怎么看待在开发过程中就进行优化的问题？

[Freeego]

不知道是完美主义还是什么，我自己在开发的时候总是习惯同步地进行优化，而且是那种我自己都觉得没什么必要的优化。

比如经常苦思冥想降低几个百分点的 CPU 占用率，想尽办法降低内存消耗，写一个组件的时候一开始就尽量写得可扩展可重用。关键是这些地方优化了也基本看不出什么明显的效果，反而本来一件简单的事会被我自己搞得很复杂，但是不这么做我心里又难受，感觉浑身不舒服。

各位平时会时时考虑优化么，还是说不碰到性能问题就不优化？感觉都有点强迫症了，难受的不行……

[murmur]

开发如果你并发只能到 100 堆硬件后面改也优化不到 10000 是吧

[newtype0092]

以前我也这样，后来看了高性能 MySQL 才知道，这种根本不叫优化，就叫瞎折腾。
优化一定是先分析和测试，找出效率低下的地方，然后设计优化方案并预估成本和能带来的改善，最后根据前面的信息决策，如果改善大于成本，那么就动手修改。
所以修改代码只是优化过程的最后一小步，如果没有前面的所有工作，那这多余的一小步没有任何意义。

[dosmlp]

性能优化绝大多数情况下属于多余，还是代码结构易读性等比较重要

[elekids]

最大的毛病之一

一定要克服

[akira]

和你反过来，如果换一种写法 代码看起来更好阅读，即使会降低效率，那我也会换一种写法。

性能优化是需要数字支撑的。
低频的代码 优先考虑是上缓存，其次才是代码优化。
高频执行的代码，需要确认瓶颈点以后，再进行优化。

说真的，现在的系统，大部分情况下，逻辑代码都是没有性能问题的。优先保障业务正常，系统上线以后，再来考虑优化都来得及。 有业务的系统，才有资格讨论优化。死掉的系统，没有资格说优化的问题。

[wuwukai007]

有很多时候明明是加一个变量就好的事情，偏要在那边死磕的优雅一点…

[uxff]

处了内存优化，还有设计优化，我也是同样有强迫症，看到设计不够好的代码，有强烈的冲动去把它改好。

[Honwhy]

首先完成需求是第一任务,至于优化需要看时间是否紧迫
然后是优化的需要做好准备,涉及关联逻辑不影响到,这里做好单元测试,相信重构的力量
《重构》

[XiLemon]

这是病，得治（手动狗头

[saltedFish666]

你优化现在做了,以后还怎么优化赚钱???