- 将生产部署纳入了开发的考量。
- 持续交付的基础设施通常包含持续集成环境、测试环境、预生产环境和生产环境。
- 构建流水线保证到了下游的交付物一定是通过上游验证的。
- 随着 Docker 的诞生，交付由发布包变成了 Docker 镜像。
DevOps
- 将开发和运维结合到一起。
- 环境配置工具上的进步，让基础设施即代码成了行业共识。
验收测试
- 验收测试要站在业务的角度编写。
- BDD 是一种编写验收测试的方式。
- Given...When...Then... 的描述给了一个描述业务的统一方式。
- 写好验收测试，需要构建测试模型。
SOLID 原则
- 设计模式背后的道理。
- 单一职责原则（Single responsibility principle，SRP）。
- 开放封闭原则（Open–closed principle，OCP）。
- Liskov 替换原则（Liskov substitution principle，LSP）。
- 接口隔离原则（Interface segregation principle，ISP）。
- 依赖倒置原则（Dependency inversion principle，DIP）。
- 用好单一职责原则，前提条件是看待问题颗粒度要小。
DDD
- 它将思考的起点拉到了业务上。
- DDD 分为战略设计和战术设计。
微服务
- 做好微服务的前提是划分好限界上下文。
- 微服务的第一步，不要划分微服务。
在这个模块中，我们还了解了一些重要的思路，让我们把工作做得更好。
- 程序员的三大美德：懒惰、急躁和傲慢（Laziness, Impatience and hubris）。
- 小心 NIH 综合症（Not Invented Here Syndrome）。
- 写好构建脚本，做好项目自动化。
- 参照 Java 知识体系，学习运维知识。
- 软件设计最基础的原则是“高内聚、低耦合”。
- 分层架构是一种设计上的分解。
- 不同业务量的系统本质上不是一个系统。
- 采用简单技术解决问题，直到问题变复杂。
## 实战指南
-
请谨慎地将工作自动化。
——《[29 | “懒惰”应该是所有程序员的骄傲](http://time.geekbang.org/column/article/86210)》
-
将你的工作过程自动化。
——《[30 | 一个好的项目自动化应该是什么样子的？](http://time.geekbang.org/column/article/86561)》
-
有体系地学习运维知识。
——《[31 | 程序员怎么学习运维知识？](http://time.geekbang.org/column/article/87008)》
-
将部署纳入开发的考量。
——《[32 | 持续交付：有持续集成就够了吗？](http://time.geekbang.org/column/article/87229)》
-
将验收测试自动化。
——《[33 | 如何做好验收测试？](http://time.geekbang.org/column/article/87582)》
-
把函数写短。
——《[34 | 你的代码是怎么变混乱的？](http://time.geekbang.org/column/article/87845)》
-
构建好你的领域模型。
——《[35 | 总是在说MVC分层架构，但你真的理解分层吗？](http://time.geekbang.org/column/article/88309)》
-
用简单技术解决问题，直到问题变复杂。
——《[36 | 为什么总有人觉得5万块钱可以做一个淘宝？](http://time.geekbang.org/column/article/88764)》
-
学习领域驱动设计。
——《[37 | 先做好DDD再谈微服务吧，那只是一种部署形式](http://time.geekbang.org/column/article/89049)》
## 额外收获
在这个模块的最后，针对大家在学习过程中的一些问题，我也进行了回答，帮你梳理出一个思路，更好地理解学到的内容：
- 持续集成的延伸。
- 持续集成完成系统集成。
- 持续交付完成可部署上线。
- “持续验证”完成产品想法验证。
——《[答疑解惑 | 持续集成、持续交付，然后呢？](http://time.geekbang.org/column/article/89050)》
## 留言精选
在讲到 “懒惰”应该是所有程序员的骄傲时，jxin 同学提到：
>
有价值的事并不局限于事情本身。做自动化很重要，写代码很重要。但根据现有情况判断是否需要自动化，是否需要写代码也很重要。有的放矢，任务分解。权衡跟设计是件很艺术的事情，令人着迷。
另外，关于持续交付，Jxin 同学也提出了自己的理解：
>
分而治之是解决复杂问题的一大利器。持续交互就像重构中小步快走（每次微调后运行测试代码验证），都能保证大工程的稳步前进。同时由于单元小了，所以也灵活了，持续交互可以结合最小产品的理念，以小成本做test，收集数据后，即时调整产品发展方向。
关于软件设计， 毅 同学分享了自己的感悟：
>
我们常说任务到手不要着急去做，要从设计入手，把时间多花在前面。工作中发现大家都是思考了才动手的，那为什么越往后偏差越大呢？
>
共性原因有二：一是全局观不够，用咱们课里的话说就是上下文局限和反馈延迟（看到问题不提，直到代码写到那绕不过去了再沟通）；
>
二是没有领域的概念和有意识地去实践（纸上谈兵），尤其是做流程型任务，都喜欢先把表结构定义出来，再去生成实体，所以从领域层面来看这些实体就很不合适了。结果必然是用面向对象的工具写出了面向过程的代码，既然是面向过程那OO设计原则就鲜有用武之地了。这两点也是我个人理解要做好软件设计的两个必要条件。
讲到分层架构时， desmond 同学提到：
>
学了REST和DDD，感觉两者有相通的地方：两者都以数据（一个是资源，另外一个是领域对象）为中心，并制定一套标准的数据操作（一个是HTTP Verb，另外一个项目主要用JPA这一套）；而核心是业务建模。
对于微服务的理解，风翱 同学提到：
>
公司说我们的开发方式是敏捷开发，实际上只是使用了一些敏捷开发的方法，只有遵循敏捷开发的价值观和原则，才能算是敏捷开发。微服务也是一样，不是说拆分成多个服务去部署，就叫做微服务。也不是采用市面上常用的微服务框架，就是微服务了。
对于一个好的项目自动化应该是什么样子这个问题，西西弗与卡夫卡 同学提到：
>
设想过这样的情景（还没实现，打算实践一把）：我们新招一名比较熟练的程序员，从TA入职拿到机器，到开发示意代码，再提交SCM，然后CI/CD，再发布到线上交付给用户，整个过程可以在入职当天的午饭之前完成。
>
这不光要求构建和集成自动化，甚至要求从入职开始的各个环节都能提前准备好，包括机器、开发环境、线上环境等，甚至连示范的需求都要能及时传递给TA。理想情况下，程序员只需要开发好程序，保证质量，提交到SCM即可，其他事情都应该交给机器。
>
要知道程序员都很贵，越早给用户交付价值越好。
对于自动化验收测试， shniu 同学分享了他的学习感悟：
>
自动化验收测试确实是很好的东西，比如在回归测试，省去了很多的重复工作。但我理解BDD的初衷是驱动产品、业务、开发、测试等去深入讨论沟通需求，在还没有真的写代码的时候去实例化story，并一起定义验收用例，让每个人对需求的理解都很透彻，当然特别注意的是要从统一的业务角度去描述，可见，真的做好BDD是需要不断的尝试和总结的。
对于“5万块做淘宝”这个话题，enjoylearning 同学提到：
>
做一个淘宝那样的，客户指的是业务类似，但用户量多少，需要多少并发数，搜索性能等如何都是需要跟客户沟通后才能决定技术选型的。现实中我们的有些系统已经满足了业务需求，就没有必要为了追求技术复杂度而去拆分了，只有面向问题技术选型才会有成效。
关于运维知识，hua168 同学对文章内容进行了补充：
>
现在运维流行DevOps，高级一点就是AI，其中一篇文章《DevOps 详解》不错，链接如下：
[https://infoq.cn/article/detail-analysis-of-devops](https://infoq.cn/article/detail-analysis-of-devops)
>
《DevOps知识体系与标准化的构建》也不错，下载地址：
[https://yq.aliyun.com/download/778](https://yq.aliyun.com/download/778)
>
运维知识体系：
[https://www.unixhot.com/page/ops](https://www.unixhot.com/page/ops)
>
Web缓存知识体系：
[https://www.unixhot.com/page/cache](https://www.unixhot.com/page/cache)
**感谢同学们的精彩留言。在下一个模块中，我将结合具体的应用场景，将之前讲过的“思考框架”和“四个原则”进行综合应用的分析。**
感谢阅读，如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给你的朋友。