软件优化的原则

我司的原则就是做出来就好，优化个锤子。
但是我的东西一般有时间就瞎捣鼓捣鼓。

楼下极有可能会有推这本书的《重构 改善既有代码的设计》

楼上说的对

但是我水平比较次，这本书对我没用

@4u1kto 我看过这本书，它比较侧重局部、小规模的重构，但我需要的是软件设计上的优化启发式原则。就比如缓存系统，什么时候应该引入缓存，什么应该缓存，什么不应该缓存。

先把功能实现，前期过度的优化是崩溃的开始(把后期的优化应用到前期上，堵死了后期的优化)

@metrxqin https://github.com/donnemartin/system-design-primer/blob/master/README-zh-Hans.md system-design-primer

@metrxqin 不立足于业务谈设计都是空中楼阁，满足需求的情况下提升性能才是软件设计的最终目标。

架构不就是坑趟多了嘛。

目的非常明确了而且很有必要，才开始优化。否则最开始乱优化，反而会导致问题的复杂度加大

找到关键点来优化 你把一个半夜运行的定时任务从 3 小时优化到 1 小时并没有什么卵用 把用户点击按钮从 3 秒优化到 1 秒意义就很大

给多少钱(工时)优化多少

面向 money 优化

闲得没事干的时候或者性能到瓶颈的时候

也就是说，不得不优化的时候才优化。

难道不是从 sleep （ 60 ）更改为 sleep （ 30 ）嘛，手动斜眼

@metrxqin 你的这个问题其实是一个很经验化的问题，也就是要 case by case 的问题。这种优化很多时候是一种取舍，所以很难说一定做什么，一定不做什么。比如缓存的引入，一定会增加系统的复杂度，何时刷新缓存，如何刷新缓存，缓存数据和落地数据更新读取顺序等等问题，大多时候都要具体情况具体分析，很少能一概而论。

感觉这个是一个软件工程的问题，没有上过这个方面的课程，仅仅经验之谈。

先业务,再谈性能

先多 sleep 一会儿，客户要求的时候就好做了

没有性能问题，就不要优化。

其实可以很简单的考虑，不管是谁写，代码写得越多，错得越多，所以首先代码越少，bug 就越少。优化什么的除非开始就可以预见会有性能问题，不然就不要考虑。

先实现功能吧,免得需求变来变去最后白搞,一般加上 TODO:之类的以后有必要时候提示下自己就好了

1.实现功能，最基本的要做到不要有重复代码
2.是否做性能优化要看是否有性能瓶颈，是否做代码的结构优化主要看你是否对于当前的代码足够满意，或者说你自己能不能看懂，有没有觉得维护性好，如果每次添加新功能时觉得整体设计不合理的话就要修改设计。

来推荐一波编程的智慧
http://www.yinwang.org/bog-cn/2015/11/21/programming-philosophy

我所接触到的优化
先加带宽 - 换 SSD - 内存翻倍 - 加个服务器负载
还不行 上面再来一遍

看工资
30K 就做 30K 级别的优化
80K 就做 80K 级别的优化

先实现功能，然后有时间就优化，没时间就挤出时间来优化。

只有通过优化代码，才能让自己的能力不断提高。

优化？不可能的，最多把代码整好看点