軟體質量，不僅僅依賴於專案架構和專案管理，同樣重要的是程式碼質量！！！

序

神在細節之中，其實幹什麼事都一樣，從小到大，一直明白一個道理：細節決定成敗！

軟體架構在開發中佔據重要地位。其次，巨集達建築的最細小的部分，比如關不緊的門、有點沒鋪平的地板，甚至是凌亂的桌面，都會將整個大局毀滅殆盡。這就是程式碼整潔之所道。

全員生產維護(TMP)，TMP的主要支柱之一就是5S原則體系，5S哲學包括以下概念：

• 整理：搞清楚事物之所在——通過恰當的命名——至關重要
• 整頓：每段程式碼都該在你希望它所在的地方
• 清楚：對於那種四處遺棄的帶註釋的程式碼，反映過往或期望的無註釋的程式碼，除之而後快
• 清潔：標準化，組內共識，使用一貫的程式碼風格
• 身美：自律，貫徹規程，樂於改進

我喜歡此書中的這句話：對於程式碼應無情的重構，寫出可讀的程式碼，重要程度不亞於寫出可執行的程式碼。我特喜歡無情兩個字，因為我總看不慣之前他人寫的亂七八糟的程式碼，想把事情做的盡善盡美。但其實實際情況是很糟糕的，在大部分並不懂技術的老闆眼裡，你能力的高低，就是看你是否能寫出可執行的程式碼，或者更精確的說是看你能否更快的寫出可執行的程式碼，老闆只注重結果，要能看到實實在在的東西，他並不會關心你是怎麼實現的，也不關心這些程式碼是否好維護。直到某天，程式碼亂成一鍋粥，想要改個東西，加個需求，已經舉步維艱的時候，我想已經晚了吧。哈哈哈。。。我認為真正牛逼的人，是以最快的速度寫出最高質量的可執行的程式碼！！！

在我眼裡，架構就好比建一個小區，架構師就是開發商，架構決定此小區是什麼檔次的小區，整個小區是什麼樣的格局，多大的樓距，綠化是否不錯，停車場是否夠大，大樓是否堅固，是否抗震，供暖，水電是否很好的接通。架構從根本上決定了整個專案。那麼專案管理呢，就好比是物業，管理的好，整個小區井井有序，那麼真正的程式開發人員，就是去每家每戶裝修設計的設計師，刷牆，裝玻璃，鋪地板，設計房間，只有你出手的東西美觀，整潔，那麼這一戶才能做到盡善盡美。所以說，一個專案，軟體架構，專案管理，高質量的程式碼，我們去對映到一個小區，開發商，物業，裝潢，我覺得再好不過了。如果這三項都無比優秀，那麼何愁這個專案不精緻呢？其實無論如何，要記住兩個字：“細節”

。

說來說去，最後謹記一點，無論架構還是程式碼都不強求完美，只求竭誠盡力而已。

書中的一句話，我們坦誠程式碼狀態，因為它永不完美。我們日漸成為完整的人，配得起神的眷顧，也越來越接近細節中的偉大之處。

前言

前言說的這幾段我真的很喜歡，因為無論做什麼事都是這樣：

習藝之要有二：知和行。你應當習得有關原則、模式和實踐的知識，窮盡應盡之事，並且要對其瞭如指掌，通過刻苦實踐掌握它。

我可以教你騎自行車的物理學原理。重力，摩擦力，角動量，質心等，用一頁寫滿方程式的紙就能說明白，有了這些方程式，我可以為你證明出騎車完全可行，而且還告訴你騎車所需的全部知識。即便如此，你在初次騎車時還是會跌倒在地。我再說的嚴重一點，讓你研究一年如何騎車，各種理論知識技巧，一年之後你第一次騎車還是會跌倒在地！！！

我們可以寫下整潔程式碼的所有“感覺良好的原則”，放手讓你去幹。那樣的話我們算是哪門子的老師？而你又會成為怎樣的學生呢？你必須自行實踐，且體驗自己的失敗。你必須觀察他人的實踐與失敗。你須看看別人是怎樣蹣跚學步，再轉頭研究他們的路數。你須看看別人是如何絞盡腦汁做出決策，又是如何為錯誤決策付出代價。

