您的位置：首页 > 其它

每 2.35 个月开发一款新游戏，这个公司是如何做到的？

2020-04-25 07:21 232 查看

以下为译文：

id Software 可能是 1990 年代最具标志性的视频游戏公司，开发了诸如《德军总部 3 D》、《毁灭战士4》和《雷神之锤》这样开创性的游戏。在最近的一次演讲中 John Romero （id 的联合创始人）概述了该公司的编程原则，这些原则使他们能够在非常短的时间内，凭借一个非常小的团队，一个接一个地创作出如此多高质量的作品。

这些原则和 Lampson 的一篇系统设计的论文（https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/acrobat-17.pdf）非常一致。许多原则是通用的，并且在今天它们也很有意义。每 2.35 个月就有一个新游戏

虽然这些编程原则主要针对视频游戏开发，但大多数原则都适用于一般的软件开发。在本博文中，我概述了我自己对这些原则的理解，并结合 Romero 自己幻灯片的截图作为参考，还概括了游戏开发之外的每一个原则。

我们开始吧。只管去做(并且做好)

这并不一定意味着将产品的当前版本过度复杂化。事实上，这可能是描述迭代开发实践的一种方式。建立一个真正做好一件事情的东西，并不断地在它上面改进，只要在每次迭代中保持高质量标准即可。保持代码始终可运行

在他的演讲中，Romero 提到当用户在加载精灵出现错误时，他们如何编写代码来显示一个百吉饼的图像。通过添加良好的默认 / 降级，他们使游戏仍然可以玩。如果他们没有这样做，用户将被阻塞，直到错误得到修复(即损失的生产力时间)。你可以想象当一个工程团队变得更大的时候，这是多么的重要。一个实际的例子是在 ReactJS 中使用 defaultProps（https://reactjs.org/docs/react-component.html#defaultprops）。保持简单

这显然不是什么新鲜事，可以称之为奥卡姆剃刀定律（https://en.wikipedia.org/wiki/Occam's_razor）或者 KISS 原则（https://en.wikipedia.org/wiki/KISS_principle）, 让事情尽可能简单是永恒的伟大建议。投入时间建立伟大的工具

在他的演讲中，Romero 提到他建立了一个叫 TED 的关卡编辑器。他花时间构建 TED 带来了可观的收益，因为它极大地帮助了他们通过提高生产力而迅速推出了一款游戏。从那时起，开发人员工具的爆炸式增长帮助提高了开发人员的开发效率。但是，如果现成的工具不能解决这个问题，试着确定一个内部工具是否能够帮助开发人员达到最高的生产效率(即使它能够从主产品上获得开发资源)。彻底测试你的代码

这涵盖了许多最有效的工程团队作为最佳实践所使用的主题：

尽可能对你的产品进行内部测试
不要委托给其他人(例如 QA 工程师，或者客户)来发现你的代码中的缺陷
为你的代码编写尽可能多的测试

尽快修复 bug

我们对 AgentRisk 的要求非常严格，这是我们以前的创业公司继承下来的做法。在我们的日常站会期间，我们确保任何新的错误有最高的优先权，并尽快得到修复。显然，并非所有的 bug 都是相同的，因此这里需要和业务结合起来判断优先级。使用高级开发系统

这是一个可能主要适用于游戏开发。在其他情况下，当涉及到开发过程中的测试时，你可能希望走另一条路线。例如，你可能让用户在一个规格非常低的移动设备上运行你的应用程序，或者他们可能通过高延迟的 2G 连接访问你的 web 应用程序——确保他们不会遇到糟糕的用户体验。为这个版本的产品编写代码

这主要意味着“不要将过去的代码及其实现的限制转移到未来的代码中”。这是一个棘手的问题，与原则 4 有某种联系。

作为工程师，我们经常想从头开始“重写一切”，这就是拥有经验丰富的工程领导能力的重要性。通常，选择冒险做一个新的实现会带来回报(类似于构建工具)。例如，随着 Slack 开始扩展，他们完全取消了v1.0的实现，转移到一个全新的架构，收获了多倍的回报。我们也有过类似的经历，从 Python 迁移到 Elixir，拥有更健壮的代码库，并大大提高了开发人员的生产力。使用好的组件抽象

这真的很难。如果你曾经构建并维护过一个 API，那么你就知道正确使用它是多么困难(尤其是在第一次使用时)。在他的演讲中，Romero 举了一个例子，把火炬的功能和火焰以及其他相关的对象封装在一起。如果他们需要移动或更新一个级别上的所有火炬实例，那么更细粒度的抽象可能会导致忘记移动 / 更新火焰。在这上面花费大量的时间，并且试着在第一次就把它做好，在开发和调试的时间里会有更高的回报。在编码时寻求同行的反馈

使用代码审查软件可以帮助解决这个问题。对于产品中更复杂的部分，可能需要进行体系结构预审。在任何情况下，确保你处在一种重视沟通和寻求反馈的文化氛围中。给程序员创造性的自由

切洋葱有很多方法，给你的程序员创造性的自由去想出他们自己的解决方案来解决他们正在工作的问题。只要确保执行一些编码标准，以便团队中的任何成员都可以跳转到代码库中。沉迷于编码美学可能会浪费宝贵的时间，所以最好把它留给碎片和自动格式化程序。这并不意味着不应该鼓励在代码审查中确定次优的实现，把注意力集中在客观上错误的事情上。谢谢阅读！

我希望本文对你有帮助。我建议你也读读《毁灭战士之主》(Masters of Doom) （https://en.wikipedia.org/wiki/Masters_of_Doom），该书以电子游戏公司id Software 创始人约翰·卡马克和约翰·罗梅洛为主线，介绍了该公司的历史及其对流行文化影响。非常感谢 Jon v 和 Diwaker Gupta 对初稿的反馈。

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

译者：明明如月，知名互联网公司 Java 高级开发工程师，CSDN 博客专家。

本文为 CSDN 翻译，转载请注明来源出处。
【END】 更多精彩推荐