【开发模式】项目过早优化现象：处女座专属鸡汤

最近在Coursera上看机器学习，顺便梳理了下算法体系。

其中Andrew Ng就有提到一个“过早优化”的观点很是喜欢：

        与其将大把时间花费在挑选学习算法、更换模型上，而后花费六、7个月收集数据，（潜台词：这是愚蠢的作法，bad idea）

不如

        凭直觉先随意挑个算法、用少许数据在1,2天内进行实现，而后经过学习曲线、偏差分析来调整这个学习算法，并判断特征是否足够区分，是否须要加入新的特征变量，直到有证据代表目前特征适合且只欠缺样本量/数据后再开始收集。这样花下去的时间才更容易有所收获。（潜台词：这才算把时间花在刀刃上，recommended way）

 

        这里我将其延伸到项目优化问题上，整理下本身的见解，请各位看官手下留情~

A. “艰难的开头”

        在学校里，基本每门语言课的老师都会强调代码的可读性。这本无问题，但可读性、交互性（特别是涉及GUI交互）在更多时候与性能优化是矛盾的。但愿脚踏两船的每每弄得焦头烂额，最后仍是不得不妥协，只能折中偏向其一。

        而上过设计模式的课后，多数同窗更是为了可读性、复用性、拓展性……在项目的开始就一头扎进了无限优化框架的不归路。

        特别是对于项目经验并不丰富的同窗，每每在项目的开头就由于想着如何搭好框架而把本身弄得精疲力竭，进度停滞；想着后续的功能需求还一个都未实现，内心更是惴惴不安；面对BOSS的一次次催促而逐渐厌烦，致使项目的一个DEMO都没出来就已宣告放弃。

        固然，这更可能是本身的亲身体会，往往项目开头总会被各类框架设计问题折腾不休，直到将系统走通或主要功能实现才松下这口气。现在看来，若是开始就从功能着手，一步步增量，反而更轻松、更适合这些项目的进度要求。而在一开始就铺开框架，每每后期会由于先天庞大的结构调整不止：一面为之后预留接口，一面修改甚至还删去当初没必要要的拓展。

 

B. “瀑布式开发” v.s. “迭代式开发”

        其实，如今看来过早应用“设计模式”并无想的那么好处多多，其更像“瀑布模型”这种弊端多多的线性开发模式，自上而下，在初期进行更多优化设计，并只有等到整个过程的末期才能见到开发成果，从而增长了开发风险。

        “迭代式开发”反而是更多项目最好的选择，而非一无可取只适用于理论的概念。

        “迭代式开发——不要求每个阶段的任务作的都是最完美的，而是明明知道还有不少不足的地方，却恰恰不去完善它，而是把主要功能先搭建起来为目的，以最短的时间，最少的损失先完成一个“不完美的成果物”直至提交。而后再经过客户或用户的反馈信息，在这个“不完美的成果物”上逐步进行完善。”

        其实不完美并不可怕，多数项目后期弥补的代价每每是能够接受的，项目进度的不可估计、风险的未知每每才是项目失败的根源。

 

C. 耦合 v.s. 性能

        此外，“设计模式”强调的低耦合每每是冗余的根源，在性能方面的表现与其彻底是负相关。真正高效的代码，绝对是能合并方法就合并方法，能枚举的就毫不遍历，最好全部代码全写在一个方法内。固然，这又是一个极端了。

 

D. 结论：好钢用在刀刃上       

        说了那么多，其实想表达的就是项目过早优化不只费心费力，并且容易起反效果：后期由于庞大的框架与多余的部分而轻松不起来。

        所以写代码仍是顺心就好，时间要花在刀刃上。框架优化了性能下降、性能提高了可读性差，既然没法两全，除非指标要求，何苦纠结这个呢，项目开始就走极端可不是一个好的作法哦~

       打下补丁：固然自觉代码水平极烂的仍是得花时间规范下吧。

 

F. 疗效测试

    若是触发治疗暴击请点赞~

    若是治疗失败，这里还有个终极疗程（PS. 是写完后才发现的，药效过猛慎入）：过早的优化是万恶之源，细数优化7大原则