架构师不写代码，能行吗？

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

当我面试架构师职位的候选人时，我通常会问一个这样的问题：“你认为架构师是否应该做一些编码工作？”而通常会得到下面两个反馈之一：

“不，我正在寻找一个不再需要编码的职位。”

“我喜欢继续编码，至少是少量的编码，但可能不会有时间这样做。”

与此类似，当问及其他一些架构师最近做过多少编码的工作，通常得到的答案是：

“有一段时间没有编码了。”

这些回应总是让人感到不安。从何时开始一个技术角色的提升开始意味着脱离技术和交付？

如果不能深入到实现这些技术的团队中，架构师又怎能期望在规模庞大的技术选择中指引方向，并理解这些技术如何在企业中发挥作用？或者更好的是，亲自实施这些技术？

在没有与交付团队保持紧密联系的前提下，架构师如何能够期望在应对持续变化的项目需求时，保持灵活？

优秀的架构师必须与交付团队紧密合作。这对发展成功的系统架构，进而成功交付是十分必要的。

收集反馈并展现领导力是保持与交付团队紧密合作的两个核心利益。

1、反馈

深度参与的架构师会见证第一手反馈信息并且与团队紧密合作以缓解各种缺陷。反馈可能源自于各处，如企业标准的变化，持续变化或发展的功能性 / 非功能性需求以及在实施和测试过程中所发现的各种挑战。

能够越早识别这些缺陷，架构师就能够越快改进系统架构。如果架构师没有积极参与到交付团队中，那么这个反馈可能会花费数周甚至数月才能够上报给架构师，这时通常已经处于交付