Clean Architecture读后感1000字

话题：Clean Architecture 读后感 

　　《Clean Architecture》是一本由Robert C. Martin著作，Prentice Hall出版的Paperback图书，本书定价：USD 34.99，页数：432，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。

　　《Clean Architecture》精选点评：

　　●http://vonzhou.com/clean-arch.html

　　●作者凭借50多年的编程经验，把IT类书写出了历史的厚重感，从全局的角度分析了软件开发自始至终不变的原则和道理。将细节面代码设计的原则与更高层面的组件设计融会贯通，有一种豁然开朗的感觉。唯一的不足是仍偏理论了一些。

　　●对想要对如今的架构设计建立正确认知的人来说，这里有你需要的思想上的一切，对于想要知道细节的人来说，我只想说：对不起，要么你火候不够，要么你读错书了……

　　●Which classes belong in which components? This is an important decision, and requires guidance from good software engineering principles. Unfortunately, over the years, this decision has been made in an ad hoc manner based almost entirely on context.

　　●越看越欢乐，也学了挺多东西，尤其是第二部分的 3 到 6 章。

　　●敏捷软件开发的延续，新意不多。有几个值得讨论主题讲得不够深入

　　●总体很清晰。不过作者可能只聚焦于企业应用，对于业务的理解过于极端，认为UI等就都不是业务了，都是外围的detail。但所谓业务，就是能依靠它来赚钱的东西，最有竞争力的部分。这样看来，交互优秀的UI，譬如能提高注册留存的注册UX，就是能实实在在立刻帮助赚到真金白银的，那么它也是业务级别的。

　　●Dependency Inversion Principal 划重点

　　●更多地讲一些principle和为什么这些principle有道理，没有太多地讲具体该怎么实现

　　●整体上挺好看的，除了略浅，算是提纲挈领总结一类。 其实整本核心内容都可以看成是对：lower level depends on higher level（business logic) , not the other way around 的展开，不管是 SOLID principles 还是architecture in the big picture。 不过IMO，国内互联网公司这么写代码的应该是越来越少了。

　　《Clean Architecture》读后感(一)：Dependency Inversion

　　重提了一遍各种principles。SOLID中S和D的思想贯穿整本书。收获最大的还是D，Dependecy Invsrsion。通过interface（或者说Polymorphism），使得在boundary crossing的时候，“底层”指向“高层”。感觉是从另外一个角度去看待interface如何解耦合。

　　《Clean Architecture》读后感(二)：道

　　这是一本讲架构设计之道的书； 道理，说简单也简单，就是根据功能的层次和依赖关系解耦合；说复杂也复杂，如何在架构理想和项目现实之间平衡，不是书本可以说清楚学得到的。知易行难是永远难以解决的问题。 作为一个同在PDP11上写出Hello world的老工程师，我对Martin老师所述感到亲切和敬佩；只是后来一直在AS400和MAINFRAME上工作，落后时代太久，自惭没有什么资格评价基于OO的架构设计，但正如Martin本人所讲，太阳底下本没有新鲜事，不管底层技术细节如何实现，从功能点的角度出发才能讨论系统架构设计。面对一个个罗列开源框架堆砌微服务等等名词的所谓系统架构，今后还是可以挺起腰板问几个问题的。 20181222至20190105，电子版，看完。

　　《Clean Architecture》读后感(三)：分章节读后总结

　　因为看的比较早，读的英文版，又因为读英文版不熟练，将各章节重点总结下

　　第一章

　　通过反例，强调了一个良好设计的软件架构的重要性。

　　第二章

　　功能与架构，哪个更重要？核心在于聚焦于重要的事情，不要将 "紧急不重要" 错当成 "紧急重要"。

　　第三&四&五&六章

　　探讨了3种编程范氏，即：结构化编程，面向对象编程，函数式编程。

　　结构化编程在发展过程中摒弃了goto语句，并证明通过Sequence（顺序执行），Selection（条件执行），Iteration（迭代执行）这三种结构可以编写所有程序（all programs can be contructed from just three structures）。

　　面向对象的思想，最核心的贡献在于通过多态，允许架构师插件化的切换一段程序的逻辑。

　　函数式编程（待填坑）

　　第七&八&九&十&十一章

　　介绍了SOLID五个原则

　　其中 单一职责原则 在不同的范畴下有不同的理解，从模块上来说，一个模块只应当对一个actor（提出修改需求的实体，如产品经理，客户们）负责。从类这一层面来说，该原则与CCP原则等价。

　　第十二章

　　介绍了模块的由来，所以作者想说明什么？

　　第十三章

　　介绍了处理组件（component）间依赖关系的三大原则。

　　REP: The Reuse/Release Equivalence Priciple. 以组件为单位重用与发布。

