【第342期】优秀程序员是如何处理糟糕代码的

前言：

最近早读君改变了一种项目的开发方式，之前很喜欢在项目代码库中直接写，现在反而喜欢在本地都开发完之后在cp到项目库中，又返回到最早期的模式。

放假期间，早读君就不推送技术文了，推送些比较散的文章～

正文从这开始～

可能你一行不好的代码也从来没有写过。这是有可能的，但在现实中又不太可能。

现实情况是，和这个星球上的其他所有程序员一样，你会产出安全漏洞、UI元素偏移，等等等等的代码。这并不能说明你是一个不好的开发人员。只是因为你是人类而已——一种不可避免会犯错的生物。

正是这种每个开发人员都有的“人性”缺陷，驱使那些优秀的开发人员敢于承担代码和底层基础架构的不足，有准备有计划地行动。下面是他们将做的事情。

假设

几年前，Netflix开源了Chaos Monkey和Simian Army的其他部分（Simian Army是一套工具，用来管理基于云的软件）。从本质上说，Chaos Monkey的范围贯穿亚马逊Web服务的基础设施，能够随意终止实例。从根本上说，它是一种通过创建最坏的可能方案来做最坏打算的方法。

正如Netflix的CoryBennett和Ariel Tseitlin于发行之时在博客上这样写道，“代码会失败，并且你越不希望失败或一点也没有准备的时候，反而更加不可避免会出现故障。如果你的应用程序不能容忍实例故障，那么你是愿意凌晨3点被召唤呢还是在办公室里通宵？”

使用不可预测的方式来模拟故障，Netflix强迫注重基础设施的弹性。与其假设最佳的情形，还不如做一个最坏的打算。这样我们就能愉快地进入下一个进程了。

测试

上面我们说了一个提高基础设施的伟大方法，那么代码呢？

Jeff Atwood，一个程序员的答案是：“你需要折腾你的代码。”他写道：

我相信，每个专业程序员职业生涯的一个关键转折点，就在当你意识到你才是自己最大的敌人，以及减轻这种威胁的唯一办法就是接受它的时候。将自己当作最大的敌人。打破你的用户界面。打破你的代码。折腾你的软件。

在实践中，这意味着“程序员至少需要对常见错误有一定的了解，然而，很多程序员往往不会这么去做，甚至是反着来。”这意味着你作为“编程之神”的责任也包括成为“测试之神”，通过“折腾”代码积极地来消除里面的错误。

Andre Medeiros补充认为我们应该对调试“精益求精”，因为开发人员需要对他们的代码做更多的事情。

“为了防止bug，你写出来的代码得让任何程序员都觉得简单。为了修复bug，你得理解你的代码。为了精密地了解代码，你需要列举和验证你的假设，如果有必要，你还需要构建调试工具。”

贫民窟上的摩天大楼

当然，对于我们的代码，其最大的问题之一是，它继承了如此多其他的代码。特别是在已建立的企业中，我们常常构建在旧代码上，从而导致了各种后续延伸问题。

以下是Zeynep Tufekci的精彩描述：

将它比喻成造房子的话——也就说你将要在已经造好的底层基础上造二楼。但房子一开始造的时候并没有造好，没有打好地基，你也不知道哪面是承重墙。你只能尽可能地去猜，然后造好了一个楼层——用你的手指。然后你接着这样做。很多旧但控制着基础设施关键部分的软件系统就是这样运行的。在某一段时间内它也的确是可以工作，但每一个新楼层的建造意味着增加了更多的漏洞。我们正在代码中建设贫民窟上的摩天大楼——而且，还在地震区。

很显然，我们对于改善这种情况束手无策，除非我们能够致力于去除技术债务。

但也许，只是也许，在心甘情愿折腾代码的过程中，你会发现消除技术债务是如此之重要。

长按图片识别图中二维码