【架构整洁之道】手札--零

一个观点和一组问题:
观点：无论微观世界的代码、宏观层面的架构、三种编程范式还是微服务架构，都在解决一个问题——分离控制和逻辑。控制就是对程序流转的与业务逻辑无关的代码或系统的控制（如多线程、异步、服务发现、部署、弹性伸缩），逻辑则是实实在在的业务逻辑，是解决用户问题的逻辑。控制和逻辑构成了整体的软件复杂度，有效分离控制和逻辑会让你的系统得到最大的简化。
问题：作为一名架构师或工程师，你要明确地区分几组词语，否则你不可能成为一名合格的工程师或架构师。这几组词语是简单VS简陋、平衡VS妥协、迭代VS半成品。如果你不能很清楚地定义出其中的区别，那么你将很难做出正确的决定，也就不能成为一名优秀的工程师或架构师。

设计与架构究竟是什么

设计与架构二者没有任何区别。一丁点区别都没有！
底层设计细节和高层架构信息是不可分割的。它们组合在一起，共同定义了整个软件系统，缺一不可。所谓的底层和高层本身就是一系列决策组成的连续体，并没有清晰的分界线。
决策的终极目标是：用最小的人力成本来满足构建和维护该系统的需求。（一个软件架构的优劣，可以用它满足用户需求所需的成本来衡量：如果成本很低，并且在系统的整个生命周期内一直都能维持这样的低成本，那么这个系统的设计就是优良的。）

两个价值维度

• 行为价值：软件系统的行为是其最直观的价值维度。对于大部分程序员来说：按照需求文档编写代码，并且修复任何Bug。这真实大错特错~
• 架构价值：软件系统必须保持灵活性。需求变更的范畴与形状，是决定对应软件变更实施成本高低的关键，好的系统架构设计应该尽可能做到与“形状”无关。

哪个价值维度更重要

            

艾森豪威尔矩阵：紧急的难题永远是不重要的，重要的难题永远是不紧急的

软件系统的第一个价值维度：系统行为，是紧急的，但并不总是特别重要的
软件系统的第二个价值维度：系统架构，是重要的，但并不总是特别紧急的
平衡系统架构的重要性与功能的紧急程度这件事，是软件研发人员自己的职责。请记住：如果忽视软件架构的价值，系统将会越来越难以维护，终会有一天，系统将会变得再也无法修改。