程序员修炼之道读书笔记_2021-01-22

重构

随着程序的演化，我们有必要思考早先的决策，并重写代码。这一过程非常自然，代码需要演化。并不是静态的事物。

重写、重做和重新架构代码合起来成为重构。

什么时候需要重构代码?

代码不再合适时，具备以下特征都应该考虑重构代码：

• 重复。对DRY原则的违反（DRY原则：系统中的每一项知识都必须具有单一、无歧义、权威的表示。）
• 非正交性
• 过时的知识、需求
• 性能

现实世界影响的因素太多，我们尽量做到早重构，常重构。追踪需要重构的事物，如果不能马上开始，列入计划中。确保收到影响的代码之道代码计划要重构以及会产生什么样的影响。

怎么样进行重构？

就其核心而言，重构就是重新设计，根据新的事实、更深的理解，变化的需求等等进行设计。在重构过程中尽量遵循以下几条建议:

1. 不要试图在重构的同时增加新功能
2. 在开始重构之前，确保拥有良好的测试。及时了解你的改动影响到什么环节。
3. 采取短小、深思熟虑的步骤。重构常常涉及许多局部改动，继而产生更大规模的改动。在确保步骤保持短小的同时可以避免长时间的调试。

面对错误代码的同时，确保对模块进行剧烈改动的情况下，既要修正它也要修正依赖它的每样东西。最好一劳永逸的修正它。不要容忍破窗户。

 

---

易于测试的代码

单元测试

在隔离的状态下对每个模块进行测试，目的是检验其行为。单元测试将建立某种人工环境，根据已知的值对返回的结果进行检查，

针对合约进行测试

针对合约进行测试是为了告诉我们两件事：1、代码是否符合合约。2、合约的含义是否与我们所认为的一致。我们需要通过广泛的测试用例与边界条件测试模块是否实现了允诺的条件。通过强调对合约进行测试，我们尽可能的多避免“下游灾难”。

当你在设计模块、单个例程时，应该即设计其合约也设计测试该合约的代码。可以仔细的考虑边界条件和其他非如此便不会发现的问题。没有什么修正错误的方法比一开始就避免发生错误更好。

编写单元测试

编写单元测试可以提供以下两种好处：1、一些例子，说明怎样使用你的模块所有功能。2、用于构建回归测试、验证未来对代码的改动是否正确的一种手段。

测试文化

记住一句话，测试你的软件，否则你的用户就得测试。

 

 

转载：https://blog.csdn.net/qq_35097281/article/details/113012950