《clean architecture》第一部分笔记

• 前言

• Bob大叔的站点介绍

• 曹大的《clean architecture》读书笔记

• lailin的架构整洁之道阅读笔记

• 第一部分的主题内容

• Chap1.设计与架构到底是什么

• 目标

• 案例分析

• 一个混乱系统的特点

• 管理层视角

• 问题到底出在了哪里

• 小结

• Chap2.两个价值维度

• 行为价值

• 架构价值

• 哪个价值维度更重要呢？

• 艾森豪威尔矩阵

• 为好的软件架构而持续斗争

• 小结

前言

相信很多同学也看过整洁架构之道这本书啦，土拨鼠之前也是查阅过网上的一些读书笔记，大部分都是简短总结性的，看了之后记忆不是很深刻(一方面看得次数不够)。So土拨鼠决定好好读一下Bob大叔的 《Clean Architecture-A CRAFTSMAN’S GUIDE TO SOFTWARE STRUCTURE AND DESIGN》 ，土拨鼠这里看的在线双语版的（主要是便于做笔记、方便回顾），中文翻译版参考的是福哥创建的书栈网[1]的上《架构整洁之道》中文翻译版[2]。发现书中的一些图是缺失的，土拨鼠就拿着英文版本的对照着看。暂时先阅读了第一部分，其中Bob大叔也举了几个现实中真真切切的例子。下面主要记录一下第一部分的关于整洁架构的概述内容。

Bob大叔的站点介绍

• bob大叔的个人简介[3]
• The Clean Code Blog[4]
• Uncle Bob Martin 博客[5]

曹大的《clean architecture》读书笔记

曹大笔记中评价还是很犀利的。

• 书评：《Clean Architecture》 写的很好，就是有点反反复复。最核心的观点实际上就是借助 interface 实现的多态和依赖反转。不过能把软件工程发展史串起来还是挺不错的。
• clean architecture(上)[6]
• clean architecture(下)[7]

lailin的架构整洁之道阅读笔记

lailin总结的也很细致，主要对书中的每个章节做了总结。

• Go工程化(一) 架构整洁之道阅读笔记[8]

第一部分的主题内容

第一部分主要是关于本书的概述，概述中Bob大叔通过软件系统好坏的简短例子说明了一个好的架构的重要性（节省成本、简单稳定、易于实施维护、灵活）。两个章节主要解释了设计和架构关系、介绍了行为和架构两个价值维度。

• Chap1. WHAT IS DESIGN AND ARCHITECTURE? 设计与架构到底是什么

• The Signature Of A Mess 一个混乱系统的特点

• The Executive View 管理层视角

• What Went Wrong? 问题到底在哪里

• The Goal? 目标是什么？

• Case Study 案例分析

• Conclusion 小结

• Chap2. A Tale of Two Value 两个价值维度

• Behavior 行为的价值

• Architecture 架构的价值

• The Greater Value 哪个价值维度更重要

• Eisenhower’s Matrix 艾森豪威尔矩阵

• Fight for the Architecture 为好的软件架构而持续斗争

Chap1.设计与架构到底是什么

本书的一个重要的目标就是要清晰、明确地对设计（Design）与架构（Architecture）进行定义。Bob大叔看来二者没有任何区别。

架构一般使用于“高层级”的讨论中，然而往往会把“底层”的实现细节排除在外。

设计往往用来指代具体的系统底层组织结构和实现的细节。但对于一个真正的系统架构师的日常工作来看，这样的区分是根本不成立的。

拿新房子来说应该包括房屋的形状、外观设计、垂直高度、房间的布局等等，还有每个插座、开关以及每个电灯具体的安装位置等具体的说明。总的来说，架构图里实际上包含了所有的底层设计细节，底层设计信息和顶层架构设计共同组成了整个房屋的架构文档。

软件设计也是如此。底层设计细节和高层架构信息是不可分割的。它们组合在一起，共同定义了整个软件系统，缺一不可。所谓的底层和高层本身就是一系列决策组成的连续体，并没有清晰的分界线。

目标

一个好的软件设计的终极目标是什么呢：软件架构的终极目标是，用最小的人力成本来满足构建和维护该系统的需求。

一个软件架构的优劣，可以用它满足用户需求所需要的成本来衡量。如果该系统的每次发布都会提升下一次变更的成本，那么这个设计就是不好的。

案例分析

图1.1展示的是 工程师团队规模随着产品的增长

图1.2展示的是 公司同期的生产效率（productivity）

纵坐标KLOC：千行代码（KLOC）是一种用于评估软件程序大小的度量。KLOC通常用于估计团队构建项目所需的时间。

