《程式員修煉之道》

注重實效的哲學

我的源碼讓貓給吃了

在所有的弱點中，最大的弱點就是害怕暴露弱點。

對于缺點、無知、錯誤，必須誠實。

負責

承諾的事情正确完成，無法完成，超出控制的事情不去承諾。

為結果負責，出現問題時應提供其他解決方案，不是尋找借口。

軟體的熵

低劣設計，糟糕代碼需要發現一個就修一個，否則會加速任何一個整潔，良好系統的腐爛。

破窗理論:一輛轎車放一星期無人理睬，一旦有一扇窗戶被打破，數小時之内車上裝置就會被搶奪一空

石頭湯煮青蛙

當大家都不願意做一件事時，自己先做，讓其餘人看見未來，就能聚集在自己周圍。

足夠好的軟體

欲求更好，常把好事更糟糕。-The King Lear

系統的功能和品質可以讓使用者參與權衡，不一定要十全十美才進行傳遞。使用者盡早使用而給出的回報，能讓系統引向更好的最終解決方案。

你的知識資産

知識會過期，價值會降低，自身價值也在降低

經營你的資産

定期投資：定期學習新知識，即使學的不多，因為習慣本身和知識總量同樣重要
多元化：掌握的技術越多，就能更好的進行調整，擁抱變化
管理風險：技術也存在高風險高回報，低風險低回報的情況，不要把技術雞蛋放一個籃子裡（個人了解：風險：學習需要花費的時間，回報：學習後産生的收益。高風險高回報的例如：作業系統，算法之類的計算機基礎。而低風險低回報的例如某個架構的使用，API的使用等）
低買高賣：在新技術流行之前學習它，但是這和找到被低估的股票一樣困難
重新評估與平衡：上個月的熱門技術可能下個月就非常冷門，要時常關注業内的新動向。

學習的機會

當發現自己不會的問題不要擱置，應該上網搜尋，去圖書館，去找出能找到答案的人。尋找答案的過程不僅可以建立人際網絡，也可以找到其他不相關問題的解決方案，都是很大的收獲。

批判的思考

對于學習到的知識要加上自己的思考，不一定每一個熱門技術都适合自己的項目。

交流

知道你想要說什麼

寫下想表達内容的大綱，并反複問自己，這些是否講清了我要說的所有内容？并反複修改

了解你的聽衆

你想讓他們學到什麼
他們對你講的什麼内容感興趣
他們有多少經驗
他們想要多少細節
你想讓誰知道這些資訊
你如何讓他們聽你說話

注重實效的路徑

重複的危害

如果你改變其中一處，你必須記得改變其他各處。這不是你是否能記住的問題，而是你何時忘記的問題。

正交性

不相依賴以及解耦，良好的系統中，改變資料庫不會影響界面，改變界面不會影響資料庫。

通過消除無關事務之間的影響來做到正交，可以帶來兩個好處提高生産率與降低風險

提高生産率

改動得以局部化，增加新代碼不用改變已有代碼
更好的複用
對正交的元件進行組合，生産率會微妙的提高。A元件能做M件事，B元件能做N件事，AB組合在一起就能做M*N件事。（這裡有一點中台的感覺）

降低風險

隔離：某個子產品出現問題不會擴散到其餘子產品，修複也更容易
更健壯：對某個子產品進行改動，出現的問題隻會出現在該子產品
可替換性：不會和特定産品、平台綁定在一起，第三方元件都被隔離在各自子產品

設計

如果顯著改變某個功能的需求，有多少子產品會受影響？正交系統中的答案是：一個。

編碼

每次編寫代碼都有破壞正交性的風險，需要時刻監視自己做的事。

代碼保持解耦
避免使用全局資料
避免編寫相似的函數

測試

每個子產品都應擁有自己的單元測試

可撤銷性

不存在最終決策，要把決策視為寫在沙灘上而不是刻在石頭上，大浪随時可能把它抹去。

注重實效的偏執

計算機簡短曆史中，沒人曾寫出一個完美的軟體，你也不大可能成為第一個

接受，擁抱并慶祝它，

要崩潰，不要破壞

當錯誤發生時，應該盡快抛出異常終止程式，而不是把錯誤資料寫進資料庫裡。

斷言式程式設計

如果一個情況不可能發生，就用斷言確定它不會發生

彎曲，或折斷

解耦與德墨忒爾法則

好籬笆促成好鄰居

間諜常會組成一個小組，小組内互相認識，但不認識小組外的人，如果某個小組被發現了，再多的審問也無法使其他小組的人暴露。

德墨忒爾法則

函數的德墨忒爾法則規定，任何方法調用都應該隻調用屬于以下情形的方法

public class Demeter {
    private void func(){}
    private Object selfObj;
    public void example(Object paramObj){
        Object methodObj = new Object();
        func();               //1.類自身的方法
        paramObj.toString(); 	 //2.傳入該方法的任何參數
        selfObj = new Object();
        selfObj.toString();   		//3.該方法建立的任何對象
        methodObj.toString();    //4.任何直接持有元件的對象
    }
}

當你編碼時

靠巧合程式設計

避免靠巧合程式設計，而要深思熟慮地程式設計。

怎樣深思熟慮地程式設計

總是意識自己在做什麼
不要盲目程式設計：不要建構不完全了解的系統，使用不熟悉的技術
按照計劃行事
依靠可靠事務：如果有無法特定的情形，就假定是最壞的情況
需要其他人知道的内容最好文檔化
為工作劃分優先級
不做曆史的奴隸：不讓已有代碼支配未來代碼，不适用的代碼都可被替換，是否重構取決于重構的影響小于不重構的影響

重構

何時重構

重複
非正交設計
過時的知識
性能

重構就像外科手術取惡性良性腫瘤，越早重構越安全

早重構，常重構

怎樣重構

不要在重構的同時增加功能
開始重試之前，確定擁有良好的測試

思考

首先承認自己永遠寫不出完美的軟體，也沒人能寫出
對于接手整潔的系統，要小心翼翼地維護，防止破窗效應
對于接手糟糕的系統，需要添加單測用例，然後排期逐漸重構
系統的設計與編碼實踐中，要注意正交性設計，盡最大可能地解耦
注意培養定期學習的習慣，哪怕學習的内容不多，習慣本身更加重要