clean code

        我最近正在阅读肯特.贝克的《implementation patterns》的序言。他说：“、、、这本书是创建在一个很是易碎的前提下：好的代码、、、”。一个易碎的地基？我不一样意。我认为那个地基是健壮的、被支持的、满载着我技艺中的地基的（我认为肯特也知道）。我认为好的代码很重要，由于过去咱们已经由于好的代码的缺乏花费了那么多时间。

        我知道一个公司，在80年代，写了一个“杀手级”应用。它很是流行，许多专业人士购买和使用它。但接下来应用发行周期开始变长。bug从上个版本遗留到下个版本。加载时间变长，崩溃次数增多。我记得那一天，我沮丧地关闭了那个应用，并从未再使用过它。很短的一段时间后，那家公司也停业了。

        20年后我遇到了那家公司的前雇员，并问他到底发生了什么。回答证明了个人担忧。他们匆忙的把产品推向市场，可是在代码上是一团糟糕。当他们增长愈来愈多的功能时，代码变得愈来愈糟糕以致没法再管理。这就是坏的代码，能够把一个公司拖垮。

        你之前被坏的代码妨碍过吗？若是你是一个有些经验的的程序员，那么你应该遇到过几回这种妨碍。事实上，咱们给他取了个名字，咱们叫他“跋涉”。咱们跋涉在坏代码的水中。咱们在充满荆棘和隐藏的陷阱的沼泽艰难前行。咱们努力寻找之后的道路，但愿经过一些提示，一些线索。可是咱们所看到的是愈来愈多的无心识的代码。

        显而易见，你曾经被坏的代码妨碍过。那么，你为何要写它呢？

        你正在走的更快吗？你正在匆忙前行吗？也许是。也许你也曾经感受到本身没有时间来作个好的工做。你的老板也许会对你在整洁代码上花时间而恼火。也许你仅仅是对这个软件已经厌倦了，想尽快完结它。或者你看到这些积压的许诺的要完成的工做，意识到必须尽快完成这个模块以便进行下一个。咱们曾经也都这样作过。

        咱们曾经看着咱们写的一团糟的代码，选择放在那一些天。咱们也曾经感到欣慰，看着那一团糟的代码，由于一团糟总比没有好。咱们老是说，之后会再整理它们的。固然，那时，咱们并不知道勒布朗的名言：“之后等于永远”。