图 1.3 展示的是同期内每行代码的变更成本。可以看出变更代码成本越来越高，按这个趋势下去，公司的利润甚至会被一点点榨干。

一个混乱系统的特点

混乱系统一般都是没有经过设计，匆匆忙忙被构建起来的。然后为了加快发布的速度，拼命地往团队里加入新人，同时加上决策层对代码质量提升和设计结构优化存在着持续的、长久的忽视。

图 1.4 展示了系统开发者的生产力的切身体会。他们一开始的效率都接近 100%，然而伴随着每次产品的发布，他们的生产力直线下降。到了产品的第 4 版本时，很明显大家的生产力已经不可避免地趋近为零了。

工程师的大部分时间都消耗在对现有系统的修修补补上，而不是真正完成实际的新功能。这些工程师真正的任务是：拆了东墙补西墙，周而复始。偶尔有精力能顺便实现一点小功能。

管理层视角

图 1.5展示的是该部门同期的月工资图。也许我们可以指望该公司的营收增长远远超出成本增长，这样公司就还能维持正常运转。但是这么惊人的曲线还是值得我们深入挖掘其中存在的巨大问题的。是什么造成了工程师生产力的直线下降？高管们除了跺脚、发飙，还能做什么呢？

问题到底出在了哪里

这里Bob大叔举了一个龟兔赛跑的例子，这里归纳了一下主题思想：

1. 慢而稳，才是成功的秘诀。
2. 该比赛并不是拼谁开始跑得快，也不是拼谁更有力气。
3. 心态越急，反而跑得越慢。

这个故事本身揭露的是过度自信的愚蠢行为。这和现代软件研发工作有点类似，现在的软件研发工程师都有点过于自信。但他们确实不会偷懒。但是他们真正偷懒的地方在于——持续低估那些精心设计的、整洁的代码的重要性。

然而工程师们常常会这样欺骗自己：“我们可以未来再重构代码，产品上线最重要！”但是结果大家都知道，产品上线以后重构工作就再没人提起了。

工程师们经常相信的另外一个错误观点是：“在项目中容忍糟糕的代码存在可以在短期内加快该工程上线的速度，未来这些代码会造成一些额外的工作量，但并没有什么大不了。”相信这些鬼话的工程师对自己清理混乱代码的能力过于自信了。但是更重要的是，他们还忽视了一个自然规律：无论是从短期还是长期来看，胡乱编写代码的工作速度其实比循规蹈矩更慢。

图 1.6 展示的是 Jason Gorman 进行的一次为期 6 天的实验。可以看出往后完成工作所需的时间越来越少。同时，也可以看到当采用了 TDD 方法编程后，比未采用 TDD 方法编程少用 10%的时间，并且采用 TDD 方法编程时最差的一天也比未采用 TDD 方法编程时最好的一天用时要短。

对于这个结果，它其实揭示了软件开发的一个核心特点：要想跑得快，先要跑得稳。

所以管理层扭转局面的唯一选择就是扭转开发者的观念，让他们从过度自信的兔子模式转变回来，为自己构建的混乱系统负起责任来。

小结

这本书的主题就是为读者描述了什么是优秀的、整洁的软件架构与设计，读者可以参考这些设计来构建一个长期稳定的、持久优秀的系统。

• 不管怎么看，研发团队最好的选择是清晰地认识并避开工程师们过度自信的特点，开始认真地对待自己的代码架构，对其质量负责。
• 要想提高自己软件架构的质量，就需要先知道什么是优秀的软件架构。而为了在系统构建过程中采用好的设计和架构以便减少构建成本，提高生产力，就需要先了解系统架构的各种属性与成本和生产力的关系。

Chap2.两个价值维度

对于每个软件系统，我们都对以通过行为和架构两个维度来体现它的实际价值。然而工程师往往只关注一个维度，而忽视了另外一个维度。而且常常关注的还是错误的维度，这导致了系统的价值最终趋降为零。

行为价值

软件系统的行为是其最直观的价值维度。 大部分程序员认为他们的工作是且仅是：按照需求文档编写代码，并且修复任何 Bug。这真是大错特错。

架构价值

软件系统的第二个价值维度，就体现在软件这个英文单词上：software。“ware” 的意思是“产品”，而 “soft” 的意思，不言而喻，是指软件的灵活性。

软件系统必须保持灵活。软件发明的目的，就是让我们可以以一种灵活的方式来改变机器的工作行为。对机器上那些很难改变的工作行为，我们通常称之为硬件（hardware）。

为了达到软件的本来目的，软件系统必须够“软” 也就是说，软件应该容易被修改。