一定要認真閱讀第2部分！！！

我對此書充滿期待，開始閱讀的旅程吧！

第一章 整潔程式碼

1.1 要有程式碼

有人說程式碼會自動生產出來，不需要人工編寫，程式設計師沒用了，這完全就是扯淡！

程式碼確然使我們最終用來表達需求的那種語言。我們永遠無法拋棄必要的精確性——所以程式碼永存

1.2 糟糕的程式碼

其實隨著時間的推移，尤其趕著要推出產品，程式碼寫得亂七八糟，最後再也沒法管理這些程式碼了。最終導致的結果就是軟體越用越卡，崩潰機率越來越大，再那之後不久，該公司就關門大吉了。

為什麼要寫糟糕的程式碼？

就拿我們現實生活來說，大部分時候是為了趕時間，如果你做的慢老闆肯定會大發雷霆，或許我們想趕緊弄完手頭的事情，好接著做下一件工作。

我們都說過有朝一日再回頭清理我們寫過的爛程式碼，但是，再那些日子裡，我們沒聽過勒布朗法則：稍後等於永不。

1.3 混亂的代價

我經常會做重構他人程式碼的事情，有很多的程式碼寫的簡直混亂不堪，甚至匪夷所思，重構完的那一刻感覺是非常爽的，但是那個過程真是非常艱辛的！！！

隨著混亂的增加，團隊生產力也持續下滑，趨向於零。

1.3.1 華麗新設計

有一天，再也無法在這種令人生厭的程式碼上進行開發了，無奈組建新軍重新開發一套新系統。

很重要的一句話：花時間保持程式碼整潔不但有關效率，還有關生存。

1.3.2 態度

這種糟糕的情況經常存在：

• 要花好幾個星期來做本來幾小時就能完成的事情
• 只需做一行修改，結果卻涉及上百個模組

一句經典話：程式設計師遵從不瞭解混亂風險的經歷的意願，是不專業的做法。

1.3.3 謎題

趕上期限的唯一方法——做得快的唯一方法——就是始終儘可能保持程式碼整潔。

1.3.4 整潔程式碼的藝術

寫整潔程式碼，需要遵循大量的小技巧，貫徹刻苦習得的“整潔感”。這種程式碼感就是關鍵所在。

編寫整潔程式碼的程式設計師就像是藝術家，他能用一系列變換把一塊白板變作優雅程式碼構成的系統。

1.3.5 什麼是整潔程式碼

• 優雅，程式碼邏輯直截了當
• 從不隱藏設計者的意圖
• 便於他人閱讀和加以增補
• 看起來像是某位特別在意它的人寫的，幾乎沒有改進的餘地，程式碼作者什麼都想到了
• 沒有重複程式碼，包括儘量少的實體，比如類，方法，函式等
• 讓程式語言像是專為解決那個問題而存在

1.4 思想流派

書中很多建議都存在爭議，但是都是作者們長久苦思、從數十年的從業經驗和無數嘗試與錯誤中得來。好好學吧！

1.5 我們是作者

Javadoc中的@author欄位告訴我們自己是什麼人。我們是作者。作者都有讀者，我們一定要負責任！！！

讀與寫花費時間的比例為10:1，在寫新程式碼時，我們一直在讀舊程式碼。

所以，努力讓程式碼變的易讀吧！

1.6 童子軍軍規

讓營地比你來時更乾淨

1.7 前傳與原則

在本書中，你會發現對不同設計原則的引用

1.8 小結

沒啥說得了，迫不及待了，開始旅程

1.9 文獻

略

總結

其實第一章是一個類似講故事的章節，根本沒必要讀這麼細，還一小節一小節的都做記錄，但是我覺得作者的很多話說的很有深意，我喜歡，把他們記錄下來。希望日後翻過來看，我會感覺到很有趣！