代碼的高質量是軟件的靈魂，代碼? =? 數據結構? + 算法，? 而高質量的代碼? =? 優良的變量、函數命名? +? 優良的代碼結構、代碼層次結構?? +? 數據結構? + 算法。

時時刻刻想這上面的四點，你的代碼就會漸漸的上新臺階，老板不給你加工資還真的不行。

寫程序不僅要考慮編譯器能執行，更應考慮代碼是否有良好的可讀性。可讀性不僅僅是為了方便別人看你的代碼，就算是作者本人，在編寫新功能的時候，其實也會反復看自己之前的代碼。為了讓開發速度快，而放棄讓代碼保持高品質，其實只會反而拖慢開發速度。編寫當前功能的時候，這么做當然是會提高開發速度，但從全盤角度去看，當前的低品質代碼，會成為將來新功能的絆腳石。所以，提高代碼開發速度的辦法是提高代碼質量，花額外的時間重構美化自己的代碼，其實并不“額外”，它是保障代碼不會隨著新功能不斷增加，而慢慢腐壞最有效的方法。

??? “光把代碼寫好可不夠，必須時時保持代碼整潔。我們都見過代碼隨時間流逝而腐壞。我們應當更積極地阻止腐壞的發生。每次代碼簽入時，代碼都比簽出時干凈。”

??? “我們都曾經瞟一眼自己親手造成的混亂，決定棄之而不顧，走向新一天。我們都曾經看到自己的爛程序居然能運行，然后斷言能運行的爛程序總比什么都沒有強。我們都曾經說過有朝一日再回頭清理。當然，在那些日子里，我們都沒聽過勒布朗法則：稍后等于永不。”

????? 所以我們要保證只寫入高質量的代碼，永不對自己說“回頭再整理他們”。xp極限編程強調編碼過程有一個環節是“重構”。

????? 我們都知道代碼靈活的重要性，都知道糟糕代碼會帶來的維護惡果，在面對管理層的時間要求時，要求我們犧牲品質保證進度時，我們一定要堅持地說“不”！管理層不了解糟糕代碼的隱患，會覺得重構代碼是在浪費時間，但我們要堅持立場。就像病人對醫生說“醫生，你不要去洗手了，直接動手術吧，我沒有時間”，醫生不可能聽病人的意見，不去洗手一樣。醫生明白不消毒的后果，不可能聽病人的意見。同樣，我們明白犧牲代碼品質的危害，我們要堅守立場。

????? 如果背負時間的壓力，我們不應該以“犧牲代碼品質”來提高開發速度，犧牲代碼品質事實上只會拖累了自己以后的開發速度，我們應該想辦法“讓自己做得更快”。什么辦法？保持代碼的高質量。這是做得快的唯一方法。