【Translation】两种软件开发的方法论

"Algorithms we develop software by 的部分中文翻译。文章核心观点是开发软件的本质是通过在问题空间里寻找到相应的解决路径，而寻找解决路径可以以路径查找算法做比喻。"

这是对于 Grant Slatton 的博文 Algorithms we develop software by 的部分翻译。

原文的核心思想是开发软件的本质是通过在问题空间里寻找到相应的解决路径，而寻找解决路径可以以路径查找算法做比喻，即我们可以参考路径查找算法去寻找解决问题的方法。但是原文并没有做更为详细的解释，因此这篇翻译的标题我也改为《两种软件开发的方法论》了。并且删改了一些内容。

以下内容部分来自于大模型翻译，存在不少我的个人删改。

方法一：当你花了一段时间还没写完相应的代码的时候，删除重写，从头开始

我最近与一位科技公司CEO进行了交谈。我很喜欢听他描述他偶尔使用的一种软件开发方法论。其中，他的一种方法是“当你在一天里没能完成一个功能的代码，那么删除重写”。

他的意思是：

一天开始的时候就开始着手开发这个功能。如果到一天结束的时候还没有完成，就把之前做的全部删除，第二天重新开始。在这个过程里，你可以保留你编写的单元测试。
如果几天后你仍然无法实现该功能，请考虑你还要做哪些基础工作，还要重构哪些代码才能够实现相应的功能。再次使用这种方法来完成这些前置功能，然后再回到你原本计划的功能实现上。

据他所说，这是上世纪90年代末到本世纪初的极限编程（extreme programming）中发明的一种方法论。

译注：极限编程是最早的敏捷开发方法，核心是测试驱动开发。你可以把它认为就是敏捷开发。

我给初级工程师的建议也和该方法的思想类似：首先先尝试解决问题，然后将完成的代码保存到别的分支上，而后重写一遍代码——将所有代码写两遍。

我是在一次工作成果丢失后偶然发现了这个方法。重新编写解决方案只花了最初实现方案所需时间的25%，而且结果要好得多。因此，通过这样的方法，你可能会得到比原来高两倍质量的代码，而花费的时间只比原来多了25%。这种代价在我们的容忍范围内的。

当然，请注意，把代码写两遍并不是说把内容重复写两次。这是一种启发式的方法（heuristic）。

而上面所说的“每天从头开始”的方法是我这种方法的更极端版本。每次重写时，你都在为解决问题铺设更平滑的道路。最终的解决方案可以变得非常干净整洁。

斯大林曾经说过：“数量本身具有一种独特的性质。”我几乎可以肯定，这个关于斯大林的不可靠的引语同样适用于成为一名优秀的软件工程师。作为一名初级工程师，没有任何东西可以替代你编写的前10万行代码。“每天从头开始”的方法可以帮助你更快地达到这个目标。

你可能会认为多次重复处理相同的问题不如获取10万行不同代码那样有价值。我不同意这种看法。反复解决同一个问题实际上对于巩固你所掌握的模式知识非常有益。

是的，你只需要5000条完美代码就能看到所有主要模式。而剩下的95000条代码的意义是通过重复代码，反复刺激你的神经元，从而巩固你所掌握的模式知识。

方法二：枪顶脑门法，强迫自己在短时间里解决问题

我使用的另一个启发式方法适用于在提出解决问题的方法的场景。也许解决者会说需要他需要4周时间来解决该问题，这个时候我便会问他：“如果你的脑袋上顶着一把枪，而你必须在24小时内完成，那么你会怎么做？”

这里的目的是打破他们的思维框架和锚定偏见。如果你刚刚说某件事需要一个月的时间，那么说明你想到的是需要一个月时间的解决方案。然而可能会存在其他的、用时更短的解决方案，只是我们目前的视角没能在问题的解决空间里看到它罢了。

而我使用的这种技巧经常能奏效。事实上，有许多人都能在几分钟内想出只需要耗时一天便能解决问题的方案。并且，在实践中，解决时间成本为一天的解决方案实际上并不需要你花一天时间思考才能想到。枪并没有真的抵在你的头上。你可以回家睡觉。而新的解决方案往往可以在几天内完成。当你能够想出相应的短时间的解决方案时，你已经节省了远比原定的解决方案更多的时间。

总结来讲，这种方法便是：当你思考解决方案的时候，首先思考一个原始解决方案，而后设置一个非常低的成本上限，认为你的解决方案不能超出该成本，然后在这个限制下尝试思考是否存在这样低廉成本的解决方案。当你想出该方案时，你会发现它通常比你的原始解决方案更好。

总结

解决问题本质上是在问题空间中的路径规划。每一条路径都是一种解决方案，工程师的工作就是找到最好的那个。

因此，我们在思考问题的解决时，可以通过借鉴路径查找算法给我们相应的启发，例如迭代加深算法（iterative deepening）、受限松弛A* 算法（bounded relaxation A*）、定向搜索（beam search）、模拟退火（simulated annealing）等算法。我认为软件开发的方法论与这些算法存在某种模糊的联系。

我觉得试图将这个类比具体化可能没有太大意义，但从概念上思考它还是有价值的。不同的搜索算法各有优缺点，这取决于您对您的约束条件和对所处理领域的了解。

同样，工程开发上方法论的启发也是如此。成为一名更好的工程师本质上就是在问题空间中成为一名更好的路径规划者。

在这个领域可能存在一个令人信服的普遍理论，但这超出了本文的范围。你可以尝试思考一下这个问题，也许你会找到通往答案的好方法。

【END】