趣味编程与生产级编程

编码中的纪律与测试

当我们为乐趣编程时，很容易忽视边界情况处理、错误报告等问题。这确实令人头疼。然而，一旦进入生产环境——更不用说为了获得薪水——我们就不能走这些捷径。

看似简单的“高质量代码”目标，实际上却让整个行业花了很长时间才摸索出正确的方法。以 Windows 95 为例，它存在一个缺陷：系统连续运行 49.7 天后就会死机。这本不奇怪，但问题在于，由于其他漏洞会在更早阶段导致系统崩溃，这个特定的 bug 竟然花了四年时间才被发现。

我们可以采取两种质量保障策略：从一开始就构建质量，或者事后强行补救。前者需要我们在日常编码中保持高度的自律；后者则依赖大量测试，最终往往意味着在自以为完成工作之后，仍需投入大量额外工作。

事后补救 是目前最常见的做法。这种模式隐含于主导行业的 瀑布开发流程 中：先明确需求，再设计，然后开发，最后测试。测试环节被放在最后。产品交付测试部门后很快就会崩溃。随后返回工程团队修复，再提交新版本，测试部门又发现新的问题，如此反复数月甚至数年。

本章的重点将放在 从一开始就构建质量 的方法上，因为只有这样，我们才能打造出值得信赖、可长期维护并持续添加功能的产品。当然，构建生产级软件是一个远超单一课程范畴的话题，其范围远不止测试本身。在接下来的课程中，我们将聚焦于现在就可以立即采取的措施，来提升代码质量。

一遍遍地测试你的代码

我们或许会认为，编写稳健的代码是理所当然的基本要求。但招聘广告上并不会写：“诚聘：态度良好、善于协作、会玩桌球的程序员。加分项：能写出稳健的代码。” 然而，现实中仍有太多程序存在缺陷。为什么会这样？

在深入探讨日常保证代码质量的具体实践之前，我们先来思考一下“编写稳健代码”究竟意味着什么。这不仅仅是一系列技术动作，更是一种思维方式。我们必须在代码交付客户之前，尽可能全面地进行测试——包括对代码本身和整个产品的各种可能场景。

毕竟，客户不会仅限于使用我们预设的理想场景。他们会以我们未曾预料的方式使用产品，长时间运行，甚至在我们从未测试过的环境中使用。我们真正需要问自己的问题是：我们希望客户发现多少个缺陷？

我们越早、越充分地在代码交付客户之前进行测试，就能越早发现并清除更多缺陷，留给客户的就自然越少。