　　CCP: The Common Closure principle. 组件应当具有不同的更改时机，与原因。

　　CRP: The Common Reuse Principle. 组件不应当依赖它们用不到的东西。

　　这三个原则不可能同时完美的遵守，需要在三者间权衡。

　　第十四章

　　被依赖的组件趋于稳定，反之依赖其他组件，自身不被其他组件依赖的组件具有更好的灵活性。扇入（fan-in）代表了被依赖的强度，扇出（fan-out）代表了依赖其他模块的强度。不稳定度（instability=fan-out/(fan-in + fan-out)）可用于衡量一个组件的不稳定程度。

　　DP: Depend in the direction of stability. 应当通过有向无环图的方式处理模块间依赖。且从不稳定到稳定的方向依赖。

　　c: 组件中类的数量。 Na: 组件中抽象类与接口的数量。 A: A=Na/Nc.

　　AP: A component should be as abstract as it is stable. 一个模块越稳定，A值应当越高。

　　第十五章

　　一个好的架构师应当然让项目的 开发、运行、维护 变得容易。尽最大可能维持系统的弹性（maximize the number of decisions not made）。将具体实现与上层逻辑隔离开。

　　第十六&十七&十八&十九章

　　不知道作者想说明啥，好像是把之前的内容换种方式重新说了一遍。

　　第二十章

　　介绍了Entities，Use Cases，Request And Response Models。（待填坑）

　　第二十一章

　　架构应当与细节独立，架构设计应当吻合系统的业务目标吻合，架构的测试应当不依赖具体实现（detail）。

　　第二十二章

　　不知道作者想说明啥

　　第二十三章

　　介绍了 Humble Object pattern（第一次见，不知道中文是？），原理是对同一个模块（或类）将不便于测试的功能（与具体实现耦合，与外部环境耦合，难以检测）与便于测试的功能拆分为两部分。

　　第二十四章

　　如何处理 你可能用不到（YAGNI） 与 你可能用的到 的矛盾？

　　作者给出了三种方案（待填坑）

　　第二十五章

　　不知道作者想说明啥

　　第二十六章

　　介绍了 Main component，这是一种设计的技巧，即提供一个Main入口方法，将一些较脏，与外界耦合的工作交给它做。可以将Main方法想象成其他方法的插件。

　　第二十七章

　　探讨了微服务的意义。作者认为好的架构取决于合理的依赖分层，并不取决于模块间交互的方式。

　　第二十八章

　　测试是系统的一部分，可以将它看作系统的最外一环，即不被其他模块依赖，同时完全依赖其他模块的模块。如果在系统层面上忽略对测试的设计，很可能导致测试无法随其他模块变化、拓展，进而不可用。可以考虑暴露一个专门用于测试的API。

　　第二十九&三十&三十一&三十二

　　硬件，数据库，web，框架都属于具体实现（detail）应当将业务逻辑与其隔离开。

　　《Clean Architecture》读后感(四)：勿忘初心架构就解决业务问题的

　　2018年读的第一本书， 这个是clean code 之后又一个佳作。 另， Bob 大叔是将故事的好手， 本书章节都蛮短，但是有力。

　　故事是从一个例子开始，为什么软件生产效率为什么会 下降？是什么原因导致的下降？软件的外部质量（behavior）和内部质量（code/structure）。当只关注软件的外部质量而不关注内部质量，那么生产效率会随着软件的软件功能的日益复杂和时间遗忘变成遗留（legacy） code, 软件难于理解，难于修改，bug 常出乎意料（regression bug ），生产效率随之 下降，成为一个一个人人避之的焦油坑。关注软件内部质量，Uncle bob 从Clean code 开始关注代码的质量，如何从形和神写出高的质量代码，有了clean code 和TDD， refactor，依赖注入 之类的工程实践，提出软件工匠。 时光穿梭，8年过去，关注点从clean code 代码出发到clean architect。 这个就是本书的核心，架构的重要性，架构的初心。什么设计架构，什么好的架构， 如何做到好的架构，有哪些原则，以及提出来一个clean architectect图，同时纠正以往在设计的时候对于框架，数据库，web的依赖。

　　但是开始先做一些铺垫和热身。

　　1.讲解计算机语言的模式进化。（结构化编程从语言中去掉goto 使得程序可以分解验证，面向对象从语言总限制数据访问，提供封装继承和多态，函数是编程从语言中拿掉赋值，较少中间状态，没有副作用）

