软件开发加速的秘诀：小步快跑 [译]
小步快跑，助你在软件开发中加速前行。
图片来源：Fernando muñoz 在 Unsplash 拍摄
虽然关于这个主题已经有很多讨论，但在配对编程实践中，这个观点仍然频繁出现，值得我们再次强调。
我将用音乐录制这个不同领域的例子来阐释这一点。作为一个业余吉他手，我尝试录制音乐。我通常会先大致拼凑出一首歌的框架——包括基础结构、和弦进行、旋律等，使用的是单一序列化乐器，比如一个优质的合成器音色。这大概需要我用掉一个下午的时间，完成一首 5 分钟长的音乐作品。
接下来，我会开始准备吉他部分——如果是那种风格的安排——并开始录制它们（音乐人通常称这个过程为“跟踪”。）
以复杂的吉他独奏为例；一个 16 小节的独奏大约持续 30 秒，速度约为每分钟 120 拍。你可能会认为一次就能录好。但实际并非如此简单。因为这是金属乐，要求极高，我努力做到最佳录音。
我可能会尝试将整个独奏一次性录制，但通常需要多次尝试才能得到满意的结果。甚至有时，我会特别喜欢第 3 次尝试的前 4 小节，第 6 次尝试的后 4 小节，以及第 1 次尝试的中间 8 小节。我可以将这些部分编辑在一起，现在这已经变得非常简单，创建一个“超级录音”，值得保存。
每次尝试都会消耗时间：如果我让我的音频工作站软件循环播放那 16 小节，每次录制一个新尝试，至少需要 30 秒。
为了得到我满意的录音，我花费了 6 次 30 秒（共 3 分钟）。
现在，设想如果我是按 4 小节的段落来录制这些尝试。每次尝试的持续时间将是 7.5 秒。为了让前 4 小节达到满意，我需要 3 次 7.5 秒（共 22.5 秒）。为了让最后 4 小节满意，我需要 6 次 7.5 秒（共 45 秒），中间 8 小节只需要 15 秒。
因此，以 4 小节为单位进行录制，我大约需要用 1 分钟 22.5 秒的时间。
虽然分段录制可能会增加一些额外工作量，但我发现，通过分解任务，我能更快地完成理想中的表演。
一个坚持纯粹表演的人可能会要求我一次性完整录制每个吉他部分。这其实就是现场表演的本质。但现场表演也有它的负担，比如排练时间。当我录制吉他部分时，实际上也相当于在排练。
现代数字录音技术让排练和表演的界限变得模糊。我家里有一个多轨录音室，可以随心所欲地录音，这就意味着我不必像过去那样为了节省昂贵的录音室时间而进行大量排练。
实际上，作曲、排练、表演和录音之间的界限已经完全消失。编程领域也是如此。
还记得编译器运行缓慢的日子吗？我们中的一些人甚至记得编译器运行在大型中央计算机上，可能要等待 15-30 分钟才能知道代码是否语法正确（更别说是否运行正常了）。
那个时代部分解释了为何“一次做对”需要大量前期工作，并促成了“设计”、“编码”和“测试”之间人为划分的现象，这种现象在今天的开发文化中仍然存在。
现在的情况是，我不再需要到计算机实验室去预约大型主机，就像我不需要去录音室预约音响工程师一样。我随时可以使用工具，成本几乎为零。因此，我可以进行各种尝试。说到底，无论是编程还是录音，本质上都是一种实验。
我们所做的一切都是实验。实验可能失败，因此我们可能需要反复尝试。一次又一次，直到获得满意的结果。
因此，如果我们要采取实验性、迭代性的方法，就必须分解成小块。因为更大的任务意味着更长的周期，更长的周期意味着我们不得不接受较差的结果——例如，前四小节可能不太理想，但在我们有限的时间里，这是六次尝试中最好的一次——或者我们需要花费更多时间来进行足够的迭代（电影导演称之为“覆盖”），以确保最终获得更多优秀作品。
这解释了为什么现场表演通常不如录音室表演那般完美无瑕，以及为什么大块头的软件开发往往耗时更长，或者成品不够理想。
谈到吉他演奏，曲目越是复杂和富有挑战性，我们就应该采取更小的步伐来演绎。例如，我可能可以一次性录制一个较长的布鲁斯摇滚曲段，因为演奏错误的几率较低。同理，在软件开发中，潜在的错误越多，我们就越需要小心翼翼，一步一个脚印地前进。
其实，这本质上是一个概率问题。如果我们一次只猜一个数字，那么猜出一个四位数的难度就会降低许多。