iTesting，爱测试，爱分享
|注：本系列文章摘自Xargin的博客，已获得作者授权转载。
架构师们常讲的设计定律之中最为重要的是康威定律，康威定律的定义：
Conway's law is an adage named after computer programmer Melvin Conway, who introduced the idea in 1967. It states that. organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.
这里的 'are constrained to' 即是该定律的精髓所在。如果一个公司的组织架构已经基本成型了，那么基本上设计出的系统架构和其人员组织架构必然是一致的。
在微服务场景下，团队会按照其所负责的模块被依次切开成为一个 5-10 人小团队，然后再由更为顶层的架构少来按照组织架构设计相应的系统。但是这里面有一个先后关系，是先设计系统，再根据系统来形成对应的团队。但很多时候也并不一定是如此，因为某些公司招聘速度过快(笑)，可能团队先形成了，然后才有系统设计，这时候，系统设计可能甚至会被团队架构所反作用(大概)。还是比较荒唐的。
即使是正常的设计流程，业务需求总是难以预测的。架构师们一般在设计完最初版本的系统架构之后，便会抽身到新的系统中继续挖坑。新的需求却在后续的实现过程中渐渐发现无法与最初的架构设计相匹配，具体体现在很难在当前架构上实现，或实现成本过于高昂，单模块几人天的事情，在当前架构上需要以月计的工时，这显然是不可接受的。
这时候该怎么办呢？没什么好办法。一套系统的架构一旦形成了，如果不是发生重大事件(例如迭代龟速导致公司在响应速度上跟不上竞争对手的步调；或者发生舆论事件，导致公司陷入风口浪尖，高层承诺短时间无法兑现)，一般系统本身并不会有架构上的变动。一线的开发人员最能体会这时候的痛苦，但是痛苦也没有什么卵用，因为这时候没有人有动力去推进架构上的变动。试想，在风平浪静的平日，没有任何一个一线 RD 能有能力去推动一堆比他们高两三级的“专家”做事。而一线的 leader 也没有动力去做这种于自己于自己组完全无益的变动，哪怕明知道现行架构已完全无法满足业务需求，多一锅不如少一锅。Manager 们就更不用说了，多一事不如少一事，能堆人解决的问题就尽量不用技术去解决。
所以你也看到了，这种问题是无法解决的。曾经在和同事讨论的时候，同事提出，按照这种说法来看的话，小公司的架构可能比大公司还要靠谱？
这当然也不一定，小公司一般开不出优秀人才的价格，所以优秀的架构师基本上是不会去小公司的，这就意味着大多数小公司的架构，肯定更加不靠谱。除非他们能持续发展壮大，公司财务健康，在不进行服务治理没有办法继续做业务的困境时，招入了合适的架构师来做全局把控，完成一次大的整体重构，彻底偿还历史技术栈，才会慢慢有所好转。当然这也只是个空想，业务驱动的公司不可能把业务完全停下来支持这种技术上的整体重构，记得阿里的人说在 09 年的时候进行公司的服务化，让整个公司的业务停了半年？这种项目如果最后效果不好，那负责人肯定是要离职谢罪的。大多数技术老板也是一定没有这个魄力让业务半年没有进展的，这样搞不好直接就被 CEO 干掉了好吗。
从技术上来讲有解决方案的问题，如果把政治也考虑在内，可能就变成了无解的问题。大多数公司内的业务系统所要承受的这个痛苦的过程从公司发展的历程上来讲，是必然的。所以各位技术同学，就不要抱怨业务代码写得乱了。
技术人员所能发挥作用的范围被限制于自己的模块内，或者那些愿意接自己需求的其它支持系统间。除了前面说的组织架构的问题，还需要考虑 KPI 的问题。
之前和同事一起得到了一个在大公司内推进事情的靠谱结论，如果一件事情在一个部门内就可以解决，那可以开开心心地推动它解决。如果一件事情需要跨部门，那还需要本部门的大领导出面才能解决，哪怕这事情再小。如果一件事情需要跨两个部门，那就没治了，谁出面都不行。这种事情做不了的。而如果一件事情和你要跨的部门 KPI 有冲突，那就更别想了，把部门重组了才能解决，这是 CTO 才能干的事情。
如果想要在大公司得到较好的绩效，遵循 KPI 规则是必然的。没有办法。
