今天文章的音频
之前已经做了领读预告哈。开始了每天的一更。
建议没看过之前领读预告的朋友们，请先移步到这篇，介绍了这其中的缘由。
幸运的金荷，公众号：梁同学Coding分享《10x程序员工作法》
2021-05-11
37-2划重点_“自动化”主题的重点内容回顾汇总
“自动化”模块终于全部更新完毕。至此，四个工作原则我已经给你全部介绍了一遍，相对而言，这个模块的内容比较“硬”，我也竭尽全力帮你串起更多知识的脉络，所以，信息量也是非常大的。希望你能够找到自己接下来努力的方向，不断提升自己的“硬实力”。
重点复习
在这个模块中，我们学习到了一些最佳实践。
【持续交付】
将生产部署纳入了开发的考量。
持续交付的基础设施通常包含持续集成环境、测试环境、预生产环境和生产环境。
构建流水线保证到了下游的交付物一定是通过上游验证的。
随着Docker的诞生，交付由发布包变成了Docker镜像。
【DevOps】
将开发和运维结合到一起。
环境配置工具上的进步，让基础设施即代码成了行业共识。
【验收测试】
验收测试要站在业务的角度编写。
BDD是一种编写验收测试的方式。
Given...When...Then...的描述给了一个描述业务的统一方式。
写好验收测试，需要构建测试模型。
【SOLID原则】
设计模式背后的道理。
单一职责原则(Singleresponsibilityprinciple，SRP)。
开放封闭原则(Open-closedprinciple，OCP)。
Liskov替换原则(Liskovsubstitutionprinciple，LSP)。
接口隔离原则(Interfacesegregationprinciple，ISP)。
依赖倒置原则(Dependencyinversionprinciple，DIP)。
用好单一职责原则，前提条件是看待问题颗粒度要小。
【DDD】
它将思考的起点拉到了业务上。
DDD分为战略设计和战术设计。
【微服务】
做好微服务的前提是划分好限界上下文。
微服务的第一步，不要划分微服务。
在这个模块中，我们还了解了一些重要的思路，让我们把工作做得更好。
程序员的三大美德：懒惰、急躁和傲慢(Laziness，Impatienceandhubris)。
小心NIH综合症(NotInventedHereSyndrome)。
写好构建脚本，做好项目自动化。
参照Java知识体系，学习运维知识。
软件设计最基础的原则是“高内聚、低耦合”。
分层架构是一种设计上的分解。
不同业务量的系统本质上不是一个系统。
采用简单技术解决问题，直到问题变复杂。
实战指南
请谨慎地将工作自动化。
——《29|“懒惰”应该是所有程序员的骄傲》
将你的工作过程自动化。
——《30|一个好的项目自动化应该是什么样子的?》
有体系地学习运维知识。
——《31|程序员怎么学习运维知识?》
将部署纳入开发的考量。
——《32|持续交付：有持续集成就够了吗?》
将验收测试自动化。
——《33|如何做好验收测试?》
把函数写短。
——《34|你的代码是怎么变混乱的?》
构建好你的领域模型。
——《35|总是在说MVC分层架构，但你真的理解分层吗?》
用简单技术解决问题，直到问题变复杂。
——《36|为什么总有人觉得5万块钱可以做一个淘宝?》
学习领域驱动设计。
——《37|先做好DDD再谈微服务吧，那只是一种部署形式》
额外收获
在这个模块的最后，针对大家在学习过程中的一些问题，我也进行了回答，帮你梳理出一个思路，更好地理解学到的内容：
持续集成的延伸。
持续集成完成系统集成。
持续交付完成可部署上线。
“持续验证”完成产品想法验证。
AB测试，用一个软件的多个版本验证想法。
Selenium用以完成浏览器的自动化。
熟练使用快捷键。
——《答疑解惑|持续集成、持续交付，然后呢?》
留言精选
在讲到“懒惰”应该是所有程序员的骄傲时，jxin同学提到：
“有价值的事并不局限性于事情本身。做自动化很重要，写代码很重要。但根据现有情况判断是否需要自动化，是否需要写代码也很重要。有的放矢，任务分解。权衡跟设计是件很艺术的事情，令人着迷。”
另外，关于持续交付，Jxin同学也提出了自己的理解：
“分而治之是解决复杂问题的一大利器。持续交互就像重构中小步快走(每次微调后运行测试代码验证)，都能保证大工程的稳步前进。同时由于单元小了，所以也灵活了，持续交互可以结合最小产品的理念，以小成本做test，收集数据后，即时调整产品发展方向。”
关于软件设计，毅同学分享了自己的感悟：
“我们常说任务到手不要着急去做，要从设计入手，把时间多花在前面。工作中发现大家都是思考了才动手的，那为什么越往后偏差越大呢?
共性原因有二：一是全局观不够，用咱们课里的话说就是上下文局限和反馈延迟(看到问题不提，直到代码写到那绕不过去了再沟通)；
二是没有领域的概念和有意识地去实践(纸上谈兵)，尤其是做流程型任务，都喜欢先把表结构定义出来，再去生成实体，所以从领域层面来看这些实体就很不合适了。结果必然是用面向对象的工具写出了面向过程的代码，既然是面向过程那OO设计原则就鲜有用武之地了。这两点也是我个人理解要做好软件设计的两个必要条件。”
讲到分层架构时，desmond同学提到：
“学了REST和DDD，感觉两者有相通的地方：两者都以数据(一个是资源，另外一个是领域对象)为中心，并制定一套标准的数据操作(一个是HTTPVerb，另外一个我项目主要用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
感谢同学们的精彩留言。在下一个模块中，我将结合具体的应用场景，将之前讲过的“思考框架”和“四个原则”进行综合应用的分析。
感谢阅读，如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给你的朋友。
