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