關於設計模式的思考

    最近開始着手項目的代碼重構,因爲原有的代碼框架已經越來越難以應對日益變更產品需求了,代碼越來越臃腫繁雜,越來越難以維護,bug隱藏越來越得越來越深,不得已纔想起了重構,重構是一個敏感的話題,很多程序員希望重構,特別是新員工,希望藉此機會來鍛鍊一下自己,但領導對於重構有着很謹慎的態度,因爲,提起重構,首先想到的就是人力物力成本和時間成本,而且更重要的是面臨着重構後產品能否有預期表現的風險,所以,很多領導對重構不太感冒,很多產品經理對重構也漠不關心,因爲他們只看產品的表現,不關係技術實現,所以,很多時候重構成了程序員的一廂情願.我們公司這次重構剛好面臨着下一版本產品需求沒有成型這樣一個空檔期,大概一個月吧,領導同意我們藉此機會重構代碼,我欣然接受.重構機會難得,不能掉以輕心,不能隨便應付了事,儘量充分應用自己哪怕少得可憐的知識來認真對待.
    今天在上衛生間的十來分鐘的時間裏我在想一個問題,既然是重構,當然就得把代碼架構設計合理,便於擴展和維護,這種時候我們都會想到設計模式,設計模式也是程序員到了一定的水平自然而然就會想到的話題,但我今天想的不是具體的用什麼設計模式,而是一些說得好聽一點就是上升到哲學層面的問題:爲什麼會有設計模式一說,我們應該用什麼心態對待設計模式,設計模式是不是一定就是好東西?
    我不是技術牛人,只是隨便發表一些膚淺的碎片化的感想,任何事物的發展都有一個過程,剛開始都難免很原始,很初級,隨後經過演化越來越高級,比如人的進化,還有人大腦的進化等等,任何領域的技能也都有這樣一個演化過程,經過多少代人的共同努力,這項技術越來越先進,這也是爲什麼人類文明爲什麼越來越發達,學科越來越多樣化的原因.因爲很多領域經過提煉加工並經過後人的演進就會成爲一門單獨的學問.同樣,軟件領域也是如此,軟從誕生初期恐怕沒人知道設計模式是什麼概念,用很原始很初級很直截了當的方式來實現軟件的需求.但隨着軟件業的發展,產生了越來越多的技術,各種名詞術語層出不窮,設計模式就是其中一個.
    設計模式是一些優秀的程序員前輩們在編程的過程中提煉總結出來的智慧結晶.是對一些軟件優秀結構的解決方案的總結.這些模式可以套用在很多地方,但是,事物都是具有兩面性的,怎麼利用設計模式有利的一面,怎麼合適地利用設計模式,是不是非得用設計模式等等這些問題都得考慮,不要迷信設計模式,不要機械呆板地使用設計模式.在我看來,設計模式的使用應該取決於場合,項目的大小,項目的性質,項目的週期,人力物力預算等等都要綜合考慮,一些較大的項目將來的維護和擴展是一件非常重要的事情,合理的架構能爲以後的維護和擴展帶來極大的便利,相反,一個結構混亂,高耦合的架構將來的維護和擴展任務將會讓程序員生不如死,而一些簡單的小項目,週期要求也很短,這種情況下就不一定在每一個模塊,每一個細節功能都把設計模式用到極致,一些直截了當的方案就可以了,如果程序員是一個理想主義者,處處考慮到重用性,也不關心項目的週期,爲了可重用性不顧一切地優化結構,不停地更改,爲了實現低耦合,可能付出了極大的代價,最終實現了一個優秀的架構,但項目也因拖延了太久而廢棄了,做爲程序員,我們應該考慮的事情有很多,不應該光從技術角度單純地考慮,即使從技術角度這一方面來考慮,也應該站在一定的高度用系統的眼光來考慮,想起一個簡單的例子,比如有一個題目是這樣的,列出用abc這三個字母組成的所有排列組合.直窮舉就可以了,沒有必要再用排列組合公式計算了,但如果讓你列出26個英文字母組成的所有組合,那就得用公式計算了,道理就是這樣,一定要站在一定的高度,用系統性思維靈活地考慮問題.很多時候簡單的解決方案因爲我們僵化的思維而被遺忘.
    沒有最優的架構,只有最合適的方案,方案的選取是對技術經理,技術總監綜合能力的考驗.