淺談程式設計

一段程式碼能正常Run,沒有BUG,這就代表這段程式碼沒有問題，是一段良好的程式碼了嗎？沒有BUG,能執行,這不代表這段程式碼是一個好程式碼.

或者說評價一個程式碼的好壞,其指標或者說原則應該是多元的,不僅僅是能Run,並且沒有BUG.而評價一個程式碼最重要的是,程式碼能否適應將來的需要,即對程式碼的維護.

程式碼能Run,不是說Run一次兩次能用就好了,你要考慮的是它一年以後,兩年以後,五年以後.甚至十年二十年以後, 這個程式碼還可能有其他人或者你自己要繼續做下去.需求如果有了變更,要進一步發展下去,這個時候你拿之前寫的程式碼怎麼辦.

你的程式碼還能不能在今後起作用； 讓今後做維護的,無論是其他人還是你自己,能夠比較容易的在這個程式碼的基礎上做事情.這才是我們考察程式碼良好的一個重要原則。 就是說這個程式碼適不適合擴充套件,也就是常說的可擴充套件性.在程式中存在相似甚至相同的程式碼塊，這是非常低階的程式碼質量問題。

程式碼複製所帶來的問題就是:如果需要去修改一個副本,那麼就必須得同時修改所有其他的副本.否則就存在不一致的問題.這大大增加了維護程式的工作量,而且很容易存在錯誤和危險.

比如對於維護程式的人來說,程式設計師看到一個副本被修改好了,就以為其他所有要修改的地方都已經修改好了.因為沒有任何跡象表明還有一份一樣的副本程式碼存在, 所以很容易導致遺漏還沒被修改的地方.

消除程式碼複製的兩個基本手段————函式與父類。

你的程式設計優不優秀.就需要定義一些評價設計的術語:兩個重要的核心術語————耦合與聚合.

耦合指的是類與類之間的聯絡.程式設計的目標是一系列通過定義明確的介面通訊來協同工作的類.耦合度反映了這些類聯絡的緊密度. 我們要努力來降低耦合度,或者叫做鬆耦合.因為耦合度決定了程式修改的難易程度.在一個緊耦合的結構中,對一個類的修改也會導致對其他一些類的修改. 這是我們要努力去避免的,否則,一點小小的改變就可能使整個應用程式發生改變.另外要想找到所需要修改的地方，並一一修改卻是即困難又費時的事情.

另一方面,在一個鬆耦合的系統中,常常可以修改一個類,但同時不會修改其他類,而且整個程式還可以正常工作.

聚合與程式中一個單獨的單元(可以說是test)所承擔的任務的數量和種類相對應有關,它是針對類或方法(函式)這樣大小的程式單元而言的理想情況下, 一個程式碼單元應該負責一個聚合任務(也就是說，一個任務可以被看作是一個邏輯單元(logic unit)).一個方法應該實現一個邏輯操作,而一個類應該代表一定型別的實體.

聚合的重點是重用:如果一個方法或者類是隻負責一件定義明確的事情,那麼就很有可能在另外不同的上下文環境中使用.

遵循這點的好處是，當程式某部分的程式碼需要改變時，在某個程式碼單元中很可能會找到所有需要改變的相關程式碼段。