去年某次会议上聊到了架构师要不要编码的问题，但是由于这个话题并不是当时的讨论重点，所以不了了之。最近又在关注架构，所以将真个问题翻出来重新整理了思路。
工作中讲过两类架构师，一类是常见的工作与交付项目上的，还有一种视角要更高的架构师。我讨论的是前者，即工作在日常交付项目上的架构师。
我认为架构师应该将编码作为工作的一部分。
[图片上传失败...(image-bb5735-1582453380195)]
1，将需求转为架构、并落地实践需要架构。
软件复杂且抽象，架构的抽象描述能在设计上解决或者有助于解决一些问题。但是现实中偏离目的的项目实施比比皆是。架构师通过编码可以了解到是否实现和设计背道而驰，从而降低技术风险，并促使架构演进。
2，了解项目真实情况，而非只是"看起来"，"听上去"那样
正如"用户表达出来的不一定是真需求"，开发者描述出来有时候并不是真的问题重点，很可能只是表象。所以能够让团队更好的解决问题，就需要清楚知道是什么、为什么，一定的编码功能，也能让架构师与项目保持同步，从而实现架构演进。
3，保持一定的水平的水准，才能更好的进行设计。
现在技术繁杂，虽然有些团队限定了技术栈，但是为了保持与时俱进，架构师能够通过部分编码工作来获得练习和与时俱进。有句话 "如果你只有一把锤子，那么看所有的问题都是钉子"。技术上的宽度和深度同样重要。这样架构师才能更好地接下来的设计中得到学习和改进。并不仅仅停留在 PPT架构师 上。
4，与团队一起工作，能够更好的帮助开发者了解架构设计的思路和目的，也起到了未来架构师培养的作用。
开发人员的焦点与架构师不同，开发人员的焦点更多的是如何在代码上，例如面型对象编程、类、接口、SOLID、重构、自动化测试等。因此对架构的理解并一定和架构师的构想一致，架构师在承担部分编码工作的时候，还能是开发者维持和架构设计的一致。并在日常沟通中培养起未来的架构师。
5，不要把全部时间都用来编码
是的，不管是哪种架构师，都不应该把全部实践用来编码，因为架构师有其自身的职责。编码只是其职责的一部分，架构师还应该架构驱动力、软件设计、技术风险管理、架构演进、质量保证上，承担相应的责任。
架构师应该将编码作为工作的一部分，但是并应该把全部实践用于编码。至于编码参与多少可以根据项目情况来决定是参与的多还是少。
