整潔代碼
- 勒布朗法則：Later equals never.
- 不要以爲你會回過頭再去修改因爲各種原因而製造的混亂代碼，混亂的代碼最終會導致生產力的下降
- 整潔代碼不要重複代碼，提高表達力，只做一件事，小規模抽象
有意義的命名
函數
- 函數儘量保證短小，只做一件事，並且擁有自頂向下的閱讀順序（即：讓每個函數後面都跟着位於下一抽象層級的函數）
- 函數參數儘量少，參數不易對付，帶有太多概念性
- 面向對象編程原則（SOLID）：
- 單一功能原則，每個類中的功能平行沒有依賴
- 開閉原則，開放拓展，封閉修改，梅耶開閉原則提倡實現繼承，多態開閉原則相比提倡對抽象基類的繼承
- 里氏替換原則，派生類（子類）對象可以在程式中代替其基類（超類）對象
- 接口隔離原則，提供小而具體的接口，使系統解開耦合
- 依賴反轉原則
- 高層次的模塊不應該依賴於低層次的模塊，兩者都應該依賴於抽象接口
- 抽象接口不應該依賴於具體實現，而具體實現則應該依賴於抽象接口
註釋
- 註釋的恰當用法是彌補我們在用代碼表達意圖遭遇的失敗
格式
- 保持良好的代碼風格，代碼風格關乎溝通
- 關係密切的概念應該互相靠近
- 變量聲明應儘可能的靠近其使用的位置
- 若某個函數調用了另一個，應該放在一起，並且調用者儘可能放在被調用者上面
對象與數據結構
- 對象暴露行爲，隱藏數據，便於添加新對象類型而無需修改既有行爲，同時也難以在既有對象中添加新行爲；數據結構暴露數據，沒有明顯的行爲，便於向既有數據結構添加新行爲，同時也難以向既有函數添加新數據結構
錯誤處理
- 拋出的異常應當提供足夠的環境說明，以便判斷錯誤的來源和處所
單元測試
- 測試驅動開發，測試代碼和生產代碼一樣重要，應該保持整潔
- 遵循F.I.R.S.T規則
- Fast
- Independent
- Repeatable
- Self-Validating
- Timely
類
- 類應該短小，通過權責衡量類的大小
- 單一權責原則認爲，類或模塊應有且只有一條加以修改的理由
- 保持內聚性
系統
- 系統起始過程與起始之後的運行邏輯應當分離開
併發編程
- 併發編程執行模式
- 生產者消費者模型（生產者與消費者之間的隊列是一種限定資源）
- 讀者作者模型（平衡兩者線程需求，實現正確操作，提供合理吞吐量，避免線程捱餓）
- 宴席哲學家（進程競爭資源問題，會造成死鎖、活鎖、吞吐量、效率降低等問題）
- 關於同步（即加鎖）
- 加鎖來確保只有一個進程執行，代價是昂貴的，會造成延遲和額外開銷；
- 另外注意保護臨界區，通過擴展臨界區來保證同步，會造成資源競爭效率低下等問題，因此，儘可能減少同步區域
- 儘早考慮關閉問題，不要把系統錯誤歸咎於偶發事件