一般而言，一个系统能用 5 年、10 年，甚至 20 年以上。但是某特定代码行以及某特定设计则往往比较短：当我们使用了不同的解决方法，其生命周期可能就只有几个月、几天，甚至是几秒种的时间。
有的代码就是比其他代码更重要
通过研究代码如何随时间变化，Michael Feathers 确定了代码库的功率曲线。每个系统都有代码，通常而言里面的很多很多代码，一次写好之后就永远不会变了的。但是还是有少量的代码，包括最重要和最有用的代码，会被一遍又一遍地改动、重构甚至是重头开始重写。
随着你对系统、问题领域以及架构方法方面经验的增长，就更加容易知道和预测什么代码总是需要改动的，什么代码是永远不会变的：有的代码就是比其他代码更重要。
我们是否应该写完美代码？
我们知道，我们应该写干净的代码，一致的、易于理解的且越简单越好的代码。
有些人因此而走向了一个极端，强迫自己尽可能地编写美丽优雅趋于完美的代码，着魔于重构，可着劲儿折腾每一个细节。
有的代码只需要写一次，以后就再也不需要作任何变动。但有些代码则并非如此，试想，这些需要不断改变的代码，代码写得那么完美却在下一秒就立马被 delete 不就太过浪费了吗？而且也没有必要这么做。
“你不用去写所谓完美的软件。不是禁止你，只是真的没有这个必要。好好想想，接受这个话。你需要明白完美的软件其实是不存在的。计算机发展到今天还没有人写的软件是完美的。你也不要自以为是地想去做第一个。除非你能接受这个事实，否则你最终只会是在浪费时间和精力，如果你想追求这个不可能实现的梦想。”
——Andrew Hunt，《The Pragmatic Programmer: from Journeyman to Master》的作者
一次就能解决的代码也不需要美丽和优雅，只要保证是正确的、容易理解的即可——因为这些不变的代码可能以后还要被多次读取。也不必非要是干净和紧密的——只需要干净即可。复制和粘贴等快捷方式在这类代码上是被允许的，至少在一定程度上可以这么做。这些代码不需要再重构（除非你需要改变这些代码），即使它周围的其他的代码一直在变化中。总之一句话，这些代码不值得我们在它身上花费额外的时间。
至于那些一直在变化的代码？苦苦思索最优雅的解决方案纯粹是在浪费时间，因为这段代码很可能在几天或者几周后就会被改写，甚至重写。
所以我们要关注的重点是：这些代码是否如愿运行——是否正确、实用和高效？是否能处理异常数据而不崩溃？——或者至少是否能做到即使失败也不会出问题？是否容易调试？是否能简单安全地改变？这些实实在在的措施才是成功与失败之间的分水岭。
编码与重构要务实
精益开发的核心思想是：不要浪费时间去做那些不重要的事情，包括写代码、重构、代码审查以及代码测试等多个方面。
只需要重构真正需要的部分就足够了——这也被 Martin Flower 称之为是机会主义的重构和有准备的重构。
关于代码审查也只需要专注于重要部分。这些代码是否正确？是否安全？是否可以运行？
不要在意风格（除非风格本身妨碍了我们的理解）。让 IDE 做主，格式化的照顾就 ok 了。我们不必去讨论代码还能不能更 OO，也不必一定要遵循某种样式，喜欢与否也没有关系，是否能用更好的方式解决也不重要——除非是你在教新手，并且需要做一些指导作为代码审查的一部分。
测试也要挑关键的来。测试要覆盖主要途径和重要的异常情况。无论是大型测试还是小而集中的测试，无论是写在代码之前还是之后，只要能起到作用就成。
这不仅仅是代码问题
软件开发总是在不断地更新迭代。哪怕现在看它的设计和代码是正确的，但是一段时间之后，它就会被要求改变或者直接被其他更好的所替代。
我们需要编写优良的代码：易于理解、正确以及安全。我们在重构和审查代码、编写有用的测试的同时也需要谨记：有些代码或者甚至是所有的这些代码，在不久的将来是要被抛弃的，或者永远也不会再被读取，或者再也不会被使用了。我们必须意识到，我们现在的一些工作将会成为无用功。做需要做的事情，仅此就够了。不要浪费时间去写所谓的完美代码。
作者：小峰
来源：51CTO
