注重實效的哲學
我的原始碼讓貓給吃了
在所有的弱點中，最大的弱點就是害怕暴露弱點。
對於缺點、無知、錯誤，必須誠實。
負責
承諾的事情正確完成，無法完成，超出控制的事情不去承諾。
為結果負責，出現問題時應提供其他解決方案，不是尋找藉口。
軟體的熵
低劣設計，糟糕程式碼需要發現一個就修一個，否則會加速任何一個整潔，良好系統的腐爛。
破窗理論:一輛轎車放一星期無人理睬，一旦有一扇窗戶被打破，數小時之內車上裝置就會被搶奪一空
石頭湯煮青蛙
當大家都不願意做一件事時，自己先做，讓其餘人看見未來，就能聚集在自己周圍。
足夠好的軟體
欲求更好，常把好事更糟糕。-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.任何直接持有元件的物件
}
}
複製程式碼當你編碼時
靠巧合程式設計
避免靠巧合程式設計，而要深思熟慮地程式設計。
怎樣深思熟慮地程式設計
總是意識自己在做什麼 不要盲目程式設計：不要構建不完全理解的系統，使用不熟悉的技術 按照計劃行事 依靠可靠事務：如果有無法特定的情形，就假定是最壞的情況 需要其他人知道的內容最好文件化 為工作劃分優先順序 不做歷史的奴隸：不讓已有程式碼支配未來程式碼，不適用的程式碼都可被替換，是否重構取決於重構的影響小於不重構的影響
重構
何時重構
出現重複性程式碼 非正交設計 過時的知識 效能不好
重構就像外科手術取腫瘤，越早重構越安全
早重構，常重構
怎樣重構
不要在重構的同時增加功能 開始重試之前，確保擁有良好的測試
結論
首先承認自己永遠寫不出完美的軟體，也沒人能寫出 對於接手整潔的系統，要小心翼翼地維護，防止破窗效應 接手糟糕的系統，需要新增單測用例，然後排期逐漸重構 系統的設計與編碼實踐中，要注意正交性設計，盡最大可能地解耦 注意培養定期學習的習慣，哪怕學習的內容不多，習慣本身更加重要