标签：需求 封装 实用 改进 分层架构 设计 工作 有序 网站
天下武功，无坚不摧，唯快不破！所以我们重视速度没毛病！
老话说：不要过早优化。赞同！
我们在写代码过程中，有时可能就是为了追求所谓的性能，然后，就给自己挖坑了。
关于开发速度，我有以下几点思考：
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，
唠叨： 凡事没有看起来那么简单。
标签：需求 封装 实用 改进 分层架构 设计 工作 有序 网站
原文地址：https://www.cnblogs.com/yougewe/p/11366876.html
