代码 “能跑起来” 只是最低要求，真正高质量的代码需要具备 “可靠性、可测试性、可维护性”。这一部分主要介绍如何通过测试、调试、代码评审等手段保障代码质量。
- 测试：提前发现问题
书中强调，“测试不是编码后的补充，而是贯穿编码全过程的环节”。主要包括以下几种测试类型：
单元测试：针对 “最小的代码单元”（如函数、方法）进行测试，验证其在不同输入下的输出是否符合预期。例如，测试一个 “计算加法” 的函数add(a, b)，需要验证add(1,2)=3、add(-1,1)=0、add(0,0)=0等场景。单元测试的核心价值是 “快速定位问题”—— 当单元测试失败时，能直接确定问题出在哪个函数，避免在整个系统中排查。
集成测试：测试多个模块之间的交互是否正常。例如，测试 “用户注册” 功能时，需要验证 “用户模块” 与 “数据库模块” 的交互（注册信息是否正确存入数据库）、“用户模块” 与 “短信模块” 的交互（是否发送注册成功短信）等。集成测试能发现模块之间接口不兼容、数据传递错误等问题。
测试驱动开发（TDD）：一种 “先写测试，再写代码” 的开发模式。具体流程是：先根据需求编写单元测试（此时测试会失败，因为代码未实现），然后编写代码让测试通过，最后优化代码（重构）。TDD 的优势在于，能确保代码始终围绕 “需求目标” 展开，避免编写冗余代码，同时保证代码的可测试性。 - 调试：高效定位与解决问题
即使经过充分测试，代码运行过程中仍可能出现问题（如 Bug、异常）。书中介绍了高效的调试方法：
重现问题：调试的第一步是 “稳定重现问题”。只有能稳定重现的问题，才能有针对性地分析原因。例如，用户反馈 “点击按钮后偶尔崩溃”，需要通过模拟用户操作、记录日志等方式，找到 “崩溃时的具体场景”（如输入数据、操作步骤），确保问题能反复出现。
定位根源：避免 “头痛医头，脚痛医脚”。例如，代码出现 “空指针异常”，不能只简单地在异常处加一个null判断，而应分析 “为什么会出现 null”（是参数传递错误，还是数据库查询返回 null 未处理？），从根源上解决问题。书中建议通过 “日志打印”“断点调试” 等方式，逐步跟踪代码执行流程，找到问题的核心原因。
记录调试过程：将调试过程中发现的问题、原因、解决方案记录下来，形成 “知识库”。这样不仅能避免后续重复踩坑，也能为团队其他成员提供参考。 - 代码评审：团队协作提升质量
代码评审（Code Review，CR）是团队成员互相检查代码的过程，是保障代码质量的重要手段。书中给出了代码评审的核心建议：
明确评审重点：代码评审不是 “挑错大会”，而是 “共同提升代码质量”。评审重点应包括：代码是否符合规范、逻辑是否清晰、是否存在性能隐患、是否有足够的测试覆盖等，而非纠结于 “括号的位置”“变量名的细微差异” 等无关紧要的细节。
保持开放心态：评审者应提出建设性意见（如 “这里可以用常量替代魔法数字，提高可读性”），而非直接否定（如 “这段代码写得太差了”）；被评审者应正视反馈，将其视为提升代码质量的机会，而非批评。
及时评审：代码评审应尽早进行（如开发者完成一个小功能后），此时代码量少，问题更容易发现，修改成本也更低。避免将代码堆积到项目后期再集中评审，导致问题集中爆发，难以修改。