转载

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,

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

原文  http://www.cnblogs.com/yougewe/p/11366876.html
正文到此结束
Loading...