四个策略，三个“坑”，读《架构师也不写代码》有感

当我面试架构师之时，常常会出现部分架构师不写代码的情况。我很担忧，从何时开始架构师不用写代码？架构师不去写代码，不深入实际技术团队，如何能够在技术选择中指引方向呢？如何能够期望在应对持续变化的项目需求时保持灵活？

我认为架构师不仅仅需要写代码，并且需要与交付团队紧密合作。只有深入参与的架构师才会有“第一手”的反馈消息，才能够越早识别架构缺陷，越快地改进系统架构。

曾经接触过非常多的优秀架构师，他们都有一个很好的共性，那就是拥有“领导力”，领导力有很多种表现形式，这里更侧重于帮助团队成长，完成目标协同。想要做到这些，机构师必须交付团队紧密合作。今天为大家介绍几种不错的策略。

1，结对

结对或结对编程是一种敏捷软件开发技术，在结对编程技术中，两个团队成员共同工作于一个工作站以完成一个共同的目标。在这一场景下，架构师永远不会独立地负责一个故事，而是与团队中的其他成员结对完成必需的设计、开发和 / 或测试工作。

2，同行评审

同行评审指的是一名同行从质量的角度评审另外一名同行的工作，通常是在大部分工作已经完成之后，反馈回路相对较慢。但是通过这种方法，架构师能够获得对架构一致性或问题预防一致性的深度洞察。

3，开发尖兵

架构师可以带领一个专注于架构探索或交付的开发尖兵团队。尖兵通过探索某项新技术，用于识别或降低风险架构某一方面的功能性概念验证的实现。尖兵提供了绝佳的机会以了解已经实现的架构决策，致力于交付目标并促进更多的针对架构瑕疵或限制的即刻视野。

4，故事开发

架构师可以成为团队成员，并完成实际的故事交付。这可能是联系最紧密的反馈回路。这种方法的缺点在于架构师可能太过于专注在个别的故事之上。此外这种方法可能会破坏团队速度的一致性。

讲完正确提高参与度的策略之外，再看看架构师应该注意哪些“坑”呢？

1，仅仅处理难题

架构师可能会有仅仅处理难题的倾向，长期来看这可能会有损团队健康发展。首先，由于团队其他成员未参与其中，不会完全理解也无法支持系统中这些复杂的细微差别。其次这种方式剥夺了其他人挖掘和学习新知识的机会。

2，接管

避免使用命令 - 控制的方式接管交付。团队成员容易对控制型的架构师滋生愤怒情绪，而无法形成自组织、高效率和相互合作的团队。

3，驱动细节 而非本质

在进行结对编程或者同行评审时，架构师应该驱动需求的本质，而非细节。

好了，今天关于架构师提高参与度的策略与“大坑”分享就到这里。

有想要阅读原文的小伙伴可以点击这里哦（https://mp.weixin.qq.com/s/PMjS_5KOgmNTcLmRy57yVw）