id software的编程原则

id software是如何在6年内只靠不到10个人开发28款游戏的

原文: https://blog.usejournal.com/programming-principles-from-id-software-bed83e762210

原作者：Alex Loukissas

译者：祝坤荣(时序)

作为1990年代最具标志性的视频游戏公司，id Software开发了如德军总部3D, Doom，雷神这样大名鼎鼎的游戏。在最近的访谈中(https://www.youtube.com/watch?v=KFziBfvAFnM)， John Romero(https://en.wikipedia.org/wiki/John_Romero)(id的合伙人)，介绍了他们公司的编程原则，就是这个让他们在很短时间内，用如此小的团队产出如此多高质量的产品。

可以将这个比作如Lampson在系统设计的timeless论文(https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/acrobat-17.pdf)一样。大多数原则是很常见的而到今天仍是有意义的。

每2.35月就有一个新游戏。哇哦

进过这些编程原则是针对视频游戏开发的，大部分也适用于常规的软件开发。在这篇博客，我会用我的思路来解释这些原则，并用Romero的幻灯片的截图作为引用。我也会尝试将游戏开发的原则普世化。

原则1：尽管做(并要做得好)

这不是代表要过度复杂化你产品当前的版本。实际上，这也是一种解释了迭代开发的实践。开发一样能将一件事做的很好的东西并不断的优化它。保证你在每个迭代中都有很高的质量要求。

原则2：时刻保证你的代码可运行

在访谈中，Romero提到他们是如何写了一段跳出一副图片的代码来处理用户遇到错误的场景的。通过加入好的缺省配置和容错，他们保证游戏仍然可以运行。如果他们没有做这些，用户在遇到bug时会不能玩下去，直到bug被修复(丧失生产力)。你可以想象到这对于一个逐渐变大的工程师团队有多重要。关于这点有一个实践的例子就是ReactJS中的defaultProps(https://reactjs.org/docs/react-component.html#defaultprops) 。

原则3：保持简单

这并不新奇。叫他Occam’s Razor(https://en.wikipedia.org/wiki/Occam%27s_razor)或者KISS原则(https://en.wikipedia.org/wiki/KISS_principle)，让东西尽可能的保持简单是永恒不变的好建议。

原则4：花时间打造伟大的工具

在他的分享中，Romero提到他打造了一个叫TED的关卡编辑器。他开发TED的时间收获了可观的利息，工具帮他们快速地一个接一个的交付了游戏，这极大的提高了生产效率。在那段时间，能帮助加速开发者生产力的开发者工具有爆发式增长。但如果手头没有货，可以尝试确认下是否一个内部工具可以帮你的开发者保持最高的生产效率(即使是这个工具开发需要从主产品线上占用资源)。

原则5：彻底地测试你的代码

这覆盖了大多数高效工程师团队的最佳实践: (a)尽可能多的吃你自己产品的狗粮(https://en.wikipedia.org/wiki/Eating_your_own_dog_food);(b) 不要委托别人(比如，QA工程师，或更糟，用户)来发现你代码中的bug；(c)尽可能的为你的代码写足够多的测试。

原则6：尽快修复bug

我们对这个非常严格(https://agentrisk.com/)，这是我们从我们上一次(https://en.wikipedia.org/wiki/Bugsense)创业(https://www.crunchbase.com/organization/maginatics)带过来的实践。在我们的日常站会，我们保证任何新bug有最高优先级并且尽快修复。很明显，不是所有的bug都是平等的，所以这里通过基于业务相关性的判断来决定。

原则7：使用优秀的开发系统

这条可能只针对游戏开发领域。在其他情况下，你想从开发转到测试阶段可能就会走一条不同的路了。比如，你可能想让用户在恶劣条件的移动设备上运行你的应用，或他们是通过高延迟的2G网络来访问你的web应用。确保他们没有一个糟糕的用户体验。

原则8：为产品的当前版本编写代码

这句可以翻译成“不要将超过限制的历史代码和实现转移到你的新产品上”。这条比较棘手并且一般跟原则4绑在一起。作为工程师，我们经常想要从头开始写。在这里有经验的工程领导力很重要。通常，选择尝试一种新的实现可以有不错的收益(就像开发工具一样)。比如，当Slack开始规模增长，他们将他们的V1.0实现整个迁移到一个全新架构(https://softwareengineeringdaily.com/2020/02/27/slack-frontend-architecture-with-anuj-nair/)，获得了很大收益。我们自己也有类似的经历，从Python迁移到Elixir,获得了一个更健壮的代码库和增长的开发效率。

原则9：使用好的组件抽象

这很难。如果你曾经开发并维护过API，你肯定知道如果将事情做对有多难(尤其是在第一次)。在他的访谈中，Romero举了一个将火炬与火焰和其他相关对象封装到函数的例子。他们需要移动或更新所有同级的火炬实例，如果是更细粒度的抽象会导致他们忘记更新/移动那些火焰。他们花了很多时间设计这个并想要在第一次做对。这些key8i在开发和调试阶段获得回报。

原则10：在编程是从同伴收集反馈

这里可以在开发时通过code review来解决。在产品里更加复杂的部分，可能需要高级架构师保证。在任何情况下，确保你是在鼓励交流和收集反馈的文化。

原则11：给与编码者创造的自由

切洋葱可以有很多方法。让你的编码人员有创造的自由，让他们使用自己的方案来解决他们面对的问题。只要确保执行同一种编码规范，这样团队中的任何人都可以快速熟悉代码库。对于编码美学的追求会浪费有价值的时间，所以最好将这个问题留给机器和自动格式化。这不表示在code review中发现次优实现不被鼓励。只是需要将精力放在那些明显的错误上。

感谢阅读！

我希望这篇文章能帮到你。下面是整个演讲的连接(https://youtu.be/KFziBfvAFnM)。我建议你也读一读 Masters of Doom(https://en.wikipedia.org/wiki/Masters_of_Doom)(译者注: 国内书名 Doom启示录)，这本书描写了id software更细节的幕后故事。感谢 Jon V 和 Diwaker Gupta对初始草稿版给予的建议。

---

微信公众号「麦芽面包」，id「darkjune_think」

开发者/科幻爱好者/硬核主机玩家/业余翻译/书虫

交流Email: zhukunrong@yeah.net