Think in Speed (关于速度的一点思考)

      天下武功,无坚不摧,唯快不破!所以我们重视速度没毛病!

     老话说:不要过早优化。赞同!

     我们在写代码过程中,有时可能就是为了追求所谓的性能,然后,就给自己挖坑了。

关于开发速度,我有以下几点思考:

     1. 程序运行速度的思考:不能只为了速度而丢弃了:扩展性,高内聚性,低耦合性;还要站在更高层次来考虑问题,比如易于理解,易于维护,分层架构,功能扩展;

     2. 开发速度的思考:快速开始是好事,但不要在想清楚之前就开始。开发未动,流程图(系分)先行;

     3. 产品迭代速度的思考:在不确定的事情之前,先反复思考产品价值,如果觉得ok,那就去做,但是一定要快。快速试错,快速修改,允许有稍微bug上线,但是一定要有反馈机制;做到快而有序,机动有余;

     4. 关于性能优化速度的思考:性能优化是个长期的事,切莫求快,一定求稳,反复测试,反复评估,带回滚机制,然后再上线;

 

代码速度:

     1. 去纠结使用 if 不是 switch, 去纠结 ;

     2. 在代码清晰性面前,不在乎多一两层嵌套;

     3. 将相乘需要变成位移动;

     4. 不在乎使用代理;

     5. 不在乎多引入几个必要依赖包;

     6. 不在乎多几个单元测试;

     7. 不在乎多几个配置变量;

     8. 不在乎多开几个后台维护线程;

     9. 不在乎因功能内聚导致的层层调用;

     10. 不在乎为可伸缩做的多余工作;

     11. 不在乎由于服务拆分导致的网络开销;

     12. 不在乎为统一外部调用多一层的封装;

     13. 推荐书箱:《effective java》,《重构改善既有代码的设计》

 

开发速度的思考:

     1. 不要一味想快;

     2. 系统架构先行;

     3. 架构依赖于现有需求及未来可能的发展规划;

     4. 依据需求,做好模块划分;

     5. 每个模块做好相应流程图(系分);

     6. 写真正代码前,先写测试用例,做好结果预期;

     7. 尽快提供统一稳定的对外接口,不要沉溺内部逻辑;

     8. 来不及更改的地方,打上todo标签,待外部环境稍稳定后,再回来赶紧修复内部问题;

     9. 多做单元测试;

     10. 多观察真实测试结果,及是否存在报错,在黑盒外测试,在白盒里看问题;

     11. 最后关注性能问题;

     12. 推荐书籍:《head first 设计模式》,《大型网站架构设计》

 

产品迭代速度的思考:

    1. 定位好解决的问题,定位好客户群体;

    2. 以问题为核心,关注点集中,快速上线,市场验证;

    3. 观察效果,尽可能接近真实用户,发现问题,快速修复;

    4. 跟进后续突破的点,快速迭代;

    5. 继续观察产品效果,改进;

    6. 发现细微的点,发现用户潜在的点,为其解决问题;

    7. 减慢产品速度,开拓新市场;

 

关于性能优化速度的思考:

    1. 别想一次就把性能优化做好;

    2. 审阅代码;

    3. 压测,记录结果;

    4. 发现性能瓶颈点,想办法优化掉;

    5. 继续压,记录结果;

    6. 再发现瓶颈点,再优化;

    7. 时刻关注cpu,内存,网络;(磁盘次之)

    8. 针对某些业务场景,做降级策略备用;

    9. 压测,记录结果;

    10. 性能监控要跟上;

    11. 回滚方案需有数;

    12. 优化工具:jmx,jmeter,sonar,grafana,

 

唠叨: 凡事没有看起来那么简单。

posted @ 2019-08-16 23:35 等你归去来 阅读(...) 评论(...) 编辑 收藏