可能你一行不好的代码也从来没有写过。这是有可能的，但在现实中又不太可能。
现实情况是，和这个星球上的其他所有程序员一样，你会产出安全漏洞、UI元素偏移，等等等等的代码。这并不能说明你是一个不好的开发人员。只是因为你是人类而已——一种不可避免会犯错的生物。
正是这种每个开发人员都有的“人性”缺陷，驱使那些优秀的开发人员敢于承担代码和底层基础架构的不足，有准备有计划地行动。下面是他们将做的事情。
假设
几年前，Netflix开源了Chaos Monkey和Simian Army的其他部分（Simian Army是一套工具，用来管理基于云的软件）。从本质上说，Chaos Monkey的范围贯穿亚马逊Web服务的基础设施，能够随意终止实例。从根本上说，它是一种通过创建最坏的可能方案来做最坏打算的方法。
正如Netflix的Cory Bennett和Ariel Tseitlin于发行之时在博客上这样写道，“代码会失败，并且你越不希望失败或一点也没有准备的时候，反而更加不可避免会出现故障。如果你的应用程序 不能容忍实例故障，那么你是愿意凌晨3点被召唤呢还是在办公室里通宵？”
使用不可预测的方式来模拟故障，Netflix强迫注重基础设施的弹性。与其假设***的情形，还不如做一个最坏的打算。这样我们就能愉快地进入下一个进程了。
测试
上面我们说了一个提高基础设施的伟大方法，那么代码呢？
Jeff Atwood，一个程序员的答案是：“你需要折腾你的代码。”他写道：
我相信，每个专业程序员职业生涯的一个关键转折点，就在当你意识到你才是自己***的敌人，以及减轻这种威胁的唯一办法就是接受它的时候。将自己当作***的敌人。打破你的用户界面。打破你的代码。折腾你的软件。
在实践中，这意味着“程序员至少需要对常见错误有一定的了解，然而，很多程序员往往不会这么去做，甚至是反着来。”这意味着你作为“编程之神”的责任也包括成为“测试之神”，通过“折腾”代码积极地来消除里面的错误。
Andre Medeiros补充认为我们应该对调试“精益求精”，因为开发人员需要对他们的代码做更多的事情。
“为了防止bug，你写出来的代码得让任何程序员都觉得简单。为了修复bug，你得理解你的代码。为了精密地了解代码，你需要列举和验证你的假设，如果有必要，你还需要构建调试工具。”
贫民窟上的摩天大楼
当然，对于我们的代码，其***的问题之一是，它继承了如此多其他的代码。特别是在已建立的企业中，我们常常构建在旧代码上，从而导致了各种后续延伸问题。
以下是Zeynep Tufekci的精彩描述：
将它比喻成造房子的话——也就说你将要在已经造好的底层基础上造二楼。但房子一开始造的时候并没有造好，没有打好地基，你 也不知道哪面是承重墙。你只能尽可能地去猜，然后造好了一个楼层——用你的手指。然后你接着这样做。很多旧但控制着基础设施关键部分的软件系统就是这样运 行的。在某一段时间内它也的确是可以工作，但每一个新楼层的建造意味着增加了更多的漏洞。我们正在代码中建设贫民窟上的摩天大楼——而且，还在地震区。
很显然，我们对于改善这种情况束手无策，除非我们能够致力于去除技术债务。
但也许，只是也许，在心甘情愿折腾代码的过程中，你会发现消除技术债务是如此之重要。
译文链接：http://www.codeceo.com/article/good-programmer-deal-bad-code.html
英文原文：How Good Developers Deal With Bad Code
