18 | 架构设计，专业分工和协作精神的体现

架构设计的终极目的： 快速响应业务需求，对业务达到可持续的稳定的支撑！ 为了达到上述的目的，不同的时间，不同的地点，不同的环境，不同的发展阶段，都可能有不同的解决方案措施，但是别问白猫黑猫，抓到老鼠就是好猫。 之所以有各种各样的架构，很大程度是为了应对"复杂性"， 如果事情本身不复杂，为了架构而架构，就是舍本逐末。而影响到事物复杂性的因素主要有：事物数量多，事物联系多，事物变化多。为了解决复杂性，我们就应该 化繁为简。然而，事物的复杂性永远不会消失只会转移。将事物划分的过粗，可能导致单个模块内部过于复杂;而将模块划分的过细，导致整体的模块的数量过多，以及潜在的联系过多。所以要把握一个度，这个度的标准就是"高内聚，低耦合"。为了应对复杂度中"变化多"的因素，我们应该从业务发展的角度来看，哪些部分是稳定的，哪些部分又是将来可能发生变化的，将变化的部分是否可以抽象出不变的框架，作为扩展点。

为了写心得体会，我读了专栏内容2遍和阅读了所有留言的内容，大家的留言内容让我受益匪浅。 追求架构的“道”，是需要直面的问题。抽象能力让我们抓住核心稳定的对象，自顶向下分解(专业分工)。同理心让我们理解用户的需求，组合我们的分解(协作精神)，分工是为了规模化和高效协作。 不仅仅是架构设计，团队整体形成架构共识也很重要，架构不仅仅在架构师的脑里创造，也需要在团队每个人的脑里达成共识。

《闪电式扩张》中把企业分成五个阶段：家庭、部落、村庄、城市、国家。架构债务，其中一个原因是组织已经发展到了城市或国家阶段，但是系统还停留在部落甚至家庭阶段。 康威定律也指出，组织架构和系统架构之间有一种隐含的映射关系。组织，需要分工和协作，架构也是。 「善战者无赫赫之功，善医者无煌煌之名」，持续提升业务和架构能力，不要满足于当个救火队员。 「沟通创业价值，分享带来快乐」，坚持留言的第 12 篇。

架构即人性： 1、组织架构解决的是人和人之间、组织和组织之间的分工和协作。“人”是一个最复杂和最不确定的元素，为了解决人自身的问题（惰性、会犯错....）、人和人之间的问题（主要是信任问题），人用机器来解决“人”相对确定的部分，然后不断的拓展可确定的部分。所以才有了各种机器，然后产生了很多系统。 2、软件架构解决的是系统或者组件之间的分工和协作。而系统或组件的源头是解决人的问题（提升人的效率、降低出错率）。其本质还是解决人和人之间的分工和协作问题。不管是分布式架构、微服务、单体架构，其实都是对现实中人和人之间协作方式中最佳实践的“机器实现”而已。所以做架构师一定要 有老师说的“洞察人性”的素质。 3、架构之间没有优劣，就像人和人之间没有绝对的对错，场景不同，所处的环境不同，知识背景不同，不要妄言对错。相对成熟一点的标椎可能就像老师传达的那样：帮助业务成长，促进组织成功。

乔老师这么多节课程其实一直在给我们布道“Trade-Off”的理念，要懂得前进，也要懂得刹车，不能陷入任何一种偏执的境地，随时提醒自己做这件事情的最初目的，不然容易走火入魔。

从技术方面的架构师设计，我联想到了最近公司的一些组织架构调整和工作职责边界的问题。专业分工，正所谓术业有专攻，确实要让专业的人做专业的事情。组织分工明确之后，协作也很重要。有些组织调整，专业分工明确了，但是协作缺失了，也不能发挥组织的协同效用，不能做到取长补短。系统设计中，工作中，总有那些无法明确划分职责边界的灰色地带，这个时候怎么提高协作能力，就是考验技术管理者的“架构设计”能力了。 我也联想到了康威定律，有前辈说在工作中反过来看康威定律，会有不同的感受。

问题拆解、专人专事、协同合作，这就是我对于老师今天课程的理解。

好的架构设计，就像优秀的组织协作一样，既能帮助 IT 系统做好各模块的专业分工，又能体现模块间的协作精神 让我想到了多线程里的，分工和同步。

这节内容我重复听了3个多小时。

我前公司的老板是这样设计的，把所有的功能全部用存储过程编写，所有的页面都控件等都在数据库登记，全都可以配置，配置某个用户的某个界面的某个文本框的长度，按钮是否可见等等，最终实现类似SAP那样，页面大多都是实施人员配置，带来的后果当然是界面逻辑非常复杂，而且很难定制化页面 你觉得这样的设计有前途不？ 我觉得没前途，所以我离开了这个10年的创业公司，去了一家上市公司做 高级前端工程师 了