《代码大全2》阅读笔记3

质量保障篇——防御式编程与系统化调试
阅读章节： 第八部分：软件质量 (第20-24章)

核心摘要：
本篇笔记关注如何通过“防御式编程”和“科学调试方法”来构建健壮、可靠的软件。质量不是事后测试出来的，而是通过编码时的一系列防御性实践和问题出现时的系统性分析“构建”进去的。

关键要点与感悟：

防御式编程（Defensive Programming）：

观点： 核心思想是“程序应该不因传入错误数据而被破坏”。这包括检查所有外部输入的参数、使用断言（Assertions）标识不应发生的情况、以及制定明确的错误处理策略。

感悟： 我不再假设调用我代码的人或模块总是正确的。对于关键函数的入口参数，我会进行合法性校验。这虽然增加了少量代码，但却极大地增强了程序的鲁棒性。

系统化的调试过程：

观点： 调试不是漫无目的地猜测，而是一个科学的调查过程。书中详细描述了从“发现错误”到“修复错误”的完整流程，特别是“通过科学方法定位问题”的步骤：提出假设 -> 设计测试 -> 验证假设。

感悟： 这彻底改变了我解决Bug的方式。以前我可能会不停地console.log，现在我会先稳定复现问题，然后根据现象提出最可能的几个假设，再设计最有效的实验（如单元测试、日志点）去逐一验证，效率大大提高。

代码重构（Refactoring）：

观点： 重构是在不改变代码外部行为的前提下，改善其内部结构的过程。它是应对“软件腐化”和“设计退化”的利器。

感悟： 我认识到重构不是项目后期才做的事情，而应是开发过程中的常态。在添加新功能或修复Bug时，如果发现相邻代码有“坏味道”（如重复代码、过长的函数），就应该顺手进行重构，保持代码库的健康。

实践启示：

在代码中关键假设处使用断言，例如“这个指针不应为空”、“这个数组长度应大于0”。

当遇到一个复杂Bug时，拿出一张纸或一个文档，按照“科学方法”的步骤写下：问题现象 -> 可能原因假设 -> 验证计划 -> 验证结果 -> 结论。这个习惯能避免思维混乱。

将重构任务纳入迭代计划，鼓励“童子军规则”：让代码比你发现它时更干净。