架构师应不应该写代码？

    似乎隔三差五就能看到一些关于架构师应不应该写代码的文章。我是属于写代码派，因为我本身就喜欢写代码。但是，当工作职责发生变化之后，如何保持写代码和其它工作之间的平衡就成了问题。
    从个体效率上来看，我自己亲自写代码，和很多人相比没有什么绝对优势，甚至有些人码代码的速度比我还快一些。
    但作为架构师，参与写代码还是会有一些不大不小的收益。
    一般来说合格的程序员对于明确分配的任务会完成的很好，但是大部分情况下 “架构” 这个词意味着架构师并不会涉及太多细节，架构图和代码实现之间总还是有些距离，你无法保证所有人都会正确的理解你的设计，或者是程序员写代码时遇到障碍时会立刻想出足够优雅的解决方案。
    之前写过一篇关于烂代码的文章 ，大部分烂代码并不是架构师的设计问题，如果程序员没能很好的理解设计或者是经验不足，往往会做出一些非常匪夷所思的东西。比如我见过刚毕业的程序员为了防止模块耦合而将耦合的代码又拷贝了一份，或者为了 “优化性能” 而尽量把所有逻辑写在一个函数里。
    如果不能及时发现并改正这些问题，那么这些地方就会变成 “正确的错误代码”，或者” 不是我写的 “代码，或者” 我靠我也看过那段代码 “之类足以被挂上耻辱柱的玩意。这种问题算是架构师的责任吗？作为一个视名声如命的架构师，我认为是的。
    在我看来，写代码的架构师更像是在做后勤保障的工作：在代码中第一时间发现可能存在的问题，向其他人提出警告，或是给予其他人改进的意见，必要的时候或是给其他人演示一下正确的姿势。
    大部分情况下我作为架构师并不需要揽下 “核心模块” 开发这种工作，毕竟我能调配的时间太零散了，效率难以保证，很多人在专注的情况下比我做的好很多，我只需要保持大局观需要适度参与就可以了。
    总的来说，架构师和程序员在某些方面上有点像产品经理和用户的关系，大部分程序员并不会主动告诉你他们想要什么、哪里需要优化，甚至自己也不知道这些。想要做出好的产品，捷径之一就是跟用户做同样的事情。

文档来源微信：架构师应不应该写代码？