【開發模式】項目過早優化現象：處女座專屬雞湯

最近在Coursera上看機器學習，順便梳理了下算法體系。

其中Andrew Ng就有提到一個「過早優化」的觀點很是喜歡：

        與其將大把時間花費在挑選學習算法、更換模型上，而後花費六、7個月收集數據，（潛臺詞：這是愚蠢的作法，bad idea）

不如

        憑直覺先隨意挑個算法、用少許數據在1,2天內進行實現，而後經過學習曲線、偏差分析來調整這個學習算法，並判斷特徵是否足夠區分，是否須要加入新的特徵變量，直到有證據代表目前特徵適合且只欠缺樣本量/數據後再開始收集。這樣花下去的時間才更容易有所收穫。（潛臺詞：這纔算把時間花在刀刃上，recommended way）

 

        這裏我將其延伸到項目優化問題上，整理下本身的見解，請各位看官手下留情~

A. 「艱難的開頭」

        在學校裏，基本每門語言課的老師都會強調代碼的可讀性。這本無問題，但可讀性、交互性（特別是涉及GUI交互）在更多時候與性能優化是矛盾的。但願腳踏兩船的每每弄得焦頭爛額，最後仍是不得不妥協，只能折中偏向其一。

        而上過設計模式的課後，多數同窗更是爲了可讀性、複用性、拓展性……在項目的開始就一頭扎進了無限優化框架的不歸路。

        特別是對於項目經驗並不豐富的同窗，每每在項目的開頭就由於想着如何搭好框架而把本身弄得精疲力竭，進度停滯；想着後續的功能需求還一個都未實現，內心更是惴惴不安；面對BOSS的一次次催促而逐漸厭煩，致使項目的一個DEMO都沒出來就已宣告放棄。

        固然，這更可能是本身的親身體會，往往項目開頭總會被各類框架設計問題折騰不休，直到將系統走通或主要功能實現纔鬆下這口氣。現在看來，若是開始就從功能着手，一步步增量，反而更輕鬆、更適合這些項目的進度要求。而在一開始就鋪開框架，每每後期會由於先天龐大的結構調整不止：一面爲之後預留接口，一面修改甚至還刪去當初沒必要要的拓展。

 

B. 「瀑布式開發」 v.s. 「迭代式開發」

        其實，如今看來過早應用「設計模式」並無想的那麼好處多多，其更像「瀑布模型」這種弊端多多的線性開發模式，自上而下，在初期進行更多優化設計，並只有等到整個過程的末期才能見到開發成果，從而增長了開發風險。

        「迭代式開發」反而是更多項目最好的選擇，而非一無可取只適用於理論的概念。

        「迭代式開發——不要求每個階段的任務作的都是最完美的，而是明明知道還有不少不足的地方，卻恰恰不去完善它，而是把主要功能先搭建起來爲目的，以最短的時間，最少的損失先完成一個「不完美的成果物」直至提交。而後再經過客戶或用戶的反饋信息，在這個「不完美的成果物」上逐步進行完善。」

        其實不完美並不可怕，多數項目後期彌補的代價每每是能夠接受的，項目進度的不可估計、風險的未知每每纔是項目失敗的根源。

 

C. 耦合 v.s. 性能

        此外，「設計模式」強調的低耦合每每是冗餘的根源，在性能方面的表現與其徹底是負相關。真正高效的代碼，絕對是能合併方法就合併方法，能枚舉的就毫不遍歷，最好全部代碼全寫在一個方法內。固然，這又是一個極端了。

 

D. 結論：好鋼用在刀刃上       

        說了那麼多，其實想表達的就是項目過早優化不只費心費力，並且容易起反效果：後期由於龐大的框架與多餘的部分而輕鬆不起來。

        所以寫代碼仍是順心就好，時間要花在刀刃上。框架優化了性能下降、性能提高了可讀性差，既然沒法兩全，除非指標要求，何苦糾結這個呢，項目開始就走極端可不是一個好的作法哦~

       打下補丁：固然自覺代碼水平極爛的仍是得花時間規範下吧。

 

F. 療效測試

    若是觸發治療暴擊請點贊~

    若是治療失敗，這裏還有個終極療程（PS. 是寫完後才發現的，藥效過猛慎入）：過早的優化是萬惡之源，細數優化7大原則