近期。同專案組的一位師姐請產假了。由我接手她之前的部分版本號的開發工作。在開發的過程中，我閱讀了某個非常古老的版本號的程式**。心生感觸。想在這裡囉嗦幾句。
該版本號中非常多函式的呼叫關係都錯綜複雜，讓人讀起來非常的費勁。我用例如以下的圖來形象化地表示這樣的函式之間的呼叫關係。
箭頭的指向為呼叫關係，如「函式a」呼叫了「函式b」、「函式c」、「函式d」、「函式e」、「函式f」，以此類推。
當函式之間的呼叫關係太多時。各個函式就組成了乙個複雜的呼叫網路。非常難將它們之間的關係理清晰。
那麼，為什麼會出現這麼「糟糕」的函式設計呢？原因有下面幾點：
第一。最原始版本號的開發者沒有做好具體設計，程式是想到**就寫到**。最原始版本號宛如一座大樓的地基，地基沒有打好。當然興許的工作就沒那麼順利了。此外。興許的開發者總喜歡拿之前開發者的程式作為參照。「不好」的前輩僅僅會教出更為「不好」的「徒弟」。
第二，專案組為了趕進度，僅僅要求程式可以實現基本功能。並沒有對**進行嚴格的同行評審。「趕進度」僅僅會產生糟糕的**。而假設**僅僅是乙個人說了算。那肯定會留下非常多的問題。
第三，在程式演進的過程中，不同的開發者對同乙個版本號的**進行了改動。假設每乙個人都對乙個版本號的程式進行改動。因為大家編寫**的習慣都不盡同樣，因此會使得程式「越改越差」。
那麼，優秀的程式有什麼樣的要求呢？要求之中的乙個就是：函式設計應做到低耦合。高內聚。
也就是說。在不新增**複雜度的情況下，盡量降低函式之間的呼叫關係，在本函式實現規定的功能。
「低耦合，高內聚」的函式設計有什麼優點呢？優點有下面幾點：
第一，便於對程式進行維護。這點非常重要，特別是剛入職的員工，假設他們閱讀到了邏輯清晰、程式設計規範的**，真的是一種福氣。
第二。便於程式版本號的演進。有了好的「模範」，之後對程式的增刪改的工作都更加的easy了。
第三。便於不同專案組或產品線之間的溝通交流。優秀的**應該拿出來，供大家一起學習。
「他山之石，可以攻玉」，僅僅有不斷地學習別人好的、成功的經驗，自己的能力才可以得到提公升。
當然，好的函式設計方法也不是一朝一夕就行掌握的。僅僅要我們堅持學習、不斷總結。相信定然會寫出優美的、易於閱讀和理解的程式來的。
高內聚,低耦合
大家都在說高內聚，低耦合。問題是什麼是高內聚？什麼是低耦合？那它們的作用是什麼？先來談談什麼是耦合，耦合就是不同模組之間粘稠的程度。耦合度高證明你的模組之間粘稠，不好剝離模組功能。造成後續修改難度加大，所謂 動一發而牽全身 當你的 粘稠在一起的時候，就代表你的 需要重寫了。那麼避免這些個事情的發生，...
高內聚，低耦合
內聚，更為專業的說法叫功能內聚，是對軟體系統中元素職責相關性和集中度的度量。如果元素具有高度相關的職責，除了這些職責內的任務，沒有其它過多的工作，那麼該元素就具有高內聚性，反之則為低內聚性。其實結合oop的思想，高內聚應該是更加趨向於介面化，工廠模式可以很容易體現這種思想。即方法呼叫，只要通過相應的...
高內聚低耦合
明確一點，乙個程式如果是高內聚零耦合會是最完美的，但是沒有絕對的零耦合。也就不存在什麼完美的程式了。1 什麼是高內聚 低耦合？首先了解什麼是內聚 耦合 1.1.1內聚性 每乙個程式中可能會按照不同功能，將整個 段劃分為不同的模組，每乙個模組內部元素彼此之間會有某些聯絡，此種聯絡就是內聚性。同乙個模組...