读书笔记-架构整洁之道有感

问题：如果你要成为一名架构师,你需要明确地区分几组词语(如何区分它们正是留给你的问题),否则你不可能成为一名合格的工程师或架构师。这几组词语是简单vs.简陋、平衡vs.妄华、迭代Vs.半成品。如果你不能很清楚地定义出其中的区别,那么你将很难做出正确的决定,也就不可有成为一名优秀的工程师或架构师。

按照Bob大叔的说法，所谓架构就是“用最小的人力成本来满足构建和维护系统需求”的设计行为。

就像盖房子一样，其组成结构一目了然【水泥，砖块等】，并且遵循现实世界的自然规律，比如重力。而软件架构确是没有固定的展现形式，甚至可以做到千人千面。

所以开发产品走的快的唯一方法就是先走好【所谓好也是具有针对性的，没有任何一款架构符合所有的业务场景】。但有时候好架构需要的成本可能太高，这时候就回头看看选择差的架构和返工重来带来的成本孰轻孰重。

文中有一个很有意思的举例：让一个上世纪的人穿越到现代和让现代的人穿越到上世纪，上他们敲写程序，可能需要一定的时间适应新的欢迎，但要不了多久他们就能正常工作了。

再举个例子，我们学习编程语言的时候，当理解了一门后再学习其他语言，是不是只用通读下基本就能上手了。

虽然这几十年硬件设备的提升可能大的难以想象，但软件结构形式【逻辑的组合】基本没有变化。仔细联想下，现在我们用的很多语言都是继承了上个世纪的思想，虽然我们一直在更新，但本质上可以说我们和上世纪没区别。

😜结构和设计是什么？

设计可以说是架构的组成部分，而架构又是经过设计所产生的。他们之间没有明确的区分，甚至都没有区别。

拿造车举例：生产汽车包括座位，外壳，发动机，空调，油箱，车胎等等大模块，他们可以称为架构的组成部分。但是在详细的往里看，座位的设计【颜色，样式，尺寸】，车胎的设计【半径，胎纹】等等这些都是经过相当详细的设计而产生的，甚至详细到了毫米的单位上。

所以，他们是密不可分的，你中有我，我中有你。

现在我们开发产品，总是想着快速上线，总是“欺骗”自己上线后再想重构的事情，但事实并非如此，一旦上线，频繁的版本迭代根本没时间重构，再加上同类产品的竞争追赶，更加没时间想这些了。

最终的结果就是，招人越来越多，产品越做越臃肿，直至承受不住。

这一点小空是感同身受的，已经不知道这么干了多少回了。

随着编程领域的不断发展，出现了编程范式，共有三种【相继在1960年左右提出】，相信未来短期内也不太可能出现新的。

结构化编程：对程序控制权的直接转移进行了限制和规范。

面向对象编程：对程序控制权的间接转移进行了限制和规范。

函数式编程：对程序中的赋值进行了限制和规范。

总的来说，这么多年，开发工具不断变化，但是软件编程的核心一直不变，都是有顺序结构、分支结构、循环结构和间接转移这几块组成的，缺一不可。

😜SOLID原则

她不是一个单一的原则，而是多个原则的简称。

SRP：单一职责原则

通俗点就是一个类尽量负责一个职责，避免需求改变的时候带动其他职责功能故障。

OCP：开闭原则

其核心是必须允许新增代码就能修改系统，而不是只靠修改原来的代码。也就是对扩展开放，对修改关闭。

LSP：里氏替换原则

想要系统的组成部分可以替换，这些就必须遵守同一个规则或约束。比如类B继承类A，类A有某个方法，现在需要扩展类A再增加个方法，我们可以增加个类C继承类A，类A增加函数，然后类B继承类C，这样既有了之前的功能也有了新的功能，反之亦然。

所以，利用巧妙的方法子类可以扩展父类的功能，但不要改变父类原有的功能。

ISP：接口隔离原则

避免在设计过程中不必要的依赖。比如接口A中有5个方法，类B实现接口A只用到了前两种方法，类C实现接口A，只用了后三种方法，这种情况，类C和类B都多了不必要的方法，很累赘，所以接口A可分为接口A1和A2，A1接口是类B的两个方法，A2是类C实现的方法，互不干扰。

DIP：依赖反转原则

提出结构性的代码不应依赖具体逻辑代码，应该是相反的，逻辑代码依赖结构代码。比如类A依赖类B，现在将类A的依赖改为类C，这就必须要修改类A了。这很不合适。所以，我们将类A改为接口，类B和类C实现类A接口，后续逻辑在使用的时候定义参数是类A接口，具体实现可以是类B和类C。

REP：复用/发布等同原则

按照小空的理解就是同一个组件内的资源，文档，类声明等等内容，要保持一致，及时更新。比如Java一个较小的工具组件，可能有几个类【平时写代码的时候应该都有文档注释】，当你更新的时候，文档注释里写的版本号或者说明，这几个类都要更新一下。防止别人调用你的时候因为版本问题出现差错。

CCP：共同闭包原则

这个理解起来还简单一些，就是解决某个需求的相关功能代码应该放在同一个组件中。比如有个类A，此类里面有对文件的读写判断等操作，又有了图片的放大缩小模糊等功能代码。这就有点不伦不类。他们应该分在不同的小组件才合适。

CRP：共同复用原则

