一、 重構，意識比技能更重要
如果問一個程序員：代碼爲什麼會變爛？他可能會找出無數種理由：
1、代碼本來就爛，我只是加了一點東西；
2、時間壓得太緊，根本沒有時間把代碼優化，功能實現出來就不錯了；
3、系統已經上線了，不敢隨便去改以前的代碼，不出問題還好，改出問題了誰負責；
……
但是，這都是從外部找原因推卸責任，程序員應該從自身尋找原因。其實，代碼變爛，罪魁禍首就是程序員自己。
很多時候，代碼一步步變爛，就是因爲程序員自己沒有良好的意識，沒有及時地重構，剛開始的代碼還是挺好的，後來需求一步步變更，就開始不斷地往裏面加分支，慢慢就變爛了。所以建立強烈的重構意識才是最重要的，頭腦裏要建立這樣的意識：一旦代碼變爛了，就去重構，要寫出高質量同時又優美易讀的代碼。
重構的技能每個人都可以學得會，但建立首先這樣的意識才是更重要的。
至於寫出好代碼卻不被上級知道和認可，也有相應的措施：推行代碼質量可視化。在公司或部門內部，通過sonar等系統實時地公佈各項目組和成員的代碼總體質量，使所有人都能看到，這樣就能讓領導看到代碼的改善，也促使更多的人建立寫出好的代碼的意識。
二、要簡潔短小職責要單一
不要在一個方法或一個類中堆砌太多的代碼，不管是方法還是類，都應該短小。過長的類或方法都是壞味道，它們會導致以下種種不快：
1、 代碼難以理解，難以維護。比如一個方法中包含10個邏輯，這時程序員要修改其中一個邏輯，那麼他不得不把這10個邏輯全部理解了才能動手修改，而且一大堆無關代碼堆砌在一起，導致程序員修改代碼時很容易出錯。而如果分成了10個小方法，那麼程序員就可以直接聚焦於要修改的那1個小方法就行了，修改也很容易。
2、 代碼難以重用，導致重複代碼。一個大方法中有一部分代碼，在另一個地方有同樣的處理，但是由於這部分代碼身處這個大方法的泥潭中，所以無法重用，那麼就只能拷貝一份了，這樣就導致了重複代碼，而重複代碼的危害是不言而喻的。
……
另外，不管是方法還是類，都應該遵循“單一職責原則”，否則不同的職責雜糅在一起，同樣導致以上的種種不快。所以，這句話很重要：函數的第一原則是短小，第二原則是短小，第三原則還是短小。
三、代碼是給人看的，應該寫人易讀懂的代碼
代碼是給機器去運行的，但更是給人看的，要寫出機器能運行的代碼很容易，但要寫出人易讀懂的代碼則更重要。建立這樣的意識之後，往往就能寫出非常整潔優美的代碼。
要怎樣寫出人易讀懂的代碼呢？
首先，還是上一條所說的，要簡潔短小，職責要單一，邏輯要清晰的區分開。不要把一大堆代碼堆砌在一起，更不要把不同職責的代碼堆砌在一起，那樣都必然導致可讀性下降。
然後，不要寫過於長的複雜表達式，那樣非常難以理解。可以把表達式進行分解，可以用解釋變量（只起到解釋的作用，就是爲了讓代碼更加易讀）。
還有，比如一個方法中包含10個重要的步驟，人要讀懂它很難。那麼可以把這個10個步驟提取到10個小方法中，然後給每個小方法起一個有意義的名字，讓人顧名思義一目瞭然，然後在原方法中依次調用這10個方法，程序員一看便知道這個方法幹了什麼。
提到有意義的名字，需要強調的是，在代碼中，不管是類、方法還是變量，一個好的名字都非常重要，起一個有意義的名字，讓人一看就知道它是幹什麼的，比多少註釋都有效。
有時爲了達到代碼整潔的目的，甚至可以犧牲一點點“性能”。這一點尤其令我印象深刻，故單獨列出來作爲第四個方面。
四、別爲了一丁點“性能”就犧牲掉整潔
這裏加了引號，是因爲這裏所說的“性能“，其實只是程序員的臆測。而這種臆測經常經常發生。
比如一個循環當中幹了兩件完全不相關的事情，使得不同職責的代碼雜糅在一起，影響了易讀性又不利於重用。其實應該分兩次做，即使做了兩次循環也沒有關係，除非有實際的測試數據證明，這樣做確實影響了程序的性能。但是其實大部分情況下，這並不會對性能造成影響。
應該時刻記住大師們的教誨：
- 別爲了一丁點"性能"就犧牲掉整潔
- "乾淨整潔的代碼往往運行起來更快，即使不快，也很容易讓他變快，讓乾淨的程序變快，比讓快速的程序變正確來得容易。"
- "過早的優化是一切罪惡的根源。"
由此可見，寫出人易讀懂的整潔的代碼是多麼重要。
以上幾種意識的無論怎麼強調都不爲過的重要性,我也將牢固建立這些意識,寫代碼的時候時刻從這些意識出發,不斷地持續地重構,只寫乾淨整潔的代碼。