目录
前言：
本篇博客内容来源自：极客时间课程《10x程序员工作法》处于学习记录。将个人认为比较重要的知识点进行摘抄记录。有兴趣的同学去极客时间学习完整课程。
一、如何做好验收测试？
行为驱动开发中的行为，指的是业务行为。BDD 希望促进业务人员与开发团队之间的协作，换句话说，如果你想做 BDD，就应该用业务语言进行描述。
BDD 则让我们换了一个视角，用业务语言做系统测试，所以，它是一个更高级别的抽象。
想写好 BDD 的测试用例，关键点在用业务视角描述。
自动化验收测试也是一个逐步发展的过程，从最开始的各自为战，到后来逐渐形成了一个完整 的自动化验收测试的体系。
一句话总结：
将验收测试自动化
二、你的代码是怎么变混乱的？
对程序员最好的惩罚是让他维护自己三个月前写的代码。
软件开发符合SOID原则
- 单一职责原则（Single responsibility principle，SRP）
- 开放封闭原则（Open–closed principle，OCP）Liskov
- 替换原则（Liskov substitution principle，LSP）
- 接口隔离原则（Interface segregation principle，ISP）
- 依赖倒置原则（Dependency inversion principle，DIP）
当我看到了 SOLID 的五个原则之后，我终于想明白了，原来我追求的方向错了。如果说设计模式是“术”，设计原则才是“道”。设计模式并不能帮你建立起知识体系，而设计原则可以。
首先，什么是单一职责原则呢？如果读过《敏捷软件开发：原则、实践与模式》，你对单一职责的理解应该是，一个模块应该仅有一个修改的原因。
单一职责原则可以用在不同的层面，写一个类，你可以问问这些方法是不是为一类 actor 服务；写方法时，你可以问问这些代码是不是在一个层面上；甚至一个服务，也需要从业务上考虑一下，它在提供是否一类的服务。总之，你看到的粒度越细，也就越能发现问题。
一句话总结：
把函数写短。
三、总是在MVC分层架构，但你真的理解分层么。
之所以你可以这么放心大胆地“忽略”底层协议，一个关键点就在于，网络模型的分层架构实现得太好了，好到你作为上层的使用者几乎可以忽略底层。而这正是分层真正的价值：构建一个良好的抽象。
我从最常见的服务端三层架构入手，给你讲了它们的来龙去脉。分层架构实际是一种设计上的分解，将不同的内容放在不同的地方，降低软件开发和维护的成本。
分层，更关键的是，提供抽象。这种分层抽象在计算机领域无处不在，无论是编程语言，还是网络协议，都体现着分层抽象的价值。有了分层抽象，人们才能更好地在抽象的基础上构建更复杂的东西。
在日常工作中，我们应该把精力重点放在构建自己的领域模型上，因为它才是工作最核心、不易变的东西。
一句话总结：
构建好你的领域模型
四、为什么总有人觉得5万块钱可以做一个淘宝
为什么我们要了解一个系统的演化过程呢？因为作为程序员，我们需要知道自己面对的到底是一个什么样的系统。
淘宝的工程师之所以要改进系统，真实的驱动力不是技术，而是不断攀升的业务量带来的问题复杂度。
所以，评估系统当前所处的阶段，采用恰当的技术解决，是我们最应该考虑的问题。
作为拥有技术能力的程序员，我们都非常在意个人技术能力的提升，但却对在什么样情形下，什么样的技术更加适用考虑得不够。采用恰当的技术，解决当前的问题，是每个程序员都应该仔细考虑的问题。如果今天的内容你只能记住。
一句话总结：
用简单技术解决问题，直到问题变复杂。
五、先做好DDD再谈微服务吧，那只是一种部署形式
相对于整体服务（Monolithic）而言，微服务足够小，代码更容易理解，测试更容易，部署也更简单。
这些道理都对，但这是做好了微服务的结果。怎么才能达到这个状态呢？这里面有一个关键因素，怎么划分微服务，也就是一个庞大的系统按照什么样的方式分解。
DDD 到底讲了什么呢？它把你的思考起点，从技术的角度拉到了业务上。
战略设计是高层设计，它帮我们将系统切分成不同的领域，并处理不同领域的关系。我在前面的内容中给你举过“订单”和“用户”的例子。从业务上区分，把不同的概念放到不同的地方，这是从根本上解决问题，否则，无论你的代码写得再好，混乱也是不可避免的。而这种以业务的角度思考问题的方式就是 DDD 战略设计带给我的。
战术设计，通常是指在一个领域内，在技术层面上如何组织好不同的领域对象。举个例子，国内的程序员喜欢用 myBatis 做数据访问，而非 JPA，常见的理由是 JPA 在有关联的情况下，性能太差。但真正的原因是没有设计好关联。
所以要做好微服务，第一步应该是识别限界上下文。
每个限界上下文都应该是独立的，每个上下文之间就不应该存在大量的耦合，困扰很多人的微服务之间大量相互调用，本身就是一个没有划分好边界而带来的伪命题，靠技术解决业务问题，事倍功半。
一句话总结：
学习领域驱动设计
六、新入职一家公司，怎么快速进入工作状态
多数程序员习惯的工作方式，往往是从细节入手，很难建立起一个完整的图景，常常是“只见树木不见森林”，而我的方式则是从大到小、由外而内，将要了解的内容层层分解，有了大图景之后，很容易知道自己做的事情到底在整体上处于什么样的位置。我把上面的内容总结了成一份供你参考。
一句话总结：
了解一个大项目，从大图景开始。
七、面对遗留系统，你应该这样做
我们把前面学到的各种知识运用到了“改造遗留系统”上。只要产品还在发展，系统改造就是不可避免的。
改造遗留系统，前提条件是要弄清楚现状，知道系统为什么要改造，是架构有问题，还是领域模型混乱，只有知道根因，才可能有的放矢地进行改造。
改造遗留系统，我给你几个建议：
- 构建测试防护网，保证新老模块功能一致；
- 分成小块，逐步替换；
- 构建好领域模型；
- 寻找行业中关于系统构建的最新理解。
-
八、我们应该如何保持竞争力？
我们的焦虑来自于对未来的不确定性，而这种不确定性是一个特定时代加上特定行业的产物。
从长期来看，只要生活中还有需要用自动化解决的问题，程序员这个群体还是很有前景的。但随着时间的推移，程序员这个职业的溢价也会越来越低，单纯凭借身处这个行业就获得好发展的可能性也越来越低，想让自己的职业生涯走得更顺畅，还需要找到更好的目标，不断努力。
当你有了“一专”，拓展“多能”，就会拥有更宽广的职业道路。比如，我拥有了深厚的技术功底，通晓怎么做软件：
- 如果还能够带着其他人一起做好，就成了技术领导者。
- 如果能够分享技术的理解，就有机会成为培训师。
- 如果能够在实战中帮助别人解决问题，就可以成为咨询师
问题：
1.持续交付是否可以再做扩展？
别把自己局限在程序员这个单一的角色中，应该了解软件开发的全生命周期。在前面的内容中，我讲了不少做产品的方法，比如，MVP、用户测试等等。如果只把自己定位在一个写代码的角色上，了解这些内容确实意义不大，但你想把自己放在一个更大的上下文中，这些内容就是必须要了解的。
- 如果你还什么都不会，那有一份编程的工作就好。
- 如果你已经能够写好普通的代码，就应该尝试去编写程序库。
- 如果实现一个具体功能都没问题了，那就去做设计，让程序有更好的组织。
- 如果你已经能完成一个普通的系统设计，那就应该去设计业务量更大的系统。
从目前的发展来看，IT 行业依然是一个非常有前景的行业，但想在这条路上走好，需要我们成为 “T ”型人才，也就是“一专多能”。一专多能的前提是“一专”，让自己成为某个方面的专家。这个专家要放在行业的标准去看，这才能降低因为一个公司的波动而造成的影响。
一句话总结：
在学习区工作和成长。
总结：
持续交付
- 将生产部署纳入了开发的考量。
- 持续交付的基础设施通常包含持续集成环境、测试环境、预生产环境和生产环境。
- 构建流水线保证到了下游的交付物一定是通过上游验证的。
- 随着 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 知识体系，学习运维知识。
- 软件设计最基础的原则是“高内聚、低耦合”。
- 分层架构是一种设计上的分解。
- 不同业务量的系统本质上不是一个系统。
- 采用简单技术解决问题，直到问题变复杂。实战指南
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。