原创不易，转载请注明出处： https://www.cnblogs.com/bee0060/p/15580245.html
作者： bee0060
发布于： 博客园
前言
最近在公司参与了一些关于架构师的讨论，有了一些想法，特此写下来记录下。
我想的问题是，对架构师来说，团队建设的能力是否重要呢？
我的看法是： 很重要。
为什么呢？
我们应该时不时会听说、或参与到一些项目，这些项目越写越大，越来越难以维护，最终成为祖传代码，初始的架构原本就没有或早已不见踪影。原因有很多，如：
- 千奇百怪的需求，加上工期紧张，开发时先实现功能，想着之后再重构，但是“稍后等于永不”，实现后基本就没重构了，长此以往，积重难返，重构的难度也越来越大，重构的热情也越来越低，最终成为祖传代码，团队成员只希望项目“能跑就行”了
- 随着项目进展，初始架构已经无法满足，但是架构师已经脱离项目，不再提供建议，开发团队根据自己的理解和水平进行实现和扩展。如果再工期压力等，也很容易落到上一条的结果。
原因虽各有不同，导致的结果往往很相似，就是项目越来越难维护。
站在不同人的角度，对此可能会有不同的看法， 如：
架构师视角
初始架构是好的，架构都有一些基本的模式和思路，但实现过程中开发团队不理解或不能遵照架构的基本思路，也没有很好的对架构进行扩展，最终导致这个结果
开发团队视角
架构师给完架构设计就走了，加上需求和进度压力，我们只能优先实现功能。随着功能越来越多，原来的架构已经不满足需求，也没人可以问，只能按我们的理解先把功能实现。
综合来看，我想到的主要原因有：
- 架构被不正确的实现，以致慢慢失控
- 架构逐渐无法满足需求
以我个人经历来说，过去有过好几个项目，架构师都只在前期参与项目，甚至只给出架构设计就很快撤出项目，之后也不跟踪项目进展和给出调整建议。如果这个是业内的大多数情况，那可能这个就是根源所在。
首先，为了避免过度设计， 架构可以有扩展性，但是不可能也不应该面面俱到为将来可能的需求做过多的设计，因为项目走向是不确定的，过度设计往往弊大于利，所以架构是有适应范围和有效期的，随着需求的增加和演变，架构会慢慢变得不适应。所以很多人说，好的架构是演化来的。对此我深以为然。所以项目的不同阶段，需要将架构按不同的需求进行调整。
这之后如果架构师不再支持团队，项目前期架构师与开发团队的沟通是否足够，是否将设计思路很好的传达给了团队？如果没有一个很好的沟通渠道让开发团队可以定期咨询架构师架构上的问题，加上团队人员流动，一个项目进展一段时间后，团队里有没人和架构师打过交道都不知道，那项目的实现自然很难和架构师所期望的一样。
那怎么解决这些问题呢？
首先，我觉得架构的实现过程，不光是实现，也是一个验证过程。
实践是检验真理的唯一标准。
一个架构，无论多被看好，或用了多好的模式和方法论，如果没有被实现出来，终究还是有点像纸上谈兵。只有被真正的实现出来，才能判断其最终的优劣和价值。
加上前面提到的问题，对成功实施一个架构，我认为以下几点都很重要：
- 架构师对团队的持续支持
- 靠谱的开发团队
- 架构师和开发团队之间的良好沟通
然而，好的团队不会从天上掉下来，也不是每个架构师都有好运气遇到好团队的。
那怎么办呢？
所以，就引出开篇时的论点：
团队建设技能对架构师很重要!
架构师与团队建设
如果架构师有很好的团队建设技能，那么应该能大大提高项目成功的概率。
我认为的架构师和开发团队的理想合作方式是：
架构师给出设计，并持续支持开发团队，持续跟踪项目进展，主动或被动给出关于架构和实现的建议。
而比这个更好的合作方式是:
架构师给出设计，持续支持团队，且参与团队的建设与管理。
我们可以参考历史，古代能打善战的将领们不光擅长用兵，同样擅长练兵！
很多名将们都有自己练出来的军队，如明代戚继光有戚家军，岳飞的岳家军，孙传庭有秦兵等等
要打胜战，先要练兵！
难道做项目不是这样吗？
在项目范围内， 我觉得将一个持续支持团队看成项目的将军并不为过，而开发团队则是他的军队。
一个项目的成败，不光开发团队有责任，架构师也有责任。
开发抱怨架构，或架构师抱怨开发团队，最终都不能解决问题。
无论架构师还是开发团队，都应尽己所能提高项目的成功率。
如果架构师具备建设出一个靠谱开发团队的能力，无论对架构师还是开发团队或是对项目、公司，都是非常重要且有益的。
反面的例子是： 如果一个架构师，掌握很好的架构技术，但是参与架构的项目都失败了，那这个架构师的价值如何体现、如何证明呢？
结尾
综上所述，重提我的论点：
团队建设技能，对架构师来说，非常重要！
谢谢观看。
欢迎提出你的观点和经验，互相交流学习。