【开发模式】项目过早优化现象：处女座专属鸡汤
最近在Coursera上看机器学习，顺便梳理了下算法体系。
其中Andrew Ng就有提到一个“过早优化”的观点非常喜欢：
与其将大把时间花费在挑选学习算法、更换模型上，然后花费6、7个月收集数据，（潜台词：这是愚蠢的做法，bad idea）
不如
凭直觉先随意挑个算法、用少量数据在1,2天内进行实现，然后通过学习曲线、误差分析来调整这个学习算法，并判断特征是否足够区分，是否需要加入新的特征变量，直到有证据表明特征适合并只缺样本量/数据后再开始收集。这样花下去的时间才更容易有所收货。（潜台词：这才算把时间花在刀刃上，recommended way）
这里我将其延伸到项目优化问题上，整理下自己的看法，请各位看官手下留情~
A. “艰难的开头”
在学校里，基本每门语言课的老师都会强调代码的可读性。这本无问题，但可读性、交互性（特别是涉及GUI交互）在更多时候与性能优化是矛盾的。希望脚踏两船的往往弄得焦头烂额，最后还是不得不妥协，只能折中偏向其一。
而上过设计模式的课后，多数同学更是为了可读性、复用性、拓展性……在项目的开始就一头扎进了无限优化框架的不归路。
特别是对于项目经验并不丰富的同学，往往在项目的开头就因为想着如何搭好框架而把自己弄得精疲力竭，进度停滞；想着后续的功能需求还一个都未实现，心里更是惴惴不安；面对BOSS的一次次催促而逐渐厌烦，导致项目的一个DEMO都没出来就已宣告放弃。
当然，这更多是自己的亲身体会，每每项目开头总会被各种框架设计问题折腾不休，直到将系统走通或主要功能实现才松下这口气。如今看来，如果开始就从功能着手，一步步增量，反而更轻松、更适合这些项目的进度要求。而在一开始就铺开框架，往往后期会因为先天庞大的结构调整不止：一面为以后预留接口，一面修改甚至还删去当初不必要的拓展。
B. “瀑布式开发” v.s. “迭代式开发”
其实，现在看来过早应用“设计模式”并没有想的那么好处多多，其更像“瀑布模型”这种弊端多多的线性开发模式，至之上而下，在初期进行更多优化设计，并只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
“迭代式开发”反而是更多项目最好的选择，而非一无是处只适用于理论的概念。
“迭代式开发——不要求每一个阶段的任务做的都是最完美的，而是明明知道还有很多不足的地方，却偏偏不去完善它，而是把主要功能先搭建起来为目的，以最短的时间，最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息，在这个“不完美的成果物”上逐步进行完善。”
其实不完美并不可怕，多数项目后期弥补的代价往往是可以接受的，项目进度的不可估计、风险的未知往往才是项目失败的根源。
C. 耦合 v.s. 性能
此外，“设计模式”强调的低耦合往往是冗余的根源，在性能方面的表现与其完全是负相关。真正高效的代码，绝对是能合并方法就合并方法，能枚举的就绝不遍历，最好所有全写在一个方法内。当然，这又是一个极端了。
D. 结论：好钢用在刀刃上
说了那么多，其实想表达的就是项目过早优化不仅费心费力，而且容易起反效果：后期因为庞大的框架与多余的部分而轻松不起来。
因此写代码还是顺心就好，时间要花在刀刃上。框架优化了性能降低、性能提升了可读性差，既然无法两全，除非指标要求，何苦纠结这个呢，项目开始就走极端可不是一个好的做法哦~
打下补丁：当然自觉代码水平极烂的还是得花时间规范下吧。
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