文章提到的是：不要强迫一个组件的用户依赖他们不需要的东西。就是告诉我们类的依赖要分开，别一环套一环，类A依赖类B，类B依赖类C，类C依赖类D，整的隔着套娃呢。如果这几个类又在不同的组件中的话，一修改那得当场炸裂。

😜无依赖环原则

这是个有头有尾的连环依赖：A依赖类B，类B依赖类C，类C依赖类D，类D依赖类A。这种情况应该很明确ABCD他们应该是同一个大组件内，而不能分开在不同的组件，否则不同的组件又是不同的人负责，你加班加点干完后，第二天一来又不能运行了，调来调去发现同事把你依赖的组件修改了。我靠，小空直接TM想干架。【抱歉，说粗话了】

因为小空实实在在经历过，就沟通着呢，下一秒对方就改了，也没和你说，你浪费不少时间排查原因发现原来是别人的工作导致。…………

😜稳定依赖原则

我们用公式来作为直观的指标

稳定性=出向依赖/(入向依赖+出向依赖)

根据字面意思我们可以看出来入向依赖是该组件被其他组件依赖的数量（比如组件A被组件B和组件C所依赖），而出向依赖则是相反的，指的是该组件依赖的其他组件数量（比如组件A依赖组件B和组件C）。

稳定性的范围是【0-1】，越小越稳定。

所以任何一个我们预期会变更的组件都不应该被一个难以修改的组件所依赖，否则这个多变的组件也将会变得非常难以被修改。

千万不要钻牛角尖，想要所有的组件都稳定那是不可能的，这就需要我们设计的架构稳稳当当分清楚谁需要稳定谁可以不稳定。

😜稳定抽象原则

这一原则学的时候没绕过弯来，所以小空没有什么举例证明，所以直接引用下阿里云文章的一段话：

一个组件的抽象化程度应该与其稳定性保持一致。为了防止高阶架构设计和高阶策略难以修改，通常抽象出稳定的接口、抽象类为单独的组件，让具体实现的组件依赖于接口组件，这样它的稳定性就不会影响它的扩展性。

小空特别喜欢其中一部分：软件架构师必须是一线程序员，千万不要摆脱代码空空而谈，就像脱离了人民群众的领导，你不亲身体会其中设计带来的麻烦和痛苦，你怎么寻找到正确的方向？怎么能够引导团队最大化生产力不断前进呢？

中间这部分小空读了，说实在的，自己本事没修炼到家，这部分理论性较强读完感觉没什么要点，所以在这也就直接省略这部分了。不过我还是列举出他们的章节名称，有兴趣的自己看原著吧。

👉什么是软件结构👉独立性👉划分边界👉边界剖析👉策略与层次👉业务逻辑👉尖叫的软件架构👉整洁架构👉展示器和谦卑对象👉不完全边界👉层次与边界👉Main组件👉服务：宏观与微观👉测试边界👉整洁的嵌入式架构

😜数据库只是实现细节

作者在书中说了一段故事：他和同事争论在项目中要不要使用数据库，而争论的问题点不是该技术对项目的影响，而是市面上人们都在用，有些客户要求用，所以要增加，但你问他为什么又不知道为什么用。

不错，数据库确实稳健又优雅，但不管他多么的精巧和便捷，她只是个技术，只是解决某个问题的方案，不是必然存在的。

😜Web是实现细节

开篇作者就说出了真相：开始Web是简单的展示，资源的计算再服务端，随着时间的推移，人们将很多计算又放到了Web端，又随着技术发展，屁颠屁颠的将计算量又挪回服务端，来来回回，一声叹息。

总结一段话就是：业务要尽力和UI解耦

😜框架是实现细节

框架流行是一件非常好的事，能为社区带来很好的活跃性，这点不可否认，你帮我，我帮你，快快乐乐甜甜蜜蜜。

但请记住不要过分依赖框架，在使用框架之前先慢慢的从非核心业务开始，直到熟悉之后。如果你上来就大换血，很容易造成不可想象的错误。仔细想想框架作者和框架使用者是单方面的关系，就是使用者受作者限制，但作者不受使用者限制。框架作者写的框架其一是根据自己的实际开发经验其二是技术栈，针对他自己来说可能很合适，但是不同的人不同的项目遇到不同的事情，框架不一定全部受用，重复造轮子也是这个原因。

所以，框架，可用，但不可过分依赖。

😜结尾

剩下的章节是作者的小举例和真实故事，这个不太好总结，有兴趣的去书中看原始真解吧。

本书内容学习到此结束了，虽然学到了很多名词和设计方式，但千万不要被约束了。放空心态，大胆设想，小心求证。

文末

很多人在刚接触这个行业的时候或者是在遇到瓶颈期的时候，总会遇到一些问题，比如学了一段时间感觉没有方向感，不知道该从那里入手去学习，对此我整理了一些资料，需要的可以免费分享给大家

这里笔者分享一份自己收录整理上述技术体系图相关的几十套腾讯、头条、阿里、美团等公司2021年的面试题，把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节，由于篇幅有限，这里以图片的形式给大家展示一部分。

【视频教程】

天道酬勤，只要你想，大厂offer并不是遥不可及！希望本篇文章能为你带来帮助，如果有问题，请在评论区留言。
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！
846435)]

【视频教程】

[外链图片转存中…(img-n0OuQ7yA-1715148846436)]

天道酬勤，只要你想，大厂offer并不是遥不可及！希望本篇文章能为你带来帮助，如果有问题，请在评论区留言。
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！