qq_37756660的博客

又一次写到了结束语，也许你也是又一次来到我的结束语。我总是试图把尽可能多的知识以结构化的方式呈现在你面前。因为，就我自己的学习而言，我也总是可以很快学会细节的东西，但知识结构却不是一朝一夕就可以建立的。在下面附上了总结图，把专栏里提到的知识做了一个整理，方便更好地进行复习。在这个专栏中，虽然把软件设计相关的核心知识都讲了一遍，可还有一些内容是我没有在专栏中呈现出来的。那么，在这个专栏的结束语中，我们就来说说那些没讲的事儿。

今天讲了如何改进一个既有软件的设计。一个软件放在时间长河中会有很多东西发生改变，即便是当初还算不错的设计，随着时间的累积，也可能积重难返。改进一个软件的设计，首先，要确定改进的目标。改进的目标就是，重新设计这个软件，它应该设计成什么样子，让设计还原到它应有的本来面貌。寻找改进的起点，一部分可以从需求入手，还有一部分要从梳理接口入手。设计改进的难点在于不要回到老路上，要做正常的设计，尤其是要把分解做好。

今天，通过一个指数系统的应用讲了一个应用的设计过程。在这里，你知道了想要做好设计，目标就不能局限于只把功能实现出来，而是我们要去不断发现可能存在的各种问题。简言之，只要你认为会出现重复，它就是一个值得我们去思考解决的问题。还讲了如何衡量应用的设计水平，就是看它符合下面哪个标准：没有自动化；开发员修改代码实现；开发员修改配置实现；业务员修改配置实现。程序员常常给人写代码，实现自动化，却常常忽略了自己工作中可以自动化的部分。

今天，讲了 Moco 的设计过程。一个好的软件也好，程序库也罢，都是从实际的问题出发的。阻碍一个程序员写出好的程序库的原因，往往是没有找到一个好问题去解决。程序员不能只当一个问题的解决者，还应该经常抬头看路，做一个问题的发现者。有了问题之后，需要把问题拆解成可以下手解决的需求，让自己有一个更明确的目标。然后，我们才是根据这个需求找到一个适当的解决方案。一个通用的解决方案需要不断地抽丝剥茧，抛开无关的部分，找到核心的部分，这同样根植于分离关注点。

今天，我们讲了 DDD 中的战术设计，我们把战术设计当作了一个故事模板。让你先去识别角色，也就是找到实体和值对象。一个简单的区分就是，能通过唯一标识符识别出来的就是实体，只能通过字段组合才能识别出来的是值对象。然后我们应该找到角色之间的关系，也就是聚合。操作聚合关键点在于找到聚合根。当聚合根不存在时，聚合中的对象也就不再有价值了。有了角色及其关系，接下来就是找到各种动词，让故事生动起来。这里，我们讲到了动作，也就是领域服务，以及动作的结果，也就是领域事件，还有创建对象的工厂和保存对象的仓库。

今天，我们主要讲了 DDD 中的战略设计。战略设计中的概念主要是为了做业务的划分和落地成解决方案。首先业务的划分，我们要把识别出来的模型做一个分类，把它们放置到不同的子域中。划分子域的出发点就是不同的关注点，也就是不同的变化来源。划分出来的子域有着不同的重要程度，我们将它们再分为核心域、支撑域和通用域。做出这种区分，主要是为了针对它们各自的特点，决定不同的投入。有了不同的领域划分，我们还要把这些领域映射到解决方案上，这就引出了限界上下文。限界上下文限定了模型的使用边界，它可以成为一个独立的系统。

今天，我们讲了领域驱动设计，这是目前在软件行业内最符合软件发展趋势的一种设计方法，因为它把软件设计的起始点从技术拉到了业务。学习领域驱动设计，我们要从通用语言和模型驱动设计入手。通用语言是在业务人员和技术人员之间建立一套共有的语言，开发通用语言的一种实践是事件风暴，这是一种工作坊，通过识别领域事件找到引发事件的命令，找出与事件和命令相关的实体或聚合，帮助团队建立通用语言。DDD 的模型设计可以分为战略设计和战术设计。战略设计是高层设计，将系统拆分成领域，战术设计是低层设计，考虑如何组织不同的模型。

