注重軟體品質——讀《浮現式設計》有感

        題記：正在讀《浮現式設計:專業軟體開發的演化本質》(榮獲第19屆Jolt生產力大獎)一書，順手寫下了一點自己的感想與淺見，是以為記。

 

        封裝、內聚、耦合，這是編碼的首要原則。

        這三個原則不是物件導向開發才有的，早在面向過程的開發方法中就已經作為普適原則存在了，隨便問一位軟體工程師，都能對“高內聚，低耦合”說上幾句。到了物件導向方法中，對“封裝”的概念進一步得到強化，利用類的設計來封裝屬性和行為。

        到了實際的編碼過程當中，別說這三個詞的含義存在多少了，就是這三個詞本身還能不能想起來都不一定。

        對於封裝，看到最多的就是不會用public\protected\private，一律全是public，如果問一句為什麼，回答竟然是“也許別人也用得上這個方法”，汗！

        再來看內聚，對於類內聚，這裡最常見的問題是把相關的方法放到一起就定義一個類。這就不得不說到物件導向方法的優勢了，本來是通過類的定義來解決問題域到解域的映射，現在脫離了問題域來定義類，我們說這樣的內聚是不恰當的。對於方法內聚，當我們發現一個方法的名字與方法的內容不一致了，或者一個方法找不到合適的名字了，往往就是違背了內聚原則了。

        對於耦合，注意是低耦合而不是零耦合，如果沒有耦合就出不來軟體了。耦合有兩種，一種是有意耦合，是設計方案中確定的必然的耦合，另一種是意外耦合，不是經過設計的，而是悄悄潛入系統的耦合。但是，也要注意分辨有意耦合是否真的需要。我們在設計階段進行的設計驗證，很多時候就是在判斷這一點。

        以上是提高軟體品質的基本原則，還有軟體幾個軟體品質標準，即冗餘、可讀性、可測試性。

        冗餘是一些重複的程式碼片段，比較常見的就是所謂的剪貼簿繼承了，Copy一段代碼，不改或稍加修改即進入了產品庫，這樣的代碼產生的冗餘最終導致可維護性的降低，修改一處而忘了另一處。有些時候可以通過引入繼承耦合來減少冗餘，把公用代碼放到基類中，但也要注意上下文語意中是否允許。

        可讀性則強調代碼風格的一致性、命名的準確性等，記著，代碼寫成什麼樣機器都懂，但要寫出人能讀懂的，很難。

        可測試性現實當中我們也考慮的不多，但不管是否實施了單元測試，在設計代碼的時候如果能考慮到可測試性，其實也是在落封裝、內聚、耦合的原則，如果真的能把單元測試一起放到工程過程中來，則對軟體品質的提高無疑是事半功倍的。

——歡迎轉載，請註明出處 http://blog.csdn.net/caowenbin ——