原标题：架构师不写代码，能行吗？

从什么时候起，技术角色的提升就意味着脱离技术与交付？CTO 不写代码已经引起诸多争议了，架构师也不写代码，能行吗？

就目前看来这似乎没什么问题。毕竟，写代码是开发人员的工作。架构师就应该在更重要的任务上忙碌。

但是，让架构师远离写代码会限制开发团队的潜力。当需求和业务需要发生变化时，也可能导致架构混乱。

所以对于业界的误解，今天我想要为架构师正名，接下来，就让我们来看看为什么让你的软件架构师参与写代码的工作是一件好事。不过，在此之前，我们首先来看看架构师的日常工作。

对于架构师是否需要编写代码一直有肯定或否定两种观点，其实这两种观点都有失偏颇。首先，我们看看支持架构师编写代码的理由：

1.能避免实现细节的失败。很多软件架构师由于思想和抽象思想本身的局限，比如抽象本身实际是对细节的无知和忽视，导致太多项目失败在性能等细节，还有API的精致设计以及组件的相互交互。

当然这些实现细节由代码架构师来编写也不一定能避免，或者认为只有代码架构师才能避免的观点也是片面的。

2.责任，代码架构师能够对自己的项目负责任，但是负责任也不一定必须亲自编码，一个好的架构师需要紧密与递交团队结合在一起。

3.反馈，代码开发是一个迭代过程，架构师应该随同产品开发一直跟进，当然跟进开发过程不代表亲自参与编码，不写代码也不意味着会缺乏反馈。

4.尊重，为了项目能够成功，架构师应该被尊重，架构师能够写代码与每天写代码是两回事，让架构师每天沉浸在代码细节编写中，反而是一种不尊重。

其他两个支持架构师必须编码的理由是：开发人员相比代码架构师实现项目系统的细节可能要困难；其次，没有架构意识的开发人员会将更多问题带入代码。这两个问题其实正是训练开发人员的机会，通过架构师的引导能够培养更多高级软件工程师。

其实，架构师编写代码也有很多缺点：

1.只见树木不见森林，一个架构师忙于编写调试代码会导致他没有时间或精力及时发现开发演进中的架构致命问题。

2.对于一个好的架构师，与其将时间花在编码上，好像是发挥其价值，其实更大的价值是进行代码审查以及与项目有关的知识技术分享上。

3.上下文切换是非常昂贵的，架构师一边负责架构设计的逻辑一致性，一边如果还要跟着项目编码几天，这两种上下文切换其实代价是昂贵的，比如某个人需要更改底层API代码，将之前隐藏的细节暴露给外部调用者，架构师会建议其在原来的API代码上再封装一层等等，这些都是为了维护系统的可维护性和演进发展的逻辑一致性，不至于代码系统随着时间推移变得混乱和不可维护。也就是说，架构师主要职责是对系统的架构负责，架构必须是可维护的，必须是可扩展的，长年累月地能保证做到这两点是非常不容易的，其中大量工作是与莽撞开发人员交涉。所以，架构师身兼数职导致上下文场景不同切换，几项工作可能都做不好。

让架构师亲自动手编码是一个短期思维，并不具有扩展性，只有知识分享才能在长期开发周期中具有可伸缩扩展性。架构师有时动手解决了一些架构问题，他必须向其他人讲解分析问题，以及自己的解决方案的理由，这些都是知识经验分享，这种文化会在开发人员之间传播。一个好的架构师会很快编码解决问题，但是如果不将其知识分享，就只是技巧技能的炫耀而已，而且会导致开发人员想：你能你就干，进而以后架构师越来越多地亲自动手编码；如果他花更多时间讲解培训相关知识，帮助其他人更深入理解这项任务，那么以后越来越多这样的任务就可以直接交给开发人员完成。

所以，很少或没有编码的架构师就被强迫积极分享他们的经验知识，从而能让项目减少对架构师的依赖，当然，不少架构师为了保护自己的工作总是通过塔布禁忌规定只有少数人才知道如何做这件事。

当然，有一些支持架构师不编码的理由也是值得商榷的，比如：

1.架构师不应该关心实现细节。其实架构师有责任提出最佳实践等细节，包括开源组件推荐等等，提供实现细节方案比较和知识分享。

2.架构师只要在这个项目写一次代码，然后就可以到其他项目了，这种观点也会给项目带来灾难，因为项目质量(维护性与扩展性)就难以保证了。

3.架构师是高级职务，可以陪伴客户打高尔夫谈业务需求，而开发人员都不知道怎么打高尔夫。这个观点在中国还是有点效果的。

最后总结：知识共享型的架构师不是不编码，而是不会编制太多代码，通常职责如下：

1.代码审查code review ，引导如何编码更好

2.结对编程。

3.考虑架构的改变，如果API经常被改变，或经常向别人解释这段代码是如何工作的，这些就有必要对代码架构进行变动，让其变得更易懂或更易于修改。

4.针对不断涌现问题，经常和队员讨论可能的解决方案。

来源网络，侵权删除返回搜狐，查看更多

责任编辑：