1. 軟件設計目標
<strong>幫助其它人</strong>，做與軟件相關的決策時，指導法則就是判斷能夠提供什么樣的幫助。一個人寫出優秀軟件的能力，完全取決于他在多大程度上理解了“幫助其它人”的思想。
- 確保軟件能夠提盡可能多的幫助；
- 確保軟件能夠持續提供盡可能多的幫助；
- 設計程序員能盡可能容易開發和維護的軟件系統，這樣的系統才能為用戶提供盡可能多的幫助，而且能持續提供盡可能多的幫助；
2. 關于未來
1.相比降低實現成本，降低維護成本更加重要
2.設計質量的好壞，正比于該系統未來能持續幫助他人時間的長度
通俗點就是，如果你的軟件只能在未來幾小時內提供幫助，就不需要花太多的功夫去設計，如果需要在未來10年內都能派上用場，就需要花很多精力去設計。
3.所以，軟件設計時最關注的應該是未來。但是，未來的某些事情，是我們所不知道的。程序員犯的最常見也是最嚴重的錯誤，就是在其實不知道未來的情況下去預測未來。
在軟件設計時，可以根據已知的信息去做某些決策，目的是為了創造更好的未來（提升價值、降低維護成本），而不必預測未來究竟發生什么具體的事情。
3. 關于變化
程序存在的時間越久，它的某個部分需要變化的可能性就越高；
關鍵在于，我們并不需要去預測有什么變化 ，我們知道的是，變化必然會發生，程序應該<strong>保證盡可能合理的靈活性</strong>。
回預某個特定文件修改歷史，問問自己，最初寫這個文件時，你能預測到這些變化嗎？是否一開始寫好就能夠減輕后期的工作量。總的來說，就是嘗試理解每次修改，看看能否從中得到一些關于軟件開發的新收獲。
軟件設計三大誤區
- 編寫不必要的代碼
不要編寫不需要的代碼，并且要刪除沒有用到的代碼。- 代碼難以修改（僵化設計）
* 對未來做太多假設
* 不仔細設計就開始編碼
* 設計程序時，應當根據現在知道的確切的需求，而不是我們認為未來會出現的需求。
- 過分追求通用；
- 僅僅根據目前確知的需求來考慮通用
- 如果設計讓事情變復雜而不是變簡單，就是在做過度工程
漸進式設計
漸進式開發
4. 缺陷和設計
最好的設計，就是能適應外界盡可能多的變化，而軟件自身的變化要盡可能的少
- 永遠不要"修正"任何東西，除非它真是一個問題，而且有證據表明問題確實存在；
- 避免重復
理想情況下，任何系統里的任何信息，都應當只存在一次或只存在一個地方；讓各處的代碼可以“使用Use”、“調用Call”、“包含Include”已有的其它代碼；
5. 簡潔
軟件的任何一部分越簡單，維護難度越小，成本越低。
簡潔是指某部分的代碼，而不是指整個系統。
- 簡潔是相對的
- 簡潔到什么程度？傻子也能看懂
- 保持一致
如果在一個地方采取了某種規則，就應當在其它每個地方都遵守這種規則，如變量命名方式等。 - 可讀性
- 空白：字符、代碼行之間留有合適的空白
- 命名：名字應該足夠長，能完整表達其意義或描述其功能，但不能太長影響閱讀
- 注釋：程序簡單的不能再簡單的時候，再添加注釋
6. 復雜性
以下情況會增加復雜性：
- 擴展軟件的用途：應當絕對禁止這樣做
- 新增程序員： 除非是高高手
- 做無謂的改變：需求變化、設計變化、代碼變化等，謹慎決策
- 困于糟糕的技術：先前采用的技術不能靈活地適應未來的需求
- 理解錯誤：越不理解自己的工作，就越容易設計出復雜的系統
- 糟糕的設計或不做設計：指的是“沒有為變化做設計”
- 重新發明輪子：不要什么都自力更生，使用成熟的輪子
復雜性及錯誤的解決辦法
需要反問的問題是：真正要解決的問題是什么？
-
問題復雜
解法不一定復雜；大多數麻煩的設計問題，都可以用在紙上畫圖或寫出來的辦法中找到答案。 - 應對復雜性
- 如果系統中某個部分太過復雜，有個好辦法可以解決：把它分解成幾個獨立的小部分，逐步重新設計；每次修改都應該足夠小，這樣可以放心動手，不會讓事情變得更復雜。
- 如果遇到不可解決的復雜性，在程序外面妥善包裝上一層，讓其它程序員更容易理解和使用
7. 測試
測試法則：
- 對軟件行為的了解程度，等于真正測試它的程度。測試程度包括：軟件有多個方面曾經測試過，上次測試是多久以前，在多少不同的環境下經過測試等。
- 必須保證測試是準確的，它的行為完全符合預期，測試結果必須有效。
