John Carmack谈软件工程的艺术与科学

在计算机学科中，真正谈得上科学的只有算法，“优化”也只能算工程。然而，真正花在算法及其优化上的时间在编程中所占比例很小。90%程序员所做的只是将功能需求以顺序、分支这样的程序形式实现出来。在这方面，我越来越不觉得有什么客观的方法能带来更好的软件。自然科学的根本在于测量和重现，在于估计和验证。软件工程中除算法和优化外，其他与此毫无关系。相反，它们只跟程序员之间，甚至同一程序员在不同时间，自己跟自己之间的社会化交互有关。程序员总在不断犯错，这已是老生常谈的事实。问题就在于，如果一种错误的做法能以正确的语法形式输入到程序中，那它就肯定会进入我们的程序。因为这个，我本人对静态代码分析极度热衷。因为我们总在不断犯错，我宁愿使用编程语言的一个更为严格的子集，并对程序员写的代码施以更加严格的限制。最近一段时间，我开始坚持每天做一点代码复查。每天看看提交的代码，找点有启发性的问题给团队讲一讲。有些问题，例如最大限度地保持参数的常量性，相对客观，争议较少。但也有很多东西更像风格问题，虽然多年来我发现它们不断地带来麻烦，但仍有很多人说：“我没见过这样的问题，对我来说这不是问题，我也不会犯这种错误。”因此，能够找到一个实际例子来指出“这就是由它引发的问题”，真是件好事。 意识到软件工程并非科学之后，我希望找到更好的方法来对付人性的弱点。然而，考虑到铁打的团队流水的开发者，想用一致的方法培训团队谈何容易。应对程序员犯错的方法肯定有好坏之分，但很难量化。而且代码会存在很长时间，将有成百上千的程序员看到一段代码，使用它并以某种方式与之交互。除了通过静态代码分析实施严格限制外，在软件API设计的层面上还有规模更大的问题，艺术的、技术的都有，我希望能在这方面找到更多可量化的方法。