讀書筆記：A Philosophy of Software Design （二）

接着上次的分享

設計兩次

這裏「設計兩次」的意思是不管設計一個類，模塊仍是功能，在設計的時候仔細思考，除了當前的方案，還有那些其它的選擇。在衆多設計中比較，列出各自的優缺點，而後選出最佳方案。就是對於設計方案，都有兩個或者兩個以上的選擇。

對於大牛而言，也許設計方案顯而易見，因而以爲沒有必要在不一樣方案中作遴選。然而這並非一個好的習慣，這說明，你沒有在處理更困難的問題，問題對於你而言太簡單了。這不是一個好的現象，由於上坡路老是很難走。當你面對困難的問題的時候，經過對不一樣設計方案的學習和思考，你會成長到更高的一個層次。

個人解讀：在管理理論上有一個叫彼得原理，就是「在一個等級制度中，每一個人趨向於上升到他所不能勝任的地位」。程序員也面臨一樣的問題，當你的經驗和資歷不斷的提升，你總會遇到你所不能勝任的問題，這個時候就須要經過不斷的學習，提升本身。固然也有可能所處的環境沒法給你更具挑戰的問題。這個時候你就須要考慮，你的下一站在哪裏？

爲何要寫註釋

困擾程序員的兩大世界性難題：

1. 別人的代碼沒有註釋
2. 別人讓我給個人代碼寫註釋

程序員一般有各類理由不寫註釋：

1. 好的代碼是自解釋的
2. 沒時間寫
3. 註釋很快就會和代碼不一致，形成誤解
4. 我讀的其餘人的註釋都毫無心義

個人解讀：其實開發過軟件的工程師都能理解寫註釋的重要性和意義，這並不須要不少的解釋。可是「懶惰」是原罪之一，我就是不想寫呀不想寫。

關於軟件開發的七宗罪，請閱讀AntiPatterns 

註釋應當用於描述代碼中不易理解的部分

若是你必定要對於顯而易見的部分增長註釋，那麼可能你是按代碼行數收取工資吧，固然，註釋也是算行數的。

選擇命名

給變量，類，模塊，文件起名字很難，真的很難。好的命名能使得軟件設計更容易理解，差的命名更容易產生Bug。

我就被坑過。仍是在某存儲公司的時候，負責開發一個軟件升級的規則模塊，根據不一樣的規則決定能不能升級。當時個人代碼release以後，發現客戶不能升級了。因而咱們在代碼中找Bug，後來發現，緣由是個人代碼判斷「hardware」字段來決定目標硬件類型是否匹配，而應該是另外一個和「hardware」命名很像的另外一個字段來決定要升級的硬件的類型。更糟糕的是，由於這個字段實在是比真正應該判斷的字段看上去更合理，進行代碼審查的人都沒能看出這個問題。而當時沒有測試環境可以實際匹配到這個硬件類型，這個問題也沒能在測試環節中發現。

註釋先行

在實現過程當中，把接口和註釋先準備好。

修改現有代碼

對於修改代碼，一樣面臨着「戰術性編程」和「戰略性編程」的挑戰，是以最少的修改完成任務，仍是以從新設計使得系統更合理的角度進行長線投資，須要仔細思考。

個人解讀：隨便改一些不相關的代碼，你可能會發現Bug神奇的消失了，軟件開發須要運氣，祈禱有的時候真的管用。

一致性

一致性在軟件設計裏很重要，包括：

1. 命名
2. 代碼風格
3. 接口
4. 設計模式
5. 常量

可使用如下的方法來保證一致性：

1. 文檔
2. 利用工具/代碼審查來強制
3. 入鄉隨俗
4. 不要隨便改變命名約定

代碼應當顯而易見

怎麼定義代碼是否是顯而易見，就是帶代碼審查的時候，若是有人認爲這的代碼不是容易理解，那麼這個代碼應該就是有問題的。也許這個代碼對你來講很直觀，可是代碼不是寫給本身看的。應該讓團隊裏的其餘成員也能讀懂你的代碼。

有一些使的代碼不易理解的元素：

1. 事件驅動模式 - 由於不知道事件流控制的順序
2. 範型 - 也許運行時才知道類型，形成閱讀的困難

個人解讀：最先曾在一家通訊企業作管理軟件開發，幾年後被要求修改本身多年前寫的代碼，讀了很久，愣是沒看懂。

軟件開發的趨勢

John對軟件開發重的一些趨勢和問題作了總結：

1. 面向對象，對於繼承，基於接口的繼承要優於基於實現的繼承
2. 敏捷，敏捷的一個潛在問題是致使「戰術性編程」爲主導，致使系統的複雜性增長
3. 單元測試
4. 測試驅動，測試驅動的問題是關注功能，而非找到最佳設計
5. 設計模式，設計模式的問題可能致使過分應用
6. Getter/Seeting， 這個模式多是冗餘的，也許不如直接暴露成員更簡單

爲性能作設計

關於如何在複雜性和性能之間的權衡，一般更簡單的代碼運行的更快。固然頗有可能更復雜和晦澀的代碼性能更高，例如彙編對比Python。設計的時候須要考慮的是爲了得到性能的提高，代價是什麼？這樣的代價是否是值得？

在爲了性能作出修改以前，先進行測量。針對關鍵路徑，找到影響性能的核心單元，作出性能改進的設計。

 

這本書的核心是關於「複雜性」的，軟件無疑是一個很是複雜的領域。對於致使複雜的緣由，我以爲John的觀點沒有問題，可是實際上還有不少更深層的緣由。軟件開發和人息息相關，離開人來說純軟件的東西，其實並不複雜，軟件開發中引發複雜性的更多緣由是更爲複雜的人，團隊，組織，和組織關係。這並非對該書的否認，這本書對於程序員來講仍是很好的一本書，值得一讀。