Architects Should Code: The Architect’s Misconception
当我面试架构师职位的候选人时，我通常会问一个这样的问题：“你认为架构师是否应该做一些编码工作？”而通常会得到下面两个反馈之一：
“不，我正在寻找一个不再需要编码的职位。”
“我喜欢继续编码，至少是少量的编码，但可能不会有时间这样做。”
与此类似，当问及其他一些架构师最近做过多少编码的工作，通常得到的答案是：
“有一段时间没有编码了。”
这些回应总是让人感到不安。从何时开始一个技术角色的提升开始意味着脱离技术和交付？
如果不能深入到实现这些技术的团队中，架构师又怎能期望在规模庞大的技术选择中指引方向，并理解这些技术如何在企业中发挥作用？或者更好的是，亲自实施这些技术？
在没有与交付团队保持紧密联系的前提下，架构师如何能够期望在应对持续变化的项目需求时，保持灵活？
优秀的架构师必须与交付团队紧密合作。这对发展成功的系统架构，进而成功交付是十分必要的。
收集反馈并展现领导力是保持与交付团队紧密合作的两个核心利益。
反馈
深度参与的架构师会见证第一手反馈信息并且与团队紧密合作以缓解各种缺陷。反馈可能源自于各处，如企业标准的变化，持续变化或发展的功能性/非功能性需求以及在实施和测试过程中所发现的各种挑战。
能够越早识别这些缺陷，架构师就能够越快改进系统架构。如果架构师没有积极参与到交付团队中，那么这个反馈可能会花费数周甚至数月才能够上报给架构师，这时通常已经处于交付周期的晚期了。
鉴于架构决策通常会包含一些非常重要或者难以改变的内容，如果需要重大的架构性调整，这一反馈方面的延迟只会加重。
在交付周期的晚期发现架构性缺陷通常会采取变通方案以“暂时熬过这一版本”，与此同时也会留下技术债务。然而，越早捕获和评估这一反馈的架构性影响，整个项目就会越敏捷，风险累积也会更少。
领导力
架构师所承担的另一主要职责就是领导力。领导力有多种形式，所有这些形式对于成果及其底层架构的成功实现来说都是至关重要的。
为了团队的成功实现，架构领导力要求架构师能够有效地与团队沟通“大局观”。传递这一信息的最佳方案就是与交付团队紧密合作并进行若干次相关讨论，而不是仅仅通过一篇文档、一次会议或一场演讲。架构方向必须在工作过程中反复调整。太过于陷入交付的热情中，很容易忽视整体目标。一个持续参与的架构师可以帮助维系愿景的一致性。
技术领导力源于这样的事实：架构师通常在开发和交付方面具有丰富的经验。架构师的目标之一就是教育开发团队帮助其成长。有些情况下有专门的技术领导人担当这一角色，但为什么要让架构师所获得的经验浪费掉？这种交互不仅能够让整个团队受益，也能够让架构师更好地了解开发团队所遭遇的常见问题。
导师是架构师可以向团队传递的非技术领导力的一种形式。如何与非技术人群合作，拥抱敏捷原则，定义架构以及架构建模等话题都是对开发人员和潜在架构师成长十分重要的技能。与更加正式的，课堂式的教育机会相比，架构师这一角色的训练和知识多数都源于在职经验。架构师应该拥抱这一趋势并让架构学习更加主动而非被动。
提高参与度的策略
参与项目的架构师可能不必亲自交付故事。实际上，取决于诸如架构师-开发人员比率或项目的对外承诺等因素，让架构师独自负责并交付故事可能并不是一个最优方案。下面是一些可以让架构师与交付团队紧密合作并增加架构师与团队之间交互的一些策略。
结对
Martin Fowler在2015年O’Reilly的一次软件架构研讨会上发表的讲话中曾经提到结对可能是让架构师更有参与感的一种很好的选择。结对或结对编程是一种敏捷软件开发技术，随着极限编程方法而逐渐流行，在结对编程技术中，两个团队成员共同工作于一个工作站以完成一个共同的目标。在这一场景下，架构师永远不会独立地负责一个故事，而是与团队中的其他成员结对完成必须的设计、开发和/或测试工作。这一方法的优点在于能够让架构师保持对交付所负有的责任并且与所发现的架构性反馈保持紧密联系，同时又避免在架构师必须要担负外部责任的情况下团队资源的流失。
同行评审
这一方法与结对类似，不过反馈回路相对较慢。同行评审指的是一名同行从质量的角度评审另外一名同行的工作，通常是在大部分工作已经完成之后。在这里，架构师与开发者一起同行评审代码，定期的或者在故事完成之前评审一次。通过这种方法，架构师能够获得对架构一致性或问题预防一致性的深度洞察并且有机会通过开发谏言的形式建立领导力。
开发尖兵
架构师可以带领一个专注于架构探索或交付的开发尖兵团队。尖兵通过探索某项新技术，用于识别或降低风险架构某一方面的功能性概念验证的实现。尖兵提供了绝佳的机会以了解已经实现的架构决策，致力于交付目标并促进更多的针对架构瑕疵或限制的即刻视野。他们还鼓励架构师直接参与到实现中，与团队合作，共享架构愿景，并直接从过去的经验中获益。
故事开发
架构师也可以成为团队成员并完成实际的故事交付。这可能是联系最紧密的反馈回路。这种方法的缺点在于架构师可能太过于专注在个别的故事之上（只见树木不见森林）。必须保持维系架构愿景和长远规划与详细设计和具体实现之间的平衡。此外，需要注意的是，这种方法可能会破坏团队速度的一致性。举例来说，如果架构师在进行实际的故事开发三周后，被抽调出去两周完成一些更高层级的工作（如路线图），这可能会对团队的整体速度造成一定影响。首先，尽管我同意短期可能会影响速度；但长期来看由于平均法则的缘故，对速度的影响会显著降低。其次，如果架构师要进行高层级的项目相关工作，那么应该为其安排与待交付故事相关的故事任务，这样可以减少架构师必须管理的高层级与低层级任务之间的转换次数。
轮转
在这一策略中，一段时间内，架构师这一角色会在团队成员之间轮转。在每个成员担任架构师这一角色的期间，他们需要承担作出架构决策、维系架构一致性以及提供总体架构指导的职责。在不同的团队成员之间轮转架构师角色所带来的收益是能够提升团队整体的工作架构知识。团队成员能够对参与到交付中的各个角色均有更好的理解，这会促进团队角色之间的共鸣，提升团队内部的交互，以及通过应用于每个角色之上的多样化视角所带来的更好的整体产品。我会建议谨慎地使用轮转策略，因为轮转所产生的不一致性导致的混乱可能会比所得到的收益更多。取决于团队的组成和发布周期的长度，在主要发布版本（3-6个月）时间线上的某个时点进行轮转可能会比较合适。
需要避免的参与方式
有一些策略可以提升架构师在交付过程中的参与度，同样也有一些架构师可能也会采取的提升参与度的方法会对整个团队的健康发展不利，这种尝试应当尽量避免。
只处理难题
架构师可能会有只处理难题的倾向，无论这一工作是否包含在故事当中。考虑到架构师的资历和经验，这看起来像是显而易见的；然而，长期来看这可能会有损团队健康发展。首先，由于未参与其中，团队可能不会完全理解也无法支持系统中这些复杂的细微差别。其次，软件开发人员享受有挑战的工作。架构师解决了所有的难题的同时也就剥夺了其他人挖掘和学习新知识的机会。
接管
另外一种不推荐的方法就是用命令-控制的方式接管交付。架构师在架构定义上所花费的时间和精力，特别是在架构师融为团队的一部分时，能够为成功的交付提供足够的动力。架构师可能会产生整体控制整个交付方方面面的意图，而不仅仅局限于引导交付向架构性目标努力。这种方法会导致如下的消极影响：
这样的团队会对控制型的架构师产生愤怒情绪，而无法形成自组织、高效率和相互合作的团队。
限制了团队成员的主人翁意识和成长的机会。
难以处理更大的交付规模。
驱动细节，而非本质
在进行结对编程或者同行评审时，架构师应该驱动需求的本质，而非细节。即使是最简单的逻辑也有许多种编码方式，而且其中有许多都能够完美地实现功能，尽管并非完全照搬架构师的思路。架构师必须要在架构方向上加以指引，并强制实施本地代码标准，与此同时也要允许一些例外。
总结
要让一个成功的架构得以实现，架构师必须要在整个生命周期始终保持与交付团队的紧密合作。保持紧密合作能够促进架构层面的快速反馈循环。并且还能够为架构师提供更多的与团队交流架构愿景和领导团队的机会。正如本文题目所描述的那样，架构师除了可以参与到实际的编码工作中之外，还有许多其他的方式可以参与到交付团队中，例如结对编程和同行评审。相反，某些参与方式有可能会对团队造成负面影响，例如接管交付、不允许团队自组织或者采用集体所有制。其中一个关键目的是为了避免“象牙塔”架构师的角色——只在项目最初发布架构，然后就再也不见踪影。谋求与交付团队的协作关系，共同努力尽早识别和解决架构性缺陷，从而交付成功的架构和最终的产品。