需求变更的范畴与形状，是决定对应软件变更实施成本高低的关键。 这就是为什么有的代码变更的成本与其实现的功能改变不成比例。这也是为什么第二年的研发成本比第一年的高很多，第三年又比第二年更高。

问题的实际根源当然就是系统的架构设计。如果系统的架构设计偏向某种特定的“形状”，那么新的变更就会越来越难以实施。所以，好的系统架构设计应该尽可能做到与“形状”无关。

哪个价值维度更重要呢？

业务部门来回答，他们通常认为系统正常工作很重要。系统开发人员常常也就跟随采取了这种态度。bob大叔这里用了下面简单的逻辑推导来证明这个态度的错误性。

• 如果某程序可以正常工作，但是无法修改，那么当需求变更的时候它就不再能够正常工作了，我们也无法通过修改让它能继续正常工作。因此，这个程序的价值将成为 0。
• 如果某程序目前无法正常工作，但是我们可以很容易地修改它，那么将它改好，并且随着需求变化不停地修改它，都应该是很容易的事。因此，这个程序会持续产生价值。

如果你问业务部门，是否想要能够变更需求，他们的回答一般是肯定的，而且他们会增加一句：完成现在的功能比实现未来的灵活度更重要。但讽刺的是，如果事后业务部门提出了一项需求，而你的预估工作量大大超出他们的预期，这帮家伙通常会对你放任系统混乱到无法变更的状态而勃然大怒。

艾森豪威尔矩阵

重要紧急	重要不紧急
不重要但紧急	不重要也不紧急

图2.1展示的是美国前总统艾森豪威尔的紧急/重要矩阵。面对这个矩阵，艾森豪威尔曾说道：

我有两种难题：紧急的和重要的，而紧急的难题永远是不重要的，重要的难题永远是不紧急的。

确实，紧急的事情常常没那么重要，而重要的事情则似乎永远也排不上优先级。

软件系统的第一个价值维度：系统行为，是紧急的，但是并不总是特别重要。

软件系统的第二个价值维度：系统架构，是重要的，但是并不总是特别紧急。

可以看出软件的系统架构——那些重要的事情——占据了该列表的前两位，而系统行为——那些紧急的事情——只占据了第一和第三位。

平衡系统架构的重要性与功能的紧急程度这件事，是软件研发人员自己的职责。

为好的软件架构而持续斗争

为了做好上述职责，软件团队必须做好斗争的准备——或者说“长期抗争”的准备。现状就是这样。研发团队必须从公司长远利益出发与其他部门抗争，这和管理团队的工作一样，甚至市场团队、销售团队、运营团队都是这样。公司内部的抗争本来就是无止境的。

如果你是软件架构师，那么这项工作就加倍重要了。软件架构师这一职责本身就应更关注系统的整体结构，而不是具体的功能和系统行为的实现，软件架构师必须创建出一个可以让功能实现起来更容易、修改起来更简单、扩展起来更轻松的软件架构。

记住：如果忽视软件架构的价值，系统将会变得越来越难以维护，终会有一天，系统将会变得再也无法修改。如果系统变成了这个样子，那么说明软件开发团队没有和需求方做足够的抗争，没有完成自己应尽的职责。

小结

名言警句：

• 底层设计和高层架构是密不可分的。
• 软件架构的终极目标是，用最小的人力成本来满足构建和维护该系统的需求。
• 无论是从短期还是长期来看，胡乱编写代码的工作速度其实比循规蹈矩更慢。
• 要想跑得快，先要跑得稳。
• 软件系统两个价值维度：系统行为，是紧急的，但是并不总是特别重要。系统架构，是重要的，但是并不总是特别紧急。
• 为好的软件架构而持续斗争。

关于整洁架构之道的第一部分关于本书的概述读书笔记土拨鼠今天就介绍到这里了。第二部分从编程范式开始，敬请期待。如果有不同见解欢迎留言讨论。

参考资料

[1]书栈网: https://www.bookstack.cn/

[2]《架构整洁之道》中文翻译版: https://www.bookstack.cn/books/Clean-Architecture-zh

[3]bob大叔的个人简介: http://cleancoder.com/files/about.md

[4]The Clean Code Blog: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

[5]Uncle Bob Martin 博客: http://cleancoder.com/products

[6]clean architecture(上): https://xargin.com/clean-architecture-1/

[7]clean architecture(下): https://xargin.com/clean-architecture-2/

[8]Go工程化(一) 架构整洁之道阅读笔记: https://lailin.xyz/post/go-training-week4-clean-arch.html