今天，讲了一些启发性的编程原则，这些设计原则更像是一种思考方式，让我们在软件设计上有更高的追求：KISS 原则，Keep it simple, stupid，我们要让系统保持简单；YAGNI 原则，You aren’t gonna need it，不要做不该做的需求；DRY 原则，Don’t repeat yourself，不要重复自己，消除各种重复。我们还讲了一个可以指导我们实际工作的简单设计原则，它有 4 条规则：通过所有测试；消除重复；表达出程序员的意图；让类和方法的数量最小化。

今天，我们谈到了如何学习设计模式。学习设计模式，很多人的注意力都在模式的代码应该如何编写，却忽略了模式的使用场景。强行应用模式，就会有一种削足适履的感觉。设计模式背后其实是各种设计原则，我们在实际的工作中，更应该按照设计原则去写代码，不一定要强求设计模式，而按照设计原则去写代码的结果，往往是变成了某个模式。学习设计模式，我们也要抬头看路，比如，很多设计模式的出现是因为程序设计语言自身能力的不足，我们还要知道，随着时代的发展，一些模式已经不再适用了。

今天我们讲了依赖倒置原则，它的表述是：高层模块不应依赖于低层模块，二者应依赖于抽象。抽象不应依赖于细节，细节应依赖于抽象。理解这个原则的关键在于理解“倒置”，它是相对于传统自上而下的解决问题然后组合的方式而言的。高层模块不依赖于低层模块，可以通过引入一个抽象，或者模型，将二者解耦开来。高层模块依赖于这个模型，而低层模块实现这个模型。DIP 还可以简单理解成要依赖于抽象，由此，还可以推导出一些指导编码的规则：任何变量都不应该指向一个具体类；任何类都不应继承自具体类；

今天，我们讨论了接口隔离原则，它告诉我们不应强迫使用者依赖于它们不用的方法。之所以要把这个原则列出来，很重要的一个原因就是很多接口设计得太“胖”了，里面包含了太多的内容，所以，一个更好的设计是，把大接口分解成一个一个的小接口。这里说的接口不仅仅是一种语法，实际上，每个类都有自己的接口，所有的公开方法都是接口。我们在做接口设计时，需要关注不同的使用者。我们可以把 ISP 理解成接口设计的 SRP。每个使用者面对的接口，其实都是一种角色接口。识别出接口不同的角色是至关重要的，这也与分离关注点的能力是相关的。

今天，我们讲了 Liskov 替换原则，其主要意思是说子类型必须能够替换其父类型。理解 LSP，我们需要站在父类的角度去看，而站在子类的角度，常常是破坏 LSP 的做法，一个值得警惕的现象是，代码中出现 RTTI 相关的代码。继承需要满足 IS-A 的关系，但 IS-A 的关键在于行为上的一致性，而不能单纯凭日常的概念或直觉去理解。LSP 不仅仅可以用在类关系的设计上，我们还可以把它用在更广泛的接口设计中。任何接口都是宝贵的，在设计时，都要精心考量。

今天，我们讲了开放封闭原则，软件实体应该对扩展开放，对修改封闭。简单地说，就是不要修改代码，新的功能要用新的代码实现。其实，道理大家都懂，但对很多人来说，做到是有难度的，尤其是在代码里留下扩展点，往往是需要有一定设计能力的。而构建模型的难点，首先就在于分离关注点，其次是找到共性。今天我们也讲了在一个真实项目中，怎样逐步地去构建扩展点，让系统稳定下来。很多优秀的软件在设计上都给我们提供了足够的扩展能力，向这些软件的接口学习，我们可以学到更多的东西。

今天，我们学习了单一职责原则。单一职责原则讲的并不是一个类只做一件事，它的关注点在于变化。其最初的定义是一个模块应该有且仅有一个变化的原因，后来其定义升级为一个模块应该对一类且仅对一类行为者负责。这个定义从考虑变化升级到考虑变化的来源。单一职责原则，本质上体现的还是分离关注点，所以，它与分离关注点的思考角度是一样的，需要我们将模块拆分成更小的粒度。不过，相比于分离关注点，它会更加具体，因为它需要我们考察关注点的来源：不同的行为者。

