软件工程是一场失败者的游戏

我最近对“赢家的游戏”和“输家的游戏”的概念很感兴趣。有很多很棒的文章深入解释了这个概念，但这里我简单总结一下：

1973 年，西蒙·拉莫 (Simon Ramo) 观察到，业余网球和职业网球的比赛获胜方式存在很大差异。

当两个业余选手比赛时，比赛的胜负往往不是胜者高超的技术，而是败者失误。败者经常犯非受迫性失误，比如将球击出界外、错失轻松击球或双误。换句话说，败者自食其果。败者“失”的分数比胜者“赢”的分数还多。这就是一场“输家的比赛”。

当两位职业选手比赛时，比赛的胜负主要取决于胜者的技术。双方球员都很少出现非受迫性失误。胜者击球精准，且表现优于对手，最终获胜。在这种比赛中，胜者“赢得”的分数远多于输者“失去”的分数。这就是一场“赢家的比赛”。

因此，如果你在玩一场输家的游戏，那么获胜策略就是尽量避免犯错，让你的对手打败自己。

（如果您以前打过网球或乒乓球，我希望您现在能点头表示认可。作为一名狂热的乒乓球运动员，我每天都会在办公室里看到这种情况。）

这条观察的应用在于，你应该尝试去理解你所参与的任何活动是赢家的游戏还是输家的游戏。获得这种理解能教会你如何参与这场游戏。

与软件工程相似

那么，如果我们把软件工程看作一场输家的游戏呢？也就是说，我们经常因为犯非受迫性失误和失误而自取灭亡。如果我们是业余选手，我们怎么才能让球留在场上而不是落入网中呢？

“如果你想变得优秀，就不要犯错”这句话说起来很简单，但这多少有点无益。这就像对贫困人口说：“你为什么不干脆别再穷下去了？”

如果我们把这个类比推得太远，那就毫无意义了。如果避免错误是软件工程的最终目标，那么最好的软件工程师是不是不写代码或什么都不做的人？显然不是。软件工程师的职责是编写代码，帮助实现某些产品，从而实现某些愿景（为企业赚钱、解决实际问题、简化任务等等），所以这一定是真正的最终目标。

因此，我们必须在创造有价值的产出和避免错误之间找到平衡。这引出了一个有趣的思考实验：我们在哪些方面会打败自己？又该如何避免犯下这些业余错误？

以下是我们可能犯的非受迫性失误的列表。我相信你也可以在这个列表中添加更多。

现在我们已经发现了一些潜在的非受迫性失误，那么我们该如何避免犯这些失误呢？

首先，我们可以采取一些安全措施，帮助我们在错误造成巨大损失之前发现并纠正它们。所有代码仓库都应该配置代码检查工具、代码格式化程序和一套自动化测试。这些安全措施可以作为持续集成 (CI) 流水线的一部分，在允许任何代码合并之前运行。

在编写代码时，我们也可以更加注重细节。创建合并请求后，在请求他人审查代码之前，我们应该始终进行自我代码审查。我们也应该始终手动验证我们的更改。

对于代码审查员来说，没有什么比审查别人的代码更令人沮丧的了，因为这些人显然自己没有做过这些检查。代码审查员需要发现一些简单的错误，例如注释掉的代码、格式错误、单元测试失败或代码功能损坏，这浪费了他们的时间。所有这些错误，代码作者或持续集成 (CI) 流程都可以轻松发现。

当合并请求频繁出现错误时，代码审查流程就会变成一个由少数资深工程师充当把关人的把关过程。这种不利的情况会造成瓶颈，降低团队的开发速度。它还会损害代码审查的更高目标——知识共享。

我们可以使用清单和合并请求模板来提醒自己需要仔细检查的事情。你审查过自己的代码吗？你编写过单元测试吗？你根据需要更新过任何文档吗？对于前端代码，你是否在公司支持的每个浏览器中验证过你的更改？你是否确保所有面向用户的文本都已翻译？你是否确保用户界面符合无障碍标准和指南？

通过借助自动化工具亲自执行这些检查，我们更加展现了专业精神，也更加尊重我们的同事。信任会增进，速度也会加快。关键在于勤奋和自律。

软件工程是一场输家的游戏。所以，让我们学会如何玩转这场游戏，不再输给自己。