Factorio与软件工程

我现在已经做了一段时间的软件工程师了，我可以很有信心地说--这很有趣。它太棒了，我不会拿它换别的东西。它是如此有趣，以至于一些人试图捕捉最有趣的元素，并将它们放入游戏中。

我已经玩过两次这样的游戏了。第一个是深圳。这张照片看起来和在嵌入式设备上工作的工程师看到的很相似。您可以通过在低功耗设备上编写汇编代码来解决难题。这个游戏的伟大之处在于，它们去掉了编写和发布代码的烦人部分。

编辑-调试-编译循环非常快。再加上一个很棒的测试套件，意味着您可以立即尝试几个潜在的解决方案。

您的代码所依赖的平台(游戏本身)没有bug。在开始编写自己的代码之前，您不需要修复依赖项。

软件工程师应该扮演深圳的角色吗？这个游戏并不适合每个人。对一些人来说，这感觉太“像工作”了。在一天结束的时候，你想要放松，而不是去做那些感觉像你花了8个小时做的事情。尽管如此，我认为看看当需求清晰且开发工具快速时，任务会变得多么有趣，这是值得的。每个人都知道，在我们的方向和我们的工具上投资会有所帮助，但玩这个游戏的乐趣会强化这种感觉。

第二款游戏是上周五发布的Factorio，尽管它作为早期预览版已经推出了大约4年。那些玩过它的人现在可能正在挠头-这是一个关于建造工厂的游戏，而不是编码。你使用传送带、金属和石油产品来制作制造航天器所需的产品。

然而，这个游戏比其他任何游戏都更让我想起软件工程。让我解释一下原因。

技术债务。我们是暂时破解它，还是正确地实施它？答案一如既往--这要视情况而定。破解它让我们现在更接近我们的目标，但我们最终必须还清债务。新手玩家(就像我一样！)。开始用传送带将我们基地的各个部分连接起来，直到我们的基地看起来像意大利面，类似于维护不善的代码库。最终，我们学会了驯服这种复杂性的技术，因此我们的基础/代码库变得更容易推理。

不要重复你的话(干巴巴的)。其中一项技术是减少重复。如果您有多个地方需要的组件，您是制作一次就到处使用，还是在每个需要的地方复制粘贴？答案是“视情况而定”。作为一名工程师，您有时使用库，而有时复制粘贴。这取决于组件的复杂程度--一些功能可以复制粘贴，而一些复杂的功能可能不能复制粘贴。因此，在Factorio，某个组件(电子电路)在4-5个地方生产。我最终将它们全部替换为一个集中的生产阵列，以简化工厂。

缩放。这个游戏中重复的主题是构建生产阵列，然后发现我们需要3-5倍的吞吐量。头几次发生这种情况时，需要从头开始重做。在我们变得明智之后，我们开始设计具有纵向扩展空间的阵列。软件也是如此-我们的系统需要扩展到更多的用户，有时不需要太多警告。我们在设计系统时会牢记这一点。

重建。当我们在单人游戏或个人软件项目中重新构建组件时，我们通常不关心该组件或整个系统是否会短暂停止工作。虽然我和朋友一起玩多人游戏，所以我试着确保我正在工作的组件不会损坏其他任何东西。我创建了一个新的炼油厂系统，在旧客户退役之前将现有客户转移到新客户。零停机时间。

调试以查找根本原因。我们的工厂离完美还差得很远，所以我们一加东西，总会有东西坏掉。找到这些问题的根本原因是很棘手的，特别是当修复这些问题会导致其他问题时，比如玩打鼹鼠游戏。昨天的一个例子-我们没有足够的电力，所以我们加了更多的锅炉，但现在水管需要修理。那么水是可以的，但是我们没有足够的煤。那是真实生活的写照。

团队合作。只要有足够的时间，大多数事情都是可能的。但是和你喜欢的团队一起工作会更快更有趣。通过在团队中分担责任，我们能够快速行动。我们有一个石油人(我)，一个火车人，一个国防部长，以及其他角色。其他人不关心炼油厂系统的内部结构，只关心接口-他们使用输出，如果出现故障就告诉我。大型软件项目也是如此--不是每个人都能了解整个系统的错综复杂之处。相反，每个人都学习所有组件的API，而少数人负责实现。

灭火。有时很难实现新功能，因为我们要处理警报--这在软件工程团队中太常见了。典型的解决方案是让一名团队成员处理警报，而其余的团队成员则专注于添加功能。我们在游戏中也是这么做的。

但最重要的是，这个游戏是关于管理复杂性的。设计规范并实现符合该规范的系统。随着时间的推移维护和发展这个系统。

IMO，玩Factorio不会让你成为更好的软件工程师。但是如果你是一名软件工程师，你可能会发现这个游戏很有趣。相反，如果你擅长这个游戏，你应该给软件工程一个机会。