架构与边界

前言

总算把《架构整洁之道》看完了，这种看还是走马观花的看法。这本书和前端没有什么直接的关联，看完之后，你甚至会想，前端有架构这个概念么？其实，从系统架构角度看，前端所做的工作只是可替代的实现细节而已。即使如此，也不妨碍从中学到有用的知识，毕竟道理都是相通的。

步入正题，如果只是一个简单的系统，倒是不用在乎架构设计。但系统越来越庞大，越来越复杂的时候，糟糕的设计只会使得投入与产出不成正比，甚至于入不敷出。而罪魁祸首就是人们经常用来自欺欺人的一句话，「技术债后期还上，产品先上线！」。但是，需求永远是做不完的，更何况，短期内技术升级是看不到任何产出的。

稳即是快！

稳，是要求软件架构的质量有保证，要求每一个实施的技术方案都经过调研和论证，而不能因业务的压力匆匆上线。虽然，「software」，soft 指的是软件的灵活性，但这和系统的「稳」并不冲突，而恰恰因为稳才使得系统更具灵活性。

那么，回过头再看一看，导致生产效率持续降低的这个锅到底谁来背？

系统的价值可以通过行为和架构两个维度来衡量。行为价值，是指将需求文档变为实际的代码，为使用者创造价值，同时修复任何 Bug。架构价值，体现在让功能实现起来更容易、修改起来更简单、扩展起来更轻松。我们将这两个维度对照着紧急/重要矩阵：

再按优先级排序：

系统架构占据第一、第二位，系统行为占据第一、第三位。而实际开发过程中，在业务部门和研发人员的“共同努力下”，错误地将第三优先级的事情当成第一优先级去做。

业务部门意识不到系统架构的重要性很正常，但是身为研发人员呢？这是研发人员的职责所在，有必要去抗争来自其它部门的压力，阐述问题的重要性。

“这是你的问题！”
“不用说了，听我的！”
“这个事情不需要讨论。”

研发人员出力不讨好，费神又费力，到底为了什么？

软件架构的终结目标是，用最小的人力成本来满足构建和维护该系统的需求。

开发中的最佳实践在团队协作中同样适用，管理团队也需要像架构师一样去协调团队及个体之间的关系。在开发过程中，沟通成本其实还是挺高的，这时候就可以学习学习系统中的数据是如何在组件间传递的。

架构师所追求的目标是最大限度地降低构建和维护一个系统所需的人力资源。那么我们就需要了解一个系统最消耗人力资源的是什么？答案是系统中存在的耦合 —— 尤其是那些过早做出的、不成熟的决策所导致的耦合。

以前端团队为背景：

「尤其是那些过早做出的、不成熟的决策所导致的耦合。」这些很好类比，比如高层拍屁股拍出的想法，产品不成熟的想法等，这些决策直接下发到代码的实现者，然后依据反馈不断纠正。

边界线也应该沿着系统的变更轴来画。也就是说，位于边界线两侧的组件应该以不同原因、不同速率变化着。

根据不同的职能划分不同的区域，左边偏业务，右边偏技术，尴尬的是处在边界上的这位仁兄。如果组长的话语权不够，那就成为谦卑对象的存在了。

管理架构图

先忽略红线，根据单一职责，做好自己的本职工作，有输入有输出，依赖关系简单，沟通效率高。组长和组员的关系就如同展示器和视图的关系，组长需要将需求整理成最终的任务分配下去，工作内容包括参与需求评审，技术方案的制定，项目排期等，组员只需要执行任务并反馈即可。

再看一看红线部分，边界本来就是应对频繁变更的需求而建立的防火墙，此时红线绕过边界干预边界的另一头，面对这么多的输入，组员也会蒙圈，这任务谁在负责，我该向谁反馈，这个人提出的问题那个人确认了么，等等一系列的问题。

所以，私底下对于频繁变更需求并干预边界右侧的产品，我们称之为傻叉某某。对于经常拍屁股拍出想法并干预右侧的 leader，我们也称之为傻叉某某。

要想稳，就得保证任务高效有质量地完成。任务派发给了蓝框里的研发人员，研发人员之间的指派总不能靠抓阄来决定。

A：“这个开发难度为S级（困难）的任务就交给你了，我先走一步。”
B：“。。。”
某一天，
C: “之前的 A 水平有限，这代码已经没法维护了，重做吧。”
B：“。。。”
C：“抓紧点，我们要赶超对手，没错，就你一个人。”
B：“。。。”

从以上对话，我们来思考几个问题。如果 B 的水平和 A 一样，最终的结果是项目还会因为无法维护而重做。如果 B 能够胜任，由于时间的问题，最终的结果可能比第一种情况好一些。如果 B 能够胜任，老板为了加快进度，又投入一个人，最终的结果就是个谜，因为这要取决于 B 的水平。

不过现在是一个团队了，团队就应该发挥团队应有的优势。

任务分配

所以，职责要明确，搭配要妥当。