本篇文章已授權微信公眾號guolin_blog(郭霖)獨家釋出

• 學習了許多的設計模式之後,大部分人都會有濫用(或者設計不足)設計模式的經歷,如何在其中找到一個balance,以下的文章就會給出一個解決方案,一種比較中和的思考方式,在此之前,我們先看一下我們經常會犯的幾種錯誤

功能上的過度設計

• 功能性過度設計其實不是我們今天討論的重點,但是知曉它非常的重要,因為需求的易變性(造成我們無法準確把握程式的走向)是造成我們對設計模式濫用的一個比較重要的原因,請各位看官帶著調侃的心態看一個小段子,笑笑後可能也會給我們帶來一些思考(為什麼說帶著一種調侃的心態,因為這部分大多不是我們能控制的,大家都懂)
  

程式上的過度設計

先引用vczh的一句話

什麼叫過度設計?只要team裡面的人沒有牛逼到來什麼需求都可以把程式碼重構到恰好滿足那個需求的最佳狀態，那麼我們在開發的時候總是要考慮一下未來的需求到底會往哪個方向走。
你蒙中了，就叫正交分解。
你沒蒙中，就叫過度設計。

• 簡單的來說,過度設計就是進行了過多的面向未來設計,我在重構系列中說過,一個程式產生的價值有兩種,今天能為你做什麼和將來能為你做什麼,但是,如果我們過多的考慮了未來,進行了太多的不必要(說不確定可能更好)的封裝,就會為系統增加許多的複雜度
• 舉一個簡單的例子,當你接手一個功能模組時,除了你完成了自己目前的任務,你還考慮到了未來可能完成的功能等,你就會做一些抽象和封裝,以便將來可以複用它們,但是到後來你發現了功能和你想象的不一樣(有可能是需求變化,有可能是你封裝抽象錯誤或者封裝抽象不足,或者說你發現複用的部分降低的成本還不如包裝花費的成本),你就會陷入泥潭,可能需要做更多的工作來還原,然後繼續前進,繼續犯錯…

如何解決

• 如何避免過度設計,這需要大量的經驗積累和不斷的思考,我們需要深入理解我們所在程式領域的知識,瞭解使用者使用我們的軟體是為了解決什麼樣的問題,這樣我們預測使用者的需求才會比以前更加準確,從而避免了我們使用設計模式來封裝一些根本不會發生的變化,也避免了我們忽視未來會發生的變化.
  

  在滿足了知道所有設計模式為什麼要被髮明出來的前提之後,剩下的其實和程式設計沒什麼關係了,而跟我們的領域知識和經驗有關(對於我這個小白,還有很長的路要走啊~-~)

TDD思考法(測試驅動開發)

這是我在網上看到的一種方法,因為題主經驗不足,自己沒有親身實踐過,無法通透其中的奧義,所以先行記錄,待以後慢慢咀嚼

• TDD的核心思想是小步增量,不斷重構,具體來說TDD有兩個狀態(兩頂帽子)
  
  • 狀態A:用test case描繪需求,並使用最簡單的方式滿足這個case,一定是最簡單的方式,不能做此外的任何涉及(考慮當前,不顧未來),case通過之後進入狀態B
  • 狀態B:重構程式碼,讓現有的程式碼在儘量保持簡單性的同時足夠清晰優雅,注意此時你只能對現有的實現程式碼進行重構,不能增加新的功能和test case.

TDD的這種思維方式走的稍微極端一點。它直接排斥任何對未來的設計，轉而以優雅簡潔的設計和test case來為未來需求的重構降低成本。 可以說嚴格遵循TDD會在設計不足和過度設計之間找到最好的平衡。