“自动化”模块终于全部更新完毕。至此，四个工作原则我已经给你全部介绍了一遍，相对而言，这个模块的内容比较“硬”，我也竭尽全力帮你串起更多知识的脉络，所以，信息量也是非常大的。希望你能够找到自己接下来努力的方向，不断提升自己的“硬实力”。

重点复习

在这个模块中，我们学习到了一些最佳实践。

  • 持续交付
    • 将生产部署纳入了开发的考量。
    • 持续交付的基础设施通常包含持续集成环境、测试环境、预生产环境和生产环境。
    • 构建流水线保证到了下游的交付物一定是通过上游验证的。
    • 随着 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 知识体系，学习运维知识。
  • 软件设计最基础的原则是“高内聚、低耦合”。
  • 分层架构是一种设计上的分解。
  • 不同业务量的系统本质上不是一个系统。
  • 采用简单技术解决问题，直到问题变复杂。

实战指南

额外收获

在这个模块的最后，针对大家在学习过程中的一些问题，我也进行了回答，帮你梳理出一个思路，更好地理解学到的内容：

  • 持续集成的延伸。
    • 持续集成完成系统集成。
    • 持续交付完成可部署上线。
    • “持续验证”完成产品想法验证。
  • AB 测试，用一个软件的多个版本验证想法。
  • Selenium 用以完成浏览器的自动化。
  • 熟练使用快捷键。

——《答疑解惑 | 持续集成、持续交付，然后呢？》

留言精选

在讲到“懒惰”应该是所有程序员的骄傲时，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

《DevOps 知识体系与标准化的构建》也不错，下载地址：
https://yq.aliyun.com/download/778

运维知识体系：
https://www.unixhot.com/page/ops

Web 缓存知识体系：
https://www.unixhot.com/page/cache

感谢同学们的精彩留言。在下一个模块中，我将结合具体的应用场景，将之前讲过的“思考框架”和“四个原则”进行综合应用的分析。

感谢阅读，如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给你的朋友。