这周最火的莫过于民营企业第一人阿里王坚博士当选中国工程院院士，身居IT高位，心里学出身，不会写代码，却一手打造出阿里云。
一、引言
在互联网企业中，身处技术要职的架构师到底需不需要写代码？一直都是存在争议，时不时报道某某知名人物不会写代码，但身居IT高位；如某某游泳教练，自已都不会游泳，但却能教出世界游泳冠军。这种“局外人”的例子真不少。那么架构师是否需要写代码，这似乎没什么问题。毕竟，写代码是开发人员的工作。架构师就应该在更重要的任务上忙碌。但是，让架构师远离写代码会限制开发团队的潜力。当需求和业务需要发生变化时，也可能导致架构混乱。
虽然自已长期从事技术管理工作，架构师也是我努力的方向，但在IT行业中，不管是技术管理还是架构师，即使不自已写代码，但一定要参与写代码的工作。
二、架构师的工作
这是一个很常见的问题。许多开发人员、产品经理、甚至连有些架构师都不确定架构师的工作是什么。一般的定义说他们需要做出高层决策并规定标准。但是这种说法很模糊。
架构师不是让自己编码很爽，架构师的工作更应该是让团队内的成员编码很爽。
理想情况下，架构师需要创建一个技术愿景，通过该愿景我们可以获得可维护又可靠的产品。架构师需要协调不同的团队，共同构建一个相互依存的软件生态系统。此外，他们还需要分享高层的集成决策，传达应用程序和组件之间协同工作的方式。除此之外，他们还需要根据常见的软件问题审查并规定工具和框架，并通过向利益相关者和领导层传达最终产品的目标和愿景，将所有这些联系在一起。
所以架构师的工作听起来很伟大。
三、架构师不参与编程会怎么样
如果看不到产品的日常开发过程，那么人们可能会认为一切都很顺利。 时间线看起来还不错。功能也在持续增加。我们正在朝着我们的目标前进。但现实总是残酷的：
3.1 架构师无法真正了解工具
如果架构师不参与编程，那么就无法亲身实践工具。
首先，库和工具无法解决问题时，架构师有可能并不知情。可能有一些架构师规定的工具在理想情况下可以正常运行，但是在复杂且常见的用例中这些工具可能会带来很多困难。 或者恰恰相反，他们推荐了一种适用于复杂场景的工具，但是对于开发人员遇到的简单日常问题则过于苛刻。
除非架构师使用他们自己推荐的工具，否则就无法真正意识到他们的选择产生的影响。
3.2 设计无法满足不断变化的需求
在考虑软件开发的时候，我们不能假设一个静态的世界。架构师做的提前设计并不能考虑到所有的可变因素和极端情况。在软件编写工作完成之前，我们无法发现其中的细微差别。
总之，架构和设计决策经常需要做出改变。
你可能会说这不是问题。架构师可以回去重新设计系统。然而，实际情况却并非如此。开发人员注意到有些事情不太对劲。这些事情变得越来越困难。而他们可以做的有：他们可以向架构师汇报这个问题，但是架构师不在其中无法真正掌握情况；他们可以自行重新设计系统；或者他们也可以尽可能地想办法弥补问题，然后继续前进。
如果架构师能够与开发团队近距离相处，并担任编程的工作，那么他们就可以看到变化即将到来，并实时修改设计。他也可以预先做最小的设计，并与团队合作，随着时间的推移改进系统的架构。
3.3 开发人员备受打击
如果设计只能自上而下地传达，而且架构师又不在身边，那么开发团队也会在各个方面遭受困苦。首先，正如我上面提到的，情况会发生变化。 如果架构师不在身边共同讨论，那么这些变化会导致延迟。
其次，许多开发人员都不喜欢刻板的编程，他们希望能够创造设计并做出决策。 如果设计过于精细，那么创造过程就会消失。
最后，当开发团队注意到实际情况与架构图上的不一致时，他们会责怪计划。而且他们会觉得架构师没有搞明白状况。无论这是实情还是他们的想象，编写软件过程中的障碍都可以视作架构师的失职。
四、解决方案
在我们注意一些陷阱的前提下，如果架构师参与写代码的工作，那么我们可以获得哪些好处呢？
4.1 尊重架构师
我曾经见过一些开发人员忽略了对架构师的尊重。毕竟，架构师不参与写代码的工作。他们不知道如何平衡可读性、设计和可维护性。
因此，如果架构师参与写代码的工作，那么他们就可以告诉开发团队他们在并肩作战。他们了解实际情况。而且如果有必要他们也愿意携手同行。
此外，架构师还可以更频繁地分享设计见解。通常，开发人员看不到架构模式的需求，因为他们从来没见过可以让他们的日子更好过的模式。架构师可以通过传达设计中重要部分的架构来解决这个问题。或者他们可以帮助团队将代码中的混乱部分重构成优雅的东西。
4.2 更好地理解设计
如果架构师参与写代码的工作，那么他们就有机会向开发人员传达更具影响力的设计思想和原则。看到白板上画出来的适配器模式是一回事，而在 IDE 中亲眼看到一个适配器模式是另一回事。
此外，架构师应该鼓励开发人员多多思考设计。作为导师，你可以教导开发人员处理意外的变化，并找到解决问题的模式和设计。你应该公开讨论解决方案的优缺点，提出问题和讨论，并开展设计合作。
另一种方法是利用原型。如果架构师将他们的一些架构设计原型化，那么就可以部分地看到该原型在实际生活中的运作方式，并为团队提供需要构建的东西。
4.3 实时设计更新
参与写代码工作的架构师可以实时地评估备选方案。过度架构的解决方案需要花费太多实现的时间，架构师可以为团队提供有关开源或购买库的信息。
让架构师与团队在一起可以确保根据不断变化的需求调整架构。此外，过度提前设计的工作压力也会减少。
如果架构师每周都可以参与一点写代码的工作，那么他们就可以及时地注意到代码偏离了愿景，从而可以及时地调整方向。此外，架构师还可以更好地处理正在创建的技术债务。而且他们能够指导团队何时增加技术债务，何时不能增加技术债务。
4.4 最终产品的架构所有权
如果架构师参与最前线的写代码工作，那么他们就会拥有更多产品的主动权。可以更好地了解他们的解决方案为企业带来的成本。如果他们能够亲手实现自己的解决方案，那么他们就会很快意识到哪些设计决策非常重要，而哪些设计决策可有可无。
例如，通常架构师需要针对可能发生的每种情况进行规划。 但是在项目开始时，通常很难知道哪些问题是真实的，哪些是想象的。 或者至少哪些情况不太可能出现。如果最终我们只有 100 个客户，那么就没有必要创造一个冗余且规模巨大的迷宫。 我们应该专心提供价值。
五、潜在问题
有关为什么架构师不应该参与写代码的工作，支持者们有以下几点理由：
- 他们会忽略长期愿景或更大的问题
- 理解原本不需要了解的应用程序的细节
- 架构师参与写代码的工作等于鼓励团队不配置架构师
希望确保架构师只承担自己的职责，即制定长期和高层决策。但是，我们并不是要求架构师花费所有时间来编写代码。相反，我们只是他们花费少量时间来帮助他们设计的应用程序变成现实。
至于不配置架构师的观点，我在别的地方看到过这样的例子。我们常常会遇到有的架构师很喜欢写代码，却不愿意将最基本部分之外的东西交给其他开发人员。这种架构师需要信任开发团队来编写代码。随着时间的推移，开发人员应该能够承担越来越复杂的工作。
六、人人受益
最后我认为，让软件架构师参与写代码的工作有益于整个团队和最终产品。同时也可以鼓励分享设计理念和快速反馈，可以帮助团队中每个人的成长。
所以让你的架构师参与写代码的工作吧。让开发人员参与设计的工作吧。加强团队合作才能提供最佳解决方案。
阿里王坚博士不懂代码其实是片面的说法，他是一位人机交互的设计专家，即使他不在阿里，一直在浙大，以31岁评为教授的能力，或许早成为院士也不一定。