原文：Simplicity Comes from Reduction
“这个重做…”
我老板一边说着一边把他的手指去按Delete键。当我的代码（一行一行的）灰飞烟灭后，我盯着电脑屏幕在哪发呆。
我老板，Stefan，并不总这样直言不讳，但他看得出什么是烂代码。并且他很清楚如何对付它。
我的定位是一名程序员初学者，体力充沛且富有激情，就是不知道如何变成。我有种可怕的思维倾向，即解决任何问题都是去某些地方增加变量，或者在行内throw。那是糟糕的一天，本来是要通过每次修改来优化这项逻辑的，但我的代码逐渐增大，越来越复杂，已经不能像原来一样工作了。
自然的，尤其是当你很焦躁的时候，本来只是想对现有代码进行最小修改，却越改越糟糕。大部分程序员都会维持烂代码，相比于恢复原状，重来明显要花费更多精力。对于那些可以正常工作的代码而言，这是正确的选择，但对于那些“跑飞”的来说，则无济于事。
浪费在挽救不良工作上的时间已经超出了它应有的。一旦某项事物变成了资源包袱，它就应该被抛弃。尽快！
并不是说所有的类型、命名、格式都简单粗暴的扔掉。我老板的反应太极端了，但它却是强迫我第二遍（偶尔第三遍）重新思考代码。当然，代码被无情地重构、转移或删除的机制，确实是修复烂代码的最佳方案。
代码应该简洁。应该最小化变量、函数、声明，以及其他必要语言语法的数量。多余的行、多余的变量…多余的任何事，确实，应该立即清除掉。剩下的那些足够完成算法或性能计算的工作即可。除此以外都是多余的，不必要的噪音，偶然的引入，掩盖了流程也隐藏了重要的内容。
当然，如果这样不行，那就把它们删掉并重来。通过这种方式抽出一个人的记忆，通常可以帮助消除大量不必要的混乱。
