提前代码优化的教训

一

总是想着写高性能代码,但是对于一个项目而言,一开始就特别注重高性能代码往往会:

1. 大大提高代码量
2. 增加写代码难度
3. Bug率飙升
4. 项目完成时间大幅增加

比如对于现在这个用Netty写个服务器的项目,本来如果用Http协议就好了,虽然对于这种环境性能不是很高,但是可以很快地实现这些功能,然而我从一开始就自定义协议,以高性能为导向,但是这么做的代价是架构变得更加复杂,自定义了一大堆协议类型,代码大大增加,同时Bug率飙升.如果从一开始就用Http协议,就没有那么多事了,本来在需要高性能的地方,再采用自定义的高性能协议就好了.

其实一个项目有很多地方要考虑,比如在给定时间内完成是一个很重要的因素,企业里面,项目无法及时完成后果很严重,而性能问题往往可以通过加钱买机器来解决.当项目的性能出现瓶颈时,往往可以后期优化解决瓶颈.更何况对于一个项目,能不能用这才是首要的,有足够的性能却没有完成这个项目那这个项目是失败的.
性能的优化是无止境的,你这么考虑性能,那你怎么不用汇编去写呢?你怎么不直接从机器码的01开始写起呢?这样性能绝对够,但是这样对于一个小型项目恐怕都得写个十几年.

以后只能这样告诉自己了:

你这么想着优化性能,你怎么不从汇编开始写呢?

你这么想着优化性能,你怎么不从汇编开始写呢?

你这么想着优化性能,你怎么不从汇编开始写呢?

以后应该如何做呢?
如果做的项目有时间限制,那么尽可能选择能快速完成项目的技术来做,逐步迭代优化,如果是个人项目且时间充裕,那么依然先最快完成项目,完成后慢慢用各种方式优化然后重构代码.如果是做个小型个人项目(暂定1000行代码以内的),并且没有什么时间限制,那就可以花较多时间去代码优化.

其实,一个项目的书写代码的难度也是挺重要的,如果难写,往往也容易出bug,更重要的是打击一个人的自信心,让自己更不想去完成项目,这往往导致个人项目尚未完成就被废弃.容易写出来才是首要的,这样才能够感受到写代码的乐趣.

所以以后写个人项目要注重的是写得舒服而不是性能,因为个人项目尤其不想企业项目那样会遇到性能瓶颈,这是极为少见的情况的.

仔细想想,自己这么注重性能的原因是不是因为目前这个阶段也只能在意代码的性能了?在意了性能,却没有看见设计良好的代码的优雅.之前的时间里,自己刷几百道ACM题,参加算法比赛,这种环境里,代码的性能是最重要的指标之一,然而,离开这种环境后,就要考虑更多因素,一般的项目没有海量的数据,性能瓶颈的解决也可以加钱解决,这时候,把代码写得优雅可能是最应该追求的.

二

Effective Java里说:不要因为性能而牺牲合理的结构.要努力编写好的程序而不是快的程序.如果好的程序不够快,它的结构将使它可以得到优化.这并不是说可以忽略问题,而是:

实现上的问题可以通过后期的优化得到修正,但是遍布全局的限制性能的结构性缺陷几乎是不可能被改正的,除非重写系统.应该要努力避免哪些限制性能的设计策略.那些最难修改的组件才是限制性能的关键:暴露给外部的API,线路层协议,永久数据格式…

我们开发软件要以发展的眼光看待.参加过算法比赛的人应该很清楚,算法比赛中的代码几乎是打完就扔,只要过了题,基本就不会再修改了,长此以往,便不自觉的以静态的观点看待软件开发.其实软件也是有生命周期的,它在不断迭代中成长,性能的提高可以通过迭代的方式得到解决.

2018/12/10 08:28

---

欢迎访问我的 个人网站(主要), Github, CSDN(主要), 博客园, 简书, 掘金, 知乎, 微信公众号:HelloVant(主要)

本文采用 知识共享 署名-非商业性使用-禁止演绎(CC by-nc-nd) 4.0 国际 许可协议 授权