clean code

        我最近正在閱讀肯特.貝克的《implementation patterns》的序言。他說：「、、、這本書是創建在一個很是易碎的前提下：好的代碼、、、」。一個易碎的地基？我不一樣意。我認爲那個地基是健壯的、被支持的、滿載着我技藝中的地基的（我認爲肯特也知道）。我認爲好的代碼很重要，由於過去咱們已經由於好的代碼的缺乏花費了那麼多時間。

        我知道一個公司，在80年代，寫了一個「殺手級」應用。它很是流行，許多專業人士購買和使用它。但接下來應用發行週期開始變長。bug從上個版本遺留到下個版本。加載時間變長，崩潰次數增多。我記得那一天，我沮喪地關閉了那個應用，並從未再使用過它。很短的一段時間後，那家公司也停業了。

        20年後我遇到了那家公司的前僱員，並問他到底發生了什麼。回答證明了個人擔憂。他們匆忙的把產品推向市場，可是在代碼上是一團糟糕。當他們增長愈來愈多的功能時，代碼變得愈來愈糟糕以致沒法再管理。這就是壞的代碼，能夠把一個公司拖垮。

        你之前被壞的代碼妨礙過嗎？若是你是一個有些經驗的的程序員，那麼你應該遇到過幾回這種妨礙。事實上，咱們給他取了個名字，咱們叫他「跋涉」。咱們跋涉在壞代碼的水中。咱們在充滿荊棘和隱藏的陷阱的沼澤艱難前行。咱們努力尋找之後的道路，但願經過一些提示，一些線索。可是咱們所看到的是愈來愈多的無心識的代碼。

        顯而易見，你曾經被壞的代碼妨礙過。那麼，你爲何要寫它呢？

        你正在走的更快嗎？你正在匆忙前行嗎？也許是。也許你也曾經感受到本身沒有時間來作個好的工做。你的老闆也許會對你在整潔代碼上花時間而惱火。也許你僅僅是對這個軟件已經厭倦了，想盡快完結它。或者你看到這些積壓的許諾的要完成的工做，意識到必須儘快完成這個模塊以便進行下一個。咱們曾經也都這樣作過。

        咱們曾經看着咱們寫的一團糟的代碼，選擇放在那一些天。咱們也曾經感到欣慰，看着那一團糟的代碼，由於一團糟總比沒有好。咱們老是說，之後會再整理它們的。固然，那時，咱們並不知道勒布朗的名言：「之後等於永遠」。