避而不谈的事也许是好事

团队里每个人都在做设计，做架构，但从来没人说过什么是架构，该如何架构，这应该是大部分团队的现状。

为什么没人拿架构做为一个明确的主题去讨论，可能的原因是：架构是关于抽象和经验。你说是好的实践，好的架构，最后的落脚点还是交付、性能、可用性上。如果一个的软件满足了这些，谁又会在意出发点和过程呢？你说未来有风险，互联项目快速迭代，开发换了一波又一波，谁又能做到持续负责？在KPI文化里，没法量化的东西是不被重视的。

架构师是稀有动物，经验最丰富，然而缺乏动力把经验理论化、系统化，教授给开发。普通开发者，听命而行，在仅有的一点自主设计上依葫芦画瓢。每个人根据自己的喜好来，再吸收别人的经验，久了团队形成了默认风格，没人能说得清为什么要这样做。这究竟是好是坏，也许并不重要，什么样的组织结构，就会产生什么样的软件架构——康威定律。

在我看来，本书的作用对个人的帮助大于团队。好的团队不需要改变，差的团队改变很难，与其从架构层面入手，不如严格执行KPI，淘汰不合格的人来的实在。个人的主要受益点，来自作者多年经验总结出的理论、方法论，自己工作几十年也不会有如此沉淀。有了这些方法论，可以切实解决实际的问题，比如如何画图，用草图而不是UML——这的确困惑了我很久。有了理论，嘿嘿，无论是建立领导力，还是说服他人，都吃这一套。