今天，讲了两个比较有用的函数式编程的概念：惰性求值和 Optional。惰性求值是一种求值策略，它将求值的过程延迟到真正需要这个值的时候，其作用就是规避一些不必要的计算。因为惰性求值的存在，还衍生出一些有趣的做法，比如，无限流和记忆。无限流启发了现在的一些大数据平台的设计，而记忆可以很好地替代 Proxy 模式。Optional 是为了解决空对象而产生的，它其实就是一个对象容器。因为这个容器的存在，访问对象时，需要增加一步思考，减少犯错的几率。

今天，我们讲了无论是全局变量、还是多线程，变化给程序设计带来了很多麻烦，然后我们还分析了这类问题的成因。然而，这类问题在函数式编程中并不存在。其中，重要的原因就是函数式编程的不变性。函数式编程的不变性主要体现在它的值和纯函数上。深入学习函数式编程时，你会遇到的与之相关的各种说法：无副作用、无状态、引用透明等等，其实都是在讨论不变性。即便使用传统的程序设计语言，我们也可以从中借鉴一些编程的方法。比如，编写不变类、编写纯函数、尽量使用不变的修饰符等等。

今天，先讲了一类特殊的函数——高阶函数，它可以接受函数或返回函数。有了高阶函数，函数式编程就可以组合了，把不同的函数组合在一起完成功能，这也给逐层构建新抽象埋下了伏笔，函数式编程从此变得精彩起来。从设计的角度看，这种模型的层层叠加，是一种好的设计方式。函数式编程中，还有一个重要的体系，就是列表转换的思想，将很多操作分解成若干转换的组合。最基础的三个转换是：map、filter 和 reduce，更多的转换操作都可以基于这三个转换完成。

这一讲我们讨论了函数式编程这种编程范式，它给我们提供的编程元素是函数。只不过，这个函数不同于传统程序设计语言的函数，它的思想根源是数学中的函数。函数是函数式编程的一等公民（first-class citizen）。一等公民指的是：它可以按需创建；它可以存储在数据结构中；它可以当作实参传给另一个函数；它可以当作另一个函数的返回值。如果你使用的程序设计语言不支持函数是一等公民，可以用其他的方式模拟出来，比如，用对象模拟函数。

今天，我们讲到了面向对象的第三个特点：多态，它是基于对象和面向对象的分水岭。多态，需要找出不同事物的共同点，建立起抽象，这也是很多程序员更好地运用多态的阻碍。而我们找出共同点，前提是要分离关注点。理解多态，还要理解好接口。它是将变的部分和不变的部分隔离开来，在二者之间建立起一个边界。一个重要的编程原则就是面向接口编程，这是很多设计原则的基础。我们今天还讨论了多态的实现，它通过将一种常见的编程结构升华为语法，降低程序员犯错的几率。最后，我们说了，多态不一定要依赖于继承实现。

今天，我们学习了面向对象的第二个特点：继承。继承分为两种，实现继承和接口继承。实现继承是站在子类的视角看问题，接口继承则是站在父类的视角。很多程序员把实现继承当作了一种代码复用的方式，但实际上，实现继承并不是一个好的代码复用的方式，之所以这种方式很常见，很大程度上是受了语言的局限。Ruby 的 mixin 机制，Scala 提供的 trait 以及 C++ 提供的私有继承都是代码复用的方式。即便只使用 Java，也可以通过组合而非继承的方式进行代码复用。

今天，我们学习了面向对象编程，它是一种以对象为编程元素的编程范式。面向对象有三个特点：封装、继承和多态。封装，是面向对象的根基。面向对象编程就是要设计出一个一个可以组合，可以复用的单元。然后，组合这些单元完成不同的功能。封装的重点在于对象提供了哪些行为，而不是有哪些数据。即便我们把对象理解成数据加函数，数据和函数也不是对等的地位。函数是接口，应该是稳定的；数据是实现，是易变的，应该隐藏起来。

今天，我们讲了程序员们最熟悉的编程范式：结构化编程。其实，从编程范式的角度，大概每个程序员都能够比较熟练地使用结构化编程提供给我们的编程元素。今天这一讲，我主要带着你回顾了一下结构化编程的由来，让你知道即便是我们已经非常熟悉的一些控制结构，也是前人经过不断努力得来的。除了知道结构化编程给我们提供了什么，我们还要看到它限制了什么，也就是 goto 语句。goto 语句实际上就是一种对程序控制权的直接转移，它可以让程序跑到任何地方去执行。而对它施加限制之后，程序就不再是随意编写的了。

