75. 简单来自删减



简单来自删减

        “重做......”，我的老板一边对我说一边用手指重重地按着删除键。我看着电脑屏幕，随着我的代码一行又一行地消失于虚无，心里一种再熟悉不过的不祥预感。
        我的老板，Stefan，并不是总是直言不讳的人，但他看到不好的代码时，他是清楚的，并且他确切的知道对不好的代码应该做什么。
        作为一个程序员学生，我带着充足的精力和热情达到了现在的位置，但是对如果写代码却一窍不通。我有一个可怕的倾向，认为解决每个问题的方法都是在什么地方加上另外一个变量，或者插入新的一行。我的代码中的逻辑没有随着更新变得更好，而是渐渐变得更大、更复杂，远远难以持续一致地运行了。
        只愿在已有的代码块中做出最小的修改的愿望是很自然的，特别是在仓促之中，即使这个修改很难看。大多数程序员都会保留不好的代码，因为害怕重新开始需要付出更多的努力。对于差不多可以工作的代码来说这样是可以的，但有些代码的确是无可救药的。
        在拯救坏代码上花费的时间比本应该做的多太多了。一旦什么东西变得了资源陷阱的话，就应该取消它，尽快。
        并不是每个人都应该轻易丢弃所有的输入、命名和格式。我的老板的反应有点极端，但确实迫使我重新思考代码，再次（有时是三次）尝试。修改坏代码的最好方法仍然是毫不客气地重构、调整或者删除。
        代码应该简单。是应该有一个变量、函数、声明和其它句法语言必需元素的最小数量，但额外的行、额外的变量......额外的任何东西都应该被清除，立即清除。留下来的，应该只是刚好能完成任务、算法或计算的。任何其它的所有东西都是不需要的噪音，是意外引入的，会搅乱流程，遮掩重要的东西。
        当然，如果不管用的话，就直接删除它并重新输入一遍。从记忆中重新提取经常能够帮助消除很多不必需的混乱东西。

原文：Simplicity Comes from Reduction byPaul W. Homer