id Software可能是1990年代最具标志性的视频游戏公司，开发了诸如Wolfenstein 3D，Doom和Quake之类的突破性游戏。在最近的一次演讲中，John Romero（id的共同创始人）概述了公司的编程原则，该原则使他们可以在非常短的时间内用非常小的团队一个接一个地制作出如此多的高质量标题。
可以将其视为Lampson 关于系统设计的永恒论文的伴侣。许多原则是通用的，并且今天它们都非常相关。

 

Principle 1: Just do it (and do it well).

只要做到（做得好）即可。

这并不一定意味着您当前产品的版本过于复杂。实际上，这可能是描述迭代开发实践的一种方式。建立能够真正做好一件事情的东西，并不断对其进行改进。只需在每次迭代中保持较高的质量标准即可。

Principle 2: Keep your code always runnable.

使代码始终可运行。

在演讲中，Romero提到了当用户在加载精灵时遇到错误时，他们如何对代码进行编程以显示百吉饼的图像。通过添加良好的默认值/后备值，他们使游戏仍然可以玩。如果他们不这样做，则用户将被阻止，直到已修复该错误（即，损失了生产时间）。您可以想象，随着工程团队规模的扩大，这变得多么重要。一个实际的例子是在ReactJS中使用defaultProps。

 

Principle 3: Keep it simple.

保持简单。

这显然不是新颖的。称其为Occam的Razor或KISS原理，使事情尽可能简单是永恒的绝佳建议。

 

Principle 4: Invest time in building great tools.

投入时间来建立出色的工具。

罗梅罗在演讲中提到，他建立了一个名为TED的关卡编辑器。他花时间建造TED带来了可观的收益，因为它极大地帮助了他们通过提高生产力而迅速推出了一款游戏。从那时起，开发人员工具的爆炸式增长有助于提高开发人员的生产率。但是，如果没有现成的东西可以解决，请尝试确定内部工具是否可以帮助您的开发人员发挥最大的生产力（即使它可以从主要产品上夺走开发资源）。

 

Principle 5: Test your code thoroughly.

彻底测试您的代码。

这涵盖很多话题，作为最佳做法，许多最有效的工程团队的使用：（一）你的产品尽可能地内部测试; （b）不要委托他人（例如质量检查工程师，或更糟糕的是，客户）来查找代码中的错误；（c）编写尽可能多的测试以伴随您的代码。

 

Principle 6: Fix bugs as soon as possible.

尽快修复错误。

在日常站立期间，我们确保所有新错误具有最高优先级，并尽快得到修复。显然，并不是所有的bug都是一样的，因此这里需要进行一些与业务相关的判断。

 

Principle 7: Use a superior development system.

使用高级开发系统。

这是可能主要适用于游戏开发的一种。在其他情况下，在开发过程中进行测试时，您可能希望走另一条路。例如，您可能让用户在规格很差的移动设备上运行您的应用程序，或者他们可能正在通过高延迟2G连接访问您的Web应用程序。确保他们没有糟糕的用户体验。

 

Principle 8: Write code for this version of the product.

为此产品版本编写代码。

这主要是指“不要将过去的代码及其实现的限制转移到将来的代码中”。这与原则4是一种棘手的联系。作为工程师，我们通常很想从头开始“重写所有内容”。这是拥有经验丰富的工程领导者真正重要的地方。通常，选择大刀阔斧地进行新的实施可能会带来红利（类似于构建工具）。例如，当Slack开始扩展时，他们完全放弃了v1.0的实现，并迁移到全新的体系结构，获得了很多倍的回报。从Python到Elixir，我们也有类似的经验，拥有更强大的代码库和大大提高的开发人员生产力。

 

Principle 9: Use good component abstractions.

使用良好的组件抽象。

这真的很难。如果您曾经构建和维护过一个API，那么您就会知道正确实现它有多困难（尤其是第一次）。在演讲中，Romero给出了将火炬的功能与火焰和其他相关对象封装在一起的示例。如果他们需要在某个级别上移动或更新所有的火炬实例，则具有更精细的抽象可能会导致例如忘记移动/更新火焰。在此上花费了大量时间，尝试在第一时间解决问题，会在开发和调试时间上将获得更多回报。

 

Principle 10: Seek feedback from peers while coding.

在编码时征求同伴的反馈。

使用代码查看软件可以帮助解决此问题。对于产品中更复杂的部分，可能需要进行高级体系结构审查。无论如何，请确保您倡导重视交流和寻求反馈的文化。

 

Principle 11: Give coders creative freedom.

给予编码人员创新的自由。

切洋葱有很多方法。为您的编码人员提供创造性的自由，以提出自己的解决方案，以解决他们正在解决的问题。只需确保执行一些编码标准，以便团队中的任何成员都可以进入代码库。追求编码美学可能会浪费宝贵的时间，因此最好将其留给后代和自动格式化程序。这并不意味着不应该鼓励例如在代码审查中确定次优的实现。只关注客观上错误的事情。

 

原链 Programming principles from id software