今天，我们今天讨论了编程范式。编程范式指的是程序的编写模式。现在主流的编程范式主要有三种：结构化编程、面向对象编程和函数式编程。编程范式对程序员的能力施加了约束，理解编程范式的一个关键点在于，哪些事情不要做。从道理上讲，编程范式与具体语言的关系不大，但很多语言都有着自己主流的编程范式。但现在的一个趋势是，打破编程范式的“次元壁”，把不同编程范式中优秀的元素放在一起。一方面，我们可以通过设计，模拟出其他编程范式中的元素，另一方面，程序设计语言的发展趋势也是要融合不同编程范式中优秀的元素。

今天的内容主要是为了让大家放松一下，所以，我们也不做内容上的总结了。每个程序员除了学习当下要用到的知识之外，一般都会对自己的未来做一些技术储备，其中，判断技术趋势就是我们在投资未来时的一个重要参考。如何才能更好地判断未来技术发展趋势呢？就是去知道一些技术的发展历史。

今天，我们讨论了领域特定语言，这是针对某个特定领域的程序设计语言。DSL 在软件开发领域中得到了广泛的应用。要实现一个 DSL，首先要构建好模型。常见的 DSL 主要是外部 DSL 和内部 DSL。二者的主要区别在于，DSL 采用的是不是宿主语言。相对于外部 DSL，内部 DSL 的开发成本更低，与我们的日常工作结合得更加紧密。内部 DSL 体现更多的是表达能力，相对于传统的代码编写方法而言，这种做法很好地将作者的意图体现了出来。

今天，我们讨论了程序设计语言的实现：运行时。对于运行时的理解，我们甚至可以做出语言本身不支持的设计。所以，做设计真正的地基，并不是程序设计语言，而是运行时。理解运行时，可以将“程序如何运行”作为主线，将相关的知识贯穿起来。我们从了解可执行文件的结构开始，然后了解程序加载机制，知道加载器的运作和内存布局。然后，程序开始运行，我们要知道程序的运行机制，了解字节码，形成一个整体认识。最后，还可以根据需要展开各种细节，做深入的了解。

今天，我们的学习主题是程序库，程序库最初只是为了消除重复。后来，逐渐有了标准库，然后有了大量的第三方库，进而发展出包管理器。如果通用性足够好，一些经过大量实践验证过的程序库甚至会变成语言的语法，而一些语法解决得不够好的地方，又会出现新的程序库去探索新的解决方案。所以，语言设计就是程序库设计，程序库设计就是语言设计。二者相互促进，不断发展。当你开始学习如何编写程序库，你对软件设计的理解就会踏上一个新的台阶。我们说过，学习不同程序设计语言一个重要的原因是为了相互借鉴。

今天，我们谈到了程序设计语言。学习不同的程序设计语言可以帮助我们更好地落地设计，也可以让我们向不同的语言借鉴优秀的方面。我们简要地了解了程序设计语言的发展历史，从最开始的对机器模型的封装，到今天不断降低的开发门槛，程序设计语言的演化从未停止。我们也看到各种不同的编程风格在经历了最初各自独立的发展之后，开始慢慢融合。一切语法都是语法糖。新的语法通常是在既有的结构上不断添加出来的，为的是简化代码的编写。

今天是了解设计的第三部分：看实现。理解一个实现，是以对模型和接口的理解为前提的。每个系统的实现都有非常多的细节，我们不可能一上来就把所有的细节吃透。如果想了解一个系统的实现，应该从软件结构和关键技术两个方面着手。无论是软件结构，还是关键技术，我们都需要带着自己的问题入手，而问题的出发点就是我们对模型和接口的理解。了解软件的结构，其实，就是把分层的模型展开，看下一层的模型。一方面，你要知道这个层次给你提供了怎样的模型，另一方面，你要带着自己的问题去了解这些模型为什么要这么设计。

