读《A Philosophy of Software Design》——（16）

🤔☕️🤔☕️🤔

• 读《A Philosophy of Software Design》——（16）Modifying Exist Code

• 📖：

  🤔：改现有的代码，为何要改？如果是代码里有缺陷，那先把缺陷点找出来，找到必现的方法，写出测试用例，尝试修改并通过用例。然后呢？赶紧找出之前的代码验证通过的方法，或者其测试用例在哪里。如果找不到，那就别碰任何旧代码。再再再看不爽的代码，改来改去，最终又还是改回原本不爽的样子，才能具备原有的功能。如果运气好，找到测试用例，那最先要读懂读明白的，是原来的测试用例。如果真想要修改代码，先给自己一个充分的理由，为何要改，会改成啥样。如果已经说服自己，那就先改测试用例。毕竟实现代码要改的情况，大概率测试用例也逃不过要改的命。

  🤔：非得要改嘛？或者说真的改得动嘛？更或者说，改了真得就更好嘛？赶紧瞄一眼接口，是否定义得合理，是否能够在接口内外关注点分离得很清晰。如果答案“YES”，多出一种候选，那就是重构它，先重构它的测试用例，再重构它的实现代码。

  🤔：为何修改或重构，非得抓住测试用例，没它不行嘛？大概率不行。原因之一，当然是验收的时候会出现碰运气的情况。原因之二，也是更重要的点，那就是通过测试用例，可以重新思考和理解，正在处理的问题，到底是什么，其边界在哪里。只有通过梳理用例的这个过程，才能比较准确理解待修改的东西，它到底是什么，它到底在怎么工作。

  🤔：还有一点要补充，那就是如何判断是否要重构。定义合理的接口是必要条件。还有就是现有代码，无法画出清晰的时序图，其中的对象，无法梳理出明显的状态，以及其状态的变迁过程。当然，重构前时序图和状态图自然不能少。

        —— By 术子米德 @2022.04.03