二、注重實效的途徑 1.
重複的危害
dry原則
系統中的每一項知識都必須具有單
一、無歧義、權威的表示。
dry –don』t repeat yourself
不要重複你自己。
與此不同的做法是在兩個或更多地方表達同一事物。如果你改變其中一處，你必須記得改變其他各處。
重複是怎樣發生的：
1） 強加的重複
解決辦法：資訊的多種表示
**中的文件，糟糕的**才需要許多注釋，不可信任的注釋比完全沒有注釋更糟糕。
文件與**，一致更新。
語言問題，應該用標頭檔案記載介面問題，用實現檔案記載**的使用者無須了解的實際細節。
2） 無意的重複
在可能的情況下，應該總是用訪問器函式讀寫物件的屬性，這將使未來增加功能變得更容易.
訪問器函式的使用與uniform access原則緊密相關,該原則規定:模組提供的所有服務都應能通過統一的表示法使用,該表示法不能洩漏它們是通過儲存,還是通過計算實現的.
3） 無耐性的重複
「欲速則不達」
4） 開發者之間的重複
鼓勵開發者相互進行主動的交流,設定論壇,用以討論常見問題,讓某個團隊成員擔任專案資料管理員,其工作是促進知識的交流.
提示12 make it easy to reuse 讓復用變得容易
你所要做的是營造一種環境,在其中要找到並復用已有的東西,比自己編寫更容易.
2.正交行
在計算技術中,該術語用於表示某種不相依賴性或是解耦性,如果兩個或更多事物中的乙個發生變化,不會影響其他事物,這些事物就是正交的,在設計良好的系統中,資料庫**與使用者介面是正交的.
非正交系統:非正交系統的改變和控制更複雜.
提示13 消除無關事物之間的影響.
正交的好處：
提高生產率，改動得以區域性化，所以開發時間和測試時間得以降低，還可以促進復用，對正交的元件進行組合，生產率會提高；
降低風險，將問題侷限在該區域中；
工作中應用正交原則的幾種方式：
專案團隊，正交性團隊效率更高；
設計，設計正交的系統，系統應該由一組相互協作的模組組成，每個模組都實現不依賴於其他模組的功能，有時，這些元件被組織為多個層次，每層提供一級抽象。問自己「如果我顯著地改變某個特定功能背後的需求，有杜少模組會受影響？」，在正交系統中，答案應為乙個。「不要依賴你無法控制的事物屬性」.
工具箱與庫，在引入第三方工具箱和庫時，要注意保持系統的正交性。
編碼：讓你的**保持解耦（編寫羞怯的**）
避免使用全域性資料
避免編寫相似的函式，重複的**是結構問題的一種症狀（參考strategy策略模式）
批判自己的**，並重構（refactoring）
測試 p42，正交地設計和實現的系統也更易於測試 文件
認同正交性，正交性與dry原則緊密相關，運用dry原則，你是在尋求使系統中的重複降至最小；運用正交性原則，你可降低系統的各元件間的相互依賴
挑戰：考慮windows上見到的面向gui的大型工具盒在shell提示下使用的短小，淡卻可以組合的命令列實用工具，哪一種更為正交？
多重繼承或多重介面對正交性的影響？
3.可撤銷性
there are no final decisions 不存在最終決策
靈活的架構：corba挑戰
「薛丁格的貓」量子力學 4.
曳光彈
曳光彈比費力計算更可取，反饋是即時的，而且因為他們工作在與真正的彈藥相同的環境中，外部影響得以降至最低。
在黑暗中發光的**
提示15 用曳光彈找到目標
曳光**並非用過就扔的**：你編寫它，是為了保留它，它含有任何一段產品**都擁有的完整的錯誤檢查、結構、文件以及自查，只不過功能不全而已。
曳光開發與專案永不會結束的理念是一致的：總有改動需要完成，總有功能需要增加，這是乙個漸進的過程。
優點： l
使用者能夠及早看到能工作的東西 l
開發者構建了乙個他們能在其中工作的結構 l
你有了乙個整合平台 l
你有了可用於演示的東西 l
你將更能夠感覺到工作進展
曳光彈並非總能擊中目標
你要調整準星，知道完全擊中目標為止，這正是要點所在。
曳光** vs 原型製作
原型製作生成用過就扔的**，曳光**雖然簡約，但卻是完整的，並且構成了最終系統的股價的一部分，你可以把原型製作視為在第一發曳光彈發射之前的偵察和情報蒐集工作。 5.
原型與便箋
原型的設計目的就是回答一些問題，可以忽略不重要的細節
應製作原型的事物：
任何帶有風險的事物，以前沒有試過的事物，或是對於最終系統極端關鍵的額事物，任何未被證明的，實現性的，或有疑問的事物，任何讓你絕得不舒服的事物，可以為下列事物製作原型： l
架構 l已有系統的新功能 l
外部資料的結構或內容 l
第三方工具或元件 l
效能問題 l
使用者介面設計
原型製作是一種學習經驗，其價值並不在於所產生的**，而在於所學到的經驗教訓，那才是原型製作的要點所在
提示16 prototype to learn 為了學習而製作原型
怎樣使用原型： l
在構建原型時，可以忽略那些細節？ l
正確性，使用虛設的資料 l
完整性
l健壯性，錯誤檢查可能不完整 l
風格 製作架構原型： n
主要組建的額責任是否得了良好定義？是否適當？ n
主要元件間的協作是否得到了良好定義？ n
耦合是否得以最小化？ n
你能否確定重複的潛在**？ n
藉口定義和各項約束是否可接受？ n
每個模組在執行過程中是否能訪問到其所需的資料？是否能在需要時進行訪問？
怎樣「不」使用原型
如果所在環境或文化中，原型**的目的有可能被誤解，也許最好還是採用曳光彈方法，你最後將得到乙個堅實的框架，為將來的開發奠定基礎。 6.
領域語言
提示17 靠近問題領域程式設計
更靠近問題領域，通過在更高的抽象層面上編碼，或得專心解決領域問題的自由，並且可以忽略瑣碎的實現細節。
7.估算
估算，以避免發生意外
你解答問題的語境是什麼？所有的估算都以問題的模型為基礎。
估算來自**
估算訣竅：去問已經做過這件事情的人，仔細在周圍找找也曾處在類似情況下的人。
理解提問內容
建立系統的模型，建立粗略、就緒的蘇偉模型骨架
把模型分解為元件
給每個引數指定值
計算答案，保留奇怪結果的答案，助於對問題或模型的理解
追蹤你的估算能力，分析與結果差距的原因
估算專案進度 l
檢查需求 l
分析風險 l
設計、實現、繼承 l
向使用者確認
提示19 通過**對進度表進行迭代
「我等會兒回答你」
讀《程式設計師修煉之道 從小工到專家》後
一 從思想上做到注重實效的程式設計師 1 面對自己的弱點，敢於負責，取代找各種理由 2 決心寫出整潔的 3 做乙個模範的領導者，而不是一味要求別人怎麼做 4 適可而止，完成別人要求的下一步 5 時刻保持學習的熱情，規劃好每段時間的內容，學會傾聽 二 成為注重實效的程式設計師的途徑 1 不要重複 2 ...
程式設計師修煉之道 從小工到專家
在專案開始之前 需求需要挖掘，而不僅僅是收集。找出使用者為何要做特定事情的原因，而不是他們目前做這件事情的方式。建立需求文件 把形式化的模板做備忘錄 好的需求文件會保持抽象 專案範圍的增大需要被記錄和可追溯，以及可評價 通過統計資訊 需求的收集和設計實現不是單向的線性關係，而是雙向關係。它們是 交付...
程式設計師修煉之道 從小工到專家
基本工具 構建自己的工具庫。使用原始碼控制。除錯bug 找到問題根源 可以快速 復現 bug。跟蹤。向別人解釋程式以找到問題所在。找bug範圍 先自己 確定無誤再找類庫或系統問題。不要固執的認為自己的 沒問題。不要假設，要驗證。注重實效的偏執 放棄寫出完美軟體的偏執。進行防禦性程式設計。合約。規定 ...