今天，我们学习如何了解设计的第二部分：看接口。看接口的一个方法是找主线，看风格。先找到一条功能主线，对项目建立起结构性的了解。有了主线之后，再沿着主线把相关接口梳理出来。查看接口，关键要看接口的风格，也就是项目作者引导人们怎样使用接口。在一个项目里，统一接口风格也是很重要的一个方面，所以，熟悉现有的接口风格，保持统一也是非常重要的。还介绍了一个曾经火爆的 Web 开发框架：Ruby on Rails。借着它的起步走文档，我给你介绍了它的一些接口，包括：Web 应用对外暴露的接口：REST API；

今天，我们学习了如何了解设计的第一部分：看模型。理解模型，要知道项目提供了哪些模型，这些模型都提供了怎样的能力。但还有更重要的一步就是，要了解模型设计的来龙去脉。这样，一方面，可以增进了我们对它的了解，但另一方面，也会减少我们对模型的破坏或滥用。我以 Spring 的 DI 容器为例给你讲解了如何理解模型。DI 容器的引入有效地解决了对象的创建和组装的问题，让程序员们拥有了一个新的编程模型。按照这个编程模型去写代码，整体的质量会得到大幅度的提升，也会规避掉之前的许多问题。

今天，我们学习了如何了解一个软件设计，可以从三个部分入手：模型、接口和实现。模型，也可以称为抽象，是一个软件的核心部分，是这个系统与其它系统有所区别的关键，是我们理解整个软件设计最核心的部分。接口，是通过怎样的方式将模型提供的能力暴露出去，是我们与这个软件交互的入口。实现，就是软件提供的模型和接口在内部是如何实现的，是软件能力得以发挥的根基。了解设计的顺序应该是，先模型，再接口，最后是实现。了解设计，需要一层一层地展开，在每个层次都按照模型、接口和实现进行理解，在头脑中形成一棵设计树。

今天，我们学习了一个影响软件设计的重要因素：可测试性。在软件设计中，可测试性常常被人忽视，结果造成了很多模块的不可测，由此引发了很多技术债。所以，在设计中就要充分考虑可测试性。在设计中考虑可测试性，就是在设计时问一下，这个函数 / 模块 / 系统怎么测。在软件开发中，只有把一个一个的小模块做了足够的测试，我们才会有稳定的构造块，才可以在集成测试的时候，只关注最终的结果。而有了可测试性的视角，我们可以把它当作一个衡量标准去看待其他的设计或实践，也可以用它帮助我们理解软件的发展趋势。

今天，我们学习了软件设计中至关重要的第一步：分解。大多数系统的设计做得不够好，问题常常出现在分解这步就没做好。常见的分解问题就是分解的粒度太大，把各种维度混淆在一起。在设计中，将一个模块的不同维度分开，有一个专门的说法，叫分离关注点。分离关注点很重要，一方面，不同的关注点混在一起会带来许多问题；另一方面，分离关注点有助于我们发现不同模块的共性，更好地进行设计。分离关注点，是我们在做设计的时候，需要时时绷起的一根弦。今天，还举了两种常见的关注点混淆的情况。

今天，我们学习了软件设计到底是什么，它应该包括“模型”和“规范”两部分：模型，是一个软件的骨架，是一个软件之所以是这个软件的核心。模型的粒度可大可小。我们所说的“高内聚、低耦合”指的就是对模型的要求，一个好的模型可以有效地隐藏细节，让开发者易于理解。模型是分层的，可以不断地叠加，基于一个基础的模型去构建上一层的模型，计算机世界就是这样一点点构建出来的。规范，就是限定了什么样的需求应该以怎样的方式去完成。它对于维系软件长期演化至关重要。关于规范，常见的两种问题是：一个项目缺乏显式的、统一的规范；

作为一个能把基本功能实现出来的程序员，偶尔仰望天空时，你是否这样问过自己，“我写过的代码还有没有更好的写法呢？如果有一天，我能够把它重写一遍，我该怎么做呢？这就是我当年问过自己的问题，因为我对自己的代码不满意：我厌倦了，把各种代码堆砌在一起，然后，在出现 Bug 时，犹如“大家来找茬”一样在其中定位问题；我厌倦了，仅仅为了一个小需求，要在无数的地方小心翼翼地做着各种微调，还被产品经理嫌弃改得慢；我厌倦了，自己辛辛苦苦写好的代码，被别人在其他地方不经意地修改，给弄崩溃了；……