　　2. 面向对象的设计原则Solid 原则（ 职责单一【反例偶然耦合，提交代码的merge】， Open Close 原则（设计追求），里氏替换原则(陷阱），接口分离（隔离变化），依赖注入（为什么以及如何做到底层依赖高层））

　　3.包设计的原则,如何做到高内聚低耦合

　　然后进入主题，什么是设计与架构。 这个是本书的重点。

　　15章开始给出软件架构对于软件生命周期的影响（5个视角 开发，测试，部署，运维， 维护）， 以及什么是设计师，设计师就是资深程序员， 没有一线编码很难做好的设计（这个在国内的国情稍有不一样）。 好的设计上要实现业务（这个是本），中间要指导实现，后面要易于维护。 这个是自己对好的架构的理解。 Bob 给出自己的好的定义： 软件架构就要抓住本质的东西，与次要的东西分离解构。这样次要的东西的决定就可以推迟，到最后的有充分的 信息在做决策

Good architects carefully separate details from policy,and then decouple the policy from the details so thoroughly that the policy has no knowledge of the details and does not depend on the details in any way. Good architects design the policy so that decisions about the details can be delayed and deferred for as long as possible.

　　16章开始讲故事，别人家故事因为过早对于次要问题的决策导致失败，而自己家因为延迟决策而成功的例子。告诉软件要区分主次问题，次要问题不要着急做决策，比如数据库（想想我司,估计要被骂吧）。 bounder line 就是提醒我们那些次要问题不要着急做决策。17、18章紧接着告诉我边界意味这什么？ 边界意味着隔离，意味着修改不会传染，不会级联修改。隔离粒度（源代码，发布单元，进程）

Managing and building firewalls against this change is what boundaries are all about

　　另外一个角度，软件架构就是划分和协作。那么在Bob这里也同样，划分成component，就是为了隔离和分工协同开发。 那隔离目的就是防火墙，隔离变化的。19章 20章 软件的核心就是解决业务,那么什么是业务？ 模型和场景。业务也分层次（低层的和高层的），同样低层的依赖高层，但是怎么确定谁高谁低呢？ 给一个原则（好操作，不好理解）

A strict definition of “level” is “the distance from the inputs and outputs.” The farther a policy is from both the inputs and the outputs of the system, the higher itslevel. The policies that manage input and output are the lowest-level policies in thesystem.

　　ob给一个很有力剪短的例子（银行利率例子）和加密算法例子来阐述。

　　22 章给出了一个Bob 的clean architect 图。 这个是 本书的精华和浓缩。两条：

Entity(模型)/场景/API/外部各种适配器（UI,BD,controller,storage...）。依赖规则，外部依赖内部，内部不依赖外部。

　　该架构体现软件的价值，支撑和实现业务，将业务放到第一优先集，这个应理所当然。 二业务不需要以来外部（次要问题），次要问题，反过来不能影响业务设计决策。 24 章 讲述Humber 模式。25 章，软件不需要过度设计。怎么把我这个度，引用来自于敏捷的社区格言：

YAGNI: “You Aren’t Going to Need It.

　　同样提供不同的方式，（最后一步省略，facade，单向依赖）

　　25给一个例子，分层的例子； 27 紧扣当下热点评价一下微服务架构。提到一个 Compoent -Based Service, 软件的划分边界不一定按照serivce 边界，这个例子告诉你很可能是夸service边界的，是按compoent划分。 28章，测试，架构的一部分。好的架构容易测试，同时测试可以让你设计更好,达到高内聚低耦合。 代码或者模块可以测试，意味着可以对象可以创建，可以调用，那么对象就不依赖别人创建，而这些不正是我们松耦合。而对象本身作用，以及验证， 也就是高聚合，我们程序员一直追求的。29章，嵌入式的软件，也应该遵循clean 架构。感觉随着芯片的便宜，更多嵌入式开发都变成通用软件开发，嵌入式软件变为通用软件.

　　23 章 放到最好，说架构与代码项目组织关系。软件代码结构要体现架构，把架构放在最明显的地方，不要让代码结构把架构淹没在代码的碎片里。 如果酒店设计，大堂要设计的明显耀眼人人都可以看到。34 章，就是一个实践，如何在代码里面保证体现架构？ 分层， 分feature，以及分compnent。这是一个权衡。自己感觉团队习惯约定与这个有一点冲突，当然架构本来就是一个折中。

　　最后强调什么是次要的问题。26章 Main Component 是次要问题。30章数据库是次要问题。31web 是次要问题。32 章框架是次要问题。这些就是水到渠成的故事。 （但是对于开发而言，实现这些是他们的日常工作，主要矛盾。 ）

　　软件的架构，其实就是识别问题，找打主要和次要问题。 换一个视角，软件复杂的分为两种，一种是关于业务的，业务复杂度。 另外一种是技术的，技术复杂度。 没有银弹，说即使技术在强大，工具再强大，但是业务复杂度总是没法避免的，这个是根本复杂度。是技术没法从根本上解决调动。