神译局是36氪旗下编译团队，关注科技、商业、职场、生活等领域，重点介绍国外的新技术、新观点、新风向。

编者按：如何才能做好软件开发？这个问题仁者见仁智者见智。但The Hosk倒是给了我们一个比较独特的视角。他用网球比赛作为例子说明了二八定律的适用性。他说职业网球的取胜是靠主动得分，而业余网球的取胜是靠对手主动丢分。所以职业网球是赢家的游戏，而业余网球是输家的游戏。同样地，从事软件开发的80%都是业余玩家，所以关键是少失误，并就如何减少失误给出了自己的建议。原文发表在medium上，标题是：Software development is a loser’s game

划重点：

问题不在于代码会不会出错，而在于当代码会出错时如何用最简单的方式去修复

80%的软件开发者都是业余人士

专业人士主动得分，而业余人士靠对手丢分

快速写代码的最佳方法是关注质量和减少错误，而不是把代码写得更快

出色的代码不能拯救你，但糟糕的代码会杀死你

我的意思不是说开发者是失败者，但大多数软件开发人员都没能打败软件开发，而是被软件开发打败了。

开发者之所以会陷入困境，是因为他们不知道自己在玩什么样的游戏，或者不知道该用什么样的最略。

你需要知道软件开发是什么样的游戏，这样你才能玩得好。

在编写代码这个创造性的过程当中，问题不在于代码会不会出错，而在于当代码会出错时如何用最简单的方式去修复。

赢家与输家

在Charles Ellis的那篇《失败者的游戏》里，他指出职业网球是赢家的游戏，球员要赢取比分。业余网球采用了不同的获胜策略，那就是把球打过去，并让对手自己打败自己。

“在职业网球比赛当中，大约 80% 的分数是赢来的；在业余网球当中，大约有 80% 的分数是丢掉的。换句话说，职业网球是赢家的游戏，也就是说最终结果要由赢家的活动决定；而业余网球是输家的游戏，也就是说最终结果由输家的活动决定。这两种游戏的基本特征完全不同。二者是对立的。”

——Charles Ellis

大家都是打网球，但策略是否有效要取决于你跟谁玩

“专家网球就是我所说的赢家的游戏。胜利是因为比对手拿到了更多的分数——就像我们稍后将会看到的那样，不仅仅是靠拿到的分数比对手更高，而且是靠赢得分数来拿到更高的分数。Ramo发现，业余网球几乎完全不一样。那些业余的笨蛋很少能击败对手，但却一直在打败自己。这种网球比赛里面的胜利者得分比对手高，但他之所以能拿到更高的分数是因为他的对手的丢分更多。”

——Charles Ellis

软件开发的游戏

我在软件开发领域已经工作了 20 年，我跟很多软件开发人员一起参与过许多项目。我估计这些软件开发者当中有 80% 都是业余爱好者，有20% 是专业人士。

为什么会这么说？

业余软件开发人员不喜欢

• 规范标准

• 单元测试

• 设计模式/SOLID 原则（单一功能、开闭原则、里氏替换、接口隔离以及依赖反转）

• 学习和设置DevOps与 ALM（应用生命周期管理）（但喜欢用）

• 修复构建

• 代码审查

• 代码分析/解决方案检查

如果你把大多数的开发团队搞砸的话，就不会执行上述步骤，因为团队里面大多数的开发人员都不是专业人士。

“避免错误的办法是打得保守一点，尽量把球回过去，让对手有足够的空间去犯错，靠对方犯错来取胜，因为他，作为一名业余爱好者（并且可能没有读过Ramo的书），会玩一场输家的游戏而不自知。”

——Charles Ellis

大多数开发者低估了写代码，又高估了自己写能用的软件的能力。他们写代码的方法是假设写代码很容易，而且代码第一次就能跑起来。

业余爱好者

如果说大多数开发者都是业余爱好者的话，那我们就应该把软件开发者看作是在玩输家的游戏，并集中精力减少业余爱好者容易犯的错误。

业余开发者的目标是写代码，其他活动会减缓这个进程的速度。上面的另一个步骤是写出简单的代码，尽早发现错误，关注质量。ALM/ Devops可以实现快速无错误的部署，从而实现快速反馈。

快速写代码的最佳方法是关注质量和减少错误，而不是把代码写得更快。

项目/开发团队越大，bug、失误和错误的成本就越重要。大型团队出问题可能会耽误很多人，重点应该是通要采取上面列表所列的活动。

我曾参与过一些状况频出的项目。出现的错误扼杀了动力，在后期发现的错误让用户失去了信心，导致上线有风险。

倒置

如果我们把软件开发倒过来的话，那目标就不是写出能用的代码，而是花时间去避免写出低质量的代码，避免出错误。

尽量别犯愚蠢的错误，而不是尽量表现得很聪明，拥有长期优势的投资者正是凭借这点获得了难以想象的收益。

——查理·芒格

业余开发者相信代码写得快是写出生产就绪代码的最快方法。把方法写得太大太复杂的代码会创建这样一个代码库，其复杂性会不断增加，而且你每增加一行代码都会导致开发变得更加困难。这是一种只适用于一两个开发者去做的小型项目的做法。

bug的代价

发现错误的时间跟编写的时间离得越远，修复错误所需的时间就越长。比方说，如果你在生产环境下发现了一个错误的话，你得先理解，重现，然后开发者必须修复代码，并在每个环境下部署和测试，直到生产上线。

如果你在单元测试中发现了同样的错误的话，就可以更快地修复好错误，而且还减少了对其他开发人员和测试人员的影响。

我们可以给开发过程添加一些简单的步骤来捕捉错误，对于一场错误要花费大量时间修正而且会消耗客户信心的游戏来说，这是最有效的方法。

一旦知道了大多数开发团队都是很容易被自己打败的业余爱好者时，这样的做法就说得过去了：那就是开发团队要更重视阻止错误的发生，而不是假设每个人都是能写出出色代码的专业开发人员。

开发的成功不在于第一次就能写出正确的代码，而在于要避免各种失败的可能性。

“专业人士主动得分，而业余人士靠对手丢分。”

译者：boxi。

36氪APP让一部分人先看到未来