1.灵魂拷问
架构师需要写代码吗？
2. 常见回答
1.不需要
2.需要编写少量的代码，但如果没有时间可能就不会做
一个技术角色的提升意味着脱离技术和交付，好像有点问题。
3.架构师的工作方式
优秀的架构师必须与交付团队紧密合作，这对发展成功的系统架构，进而成功交付是十分必要的。
我认为架构师主要的工作内容有如下两个方面：
- 收集反馈，深度参与项目
- 技术领导力，帮助团队学习成长
3.1 收集反馈（深度参与项目）
架构师除了参与到项目前期的系统设计工作，还应该参与各个模块的详细设计，当需求发生变化的时候也应该第一时间进行评估是否会对现有架构产生影响。这些需求可能来源于业务的变化、非功能性需求，以及在实施和测试过程中发现的问题。
架构决策通常包含一些非常重要或者难以改变的内容，越早识别问题，架构师就能够越快改进系统架构。如果架构师没有深度参与以上工作，这些问题通常会到交付周期的晚期发现，届时通常采用“先这样处理”的方案应付了事，留下诸多技术债务，也加大了项目的风险。
3.2 技术领导力（帮助团队学习成长）
架构师的另一项工作能力就是技术领导力。
架构师要能够有效地与团队沟通，保证架构的正确性，架构是在工作过程中持续优化，需要与团队进行若干次的相关讨论，而不是仅仅通过一篇文档、一次会议或者一场演讲。
架构师通常在开发和交付方面具有丰富的经验，通过深度的参与，不仅可以帮助开发团队成长，也可以及早发现团队目前所遇到的问题。
4.提高参与度的策略
参与项目的架构师可不必亲自交付故事（参与项目中具体模块的研发工作），让架构师独自负责并交付故事并不是一个最优方案。下面是一些可以让架构师与交付团队紧密合作并增加架构师与团队之间交互的一些策略。
- 结对
结对编程是一种敏捷软件开发技术，随着极限编程方法而逐渐流行。在结对编程技术中，两个团队成员共同完成一个工作目标。架构师与另一名成员共同完成设计、开发(该环节较少参与)以及测试工作。这一方法有点在于能够让架构师及时得到反馈。
- 同行评审（代码走查）
这一方式获得反馈的时间较长。同行评审指的是一名同行从质量的角度评审另外一名同行的工作，通常在大部分工作完成之后，架构师与开发者一起同行评审代码（代码走查）。通过这种方法，架构师也能够对架构一致性等问题进行深度的了解，提出完善改进的建议，同时也可提升技术领导力。
- 故事开发
架构师也可以成为团队成员并完成实际的故事交付（参与项目中具体模块的研发工作），这也是最及时的反馈方式。这种方式的缺点也很明显，架构师会过于专注某个故事的交付（功能的开发），降低对整体架构的把控，也会减少更高层次架构的工作。
举例来说：若架构师进行三周开发工作之后，要抽调两周时间进行一些更高层次的工作，就会影响现有团队的整体速度。
以上三种参与方式，反馈的及时性 故事开发 > 结对 > 同行评审。虽然架构师也能成为团队尖兵，但是架构师的价值远远不止如此，因此推荐的工作方式为 同行评审 > 结对 > 故事开发。
5.需要避免的参与方式
- 经常救火
救火这种场景很经常发生在项目交付的晚期，最典型的问题有功能模块性能差，需要优化。这时候由于时间的限制，能做的优化措施非常有限，比如sql优化，代码优化两种，但是有些业务场景以上这两种方式并不能提升性能，比如A和B两个系统之间的交互，原有方案采用A直接调用B系统接口的方式，但是由于B接口数据量大，处理很慢，即便优化了sql和代码，性能仍难以提升，这时候可以考虑采用MQ的方式解耦两个系统，保证A系统顺利执行完毕，B再异步处理。引入MQ需要额外进行一些处理，比如消息的可靠性、持久性等，这些都需要时间处理，会延长项目的周期。因此若架构师参加该功能模块的设计，也许就能及早发现此类问题，一开始就可以采用合理的技术方案，避免经常救火（及早参与）。
- 只处理难题
架构师可依据丰富的项目经验来处理难题，但是长期这样有损团队的健康发展，团队的其他成员失去了思考并且解决问题的机会。
- 接管（命令）
架构师融为团队一员的时候，目的应该是提升整个团队的战斗力，但是如果采用的方式不恰当，反而会削弱。比如架构师意图按照自己的想法控制项目的各方各面（过度控制），团队成员会产生抵触情绪，影响团队成员之间的合作。
- 驱动细节而非本质（代码走查）
在进行结对编程和同行评审的时候，我经常会看到部分人员纠结于代码的写法（代码洁癖）。一个功能的编码方式可以有多种，而且其中有多种都是完美的实现功能。架构师应该在架构方向上加以指引，不要过多关注代码的实现（代码需要合理）。
7.总结
要让一个成功的架构得以实现或者一个项目较为顺利交付，架构师必须要在整个生命周期始终保持与交付团队的紧密合作。保持紧密合作能够促进架构层面的快速反馈循环，并且还能够为架构师提供更多的与团队交流架构愿景和领导团队的机会。
网友评论