我们用来开发软件的算法

最近，我与一位杰出的 CEO 兼工程师进行了一次谈话。我很喜欢听他描述他偶尔使用的一种软件开发方法，这让我开始思考其他启发式和概括性的方法。

他的方法

每天早上开始着手开发一个功能。如果一天结束时没完成，就把所有代码删除，第二天重新开始。你可以保留写好的单元测试。

如果过了几天，还不能真正实现这个功能，那就想想需要做哪些基础工作、基础架构或重构才能实现它。

他说这不是他发明的，但与 90 年代末和 00 年代初的极限编程运动有些相似。

我经常给初级工程师的建议是：把所有代码写两遍。先解决问题，然后把代码暂存到一个分支上，再重新编写所有代码。

我是在偶然的情况下发现这种方法的。有一次，我的笔记本电脑坏了，几天的工作都丢失了。重新写解决方案时，只用了最初实现的 25% 的时间，而且最后的结果要好得多。

因此，你可能会用 1.25 倍的时间获得 2 倍质量更高的代码——对于那些需要长期维护的项目来说，这通常是个不错的选择。

注意：显然，不是说要 字面上 把每一行代码都写两遍。这只是一个启发式建议，要灵活运用。

“每天重新开始”的方法是这种建议的一个更极端的版本。每次你重写代码，都会为解决方案开辟一条更顺畅的道路。最终的解决方案可能会变得非常、非常简洁。

这句几乎可以确定是杜撰的斯大林名言，在成为优秀的软件工程师的过程中是非常适用的。作为一名初级工程师，没有任何替代方案可以让你快速完成前 10 万行代码的积累。“每天重新开始”的方法可以帮助你更快地达到这 10 万行。

你可能会认为，反复做同样的事情并不如写 10 万行多样化的代码有价值。我不同意。反复解决同一个问题实际上对巩固你所发现的模式非常有益。

你只需要 5000 行完美的代码就可以看到所有主要的模式。剩下的 9.5 万行只是重复训练你的神经元连接。

另一个我常用的启发式方法是：让某人想出一个问题的解决方案。也许他们会说需要四周来实现。我接着说：“如果有枪指着你，你必须在 24 小时内完成，你会怎么做？”

这个问题的目的是打破他们的思维定式和锚定偏差。如果你刚刚说某事需要一个月的时间，那么要在一天内完成必然需要一个完全不同的解决方案。

令人惊讶的是，这个技巧经常有效。很多人——在刚给出一个月的计划后几分钟——往往能够被激发出一个可能在一天内完成的计划。

实际上，这些一天内完成的计划通常也不是一天，枪并不是真的指着你的头，你可以回家睡觉。但这个新的解决方案通常只需要几天就能完成。一个十分钟的思维实验，可能会带来 10 倍的时间节省。

这个思维实验的目的并不是生成真正的解决方案。它的目的是给解决方案设定一个下限。然后，你在这个下限的基础上思考一个真实的解决方案，往往会发现它比你最初的解决方案更好。

问题的核心在于在问题空间中寻找路径。每条路径都是一个解决方案，而工程师的任务就是找到最好的那条路径。

这些启发式方法和不同的寻路算法之间有很多简略的类比。它们与iterative deepening, bounded relaxation A*, beam search, simulated annealing 等算法都有一些关联。

我认为试图将这种类比具体化不会有太多收获，但从概念上考虑它是有价值的。所有不同的搜索算法都有不同的优缺点，这取决于你的限制条件和领域知识。

工程启发式也一样。成为一名更好的工程师，就是成为一名在问题空间中寻找路径的能手。

在这个领域里，或许可以构建出一个引人入胜的通用理论，但那已经超出了这篇文章的范围。让你的大脑开一个后台线程，思考这个问题。也许你会找到通向答案的好路径。