这是一个创建于 2131 天前的主题，其中的信息可能已经有所发展或是发生改变。
不知道是完美主义还是什么，我自己在开发的时候总是习惯同步地进行优化，而且是那种我自己都觉得没什么必要的优化。
比如经常苦思冥想降低几个百分点的 CPU 占用率，想尽办法降低内存消耗，写一个组件的时候一开始就尽量写得可扩展可重用。关键是这些地方优化了也基本看不出什么明显的效果，反而本来一件简单的事会被我自己搞得很复杂，但是不这么做我心里又难受，感觉浑身不舒服。
各位平时会时时考虑优化么，还是说不碰到性能问题就不优化？感觉都有点强迫症了，难受的不行……
 | 1 ericls 2019-12-18 12:48:04 +08:00 via iPhone 最大的毛病之一 一定要克服 |
 | 2 waterlaw 2019-12-18 12:48:24 +08:00 via Android 这是对的， 前期不优化后期都懒得优化，把控代码质量是个好的习惯，但也不要过度设计就是了。 |
 | 3 xuanbg 2019-12-18 12:51:45 +08:00 这个正常，优秀的程序员都是这样一步步成长起来的。什么都应付应付能用就行，就不会有任何的成长。 |
 | 4 darksword21 PRO 但是有时候时间紧就只能先做完再说了 |
 | 5 dswyzx 2019-12-18 12:55:16 +08:00 只要按时交活,没有 bug.越优化岂不是越好 反之,优化了一句,还有 10 句没实现,或者 bug 没修复.那肯定凉凉 |
 | 6 xhq 2019-12-18 12:55:45 +08:00 via Android 看标题还以为人被优化了，原来是代码的优化 |
| 7 ericls 2019-12-18 12:57:18 +08:00 via iPhone @waterlaw 楼主这个不是代码质量问题 而是性能优化 自己写 lib 倒是可以 写 application 和 product 千万不可 因为这些是给人用的 人是很难预测的 所以你对假定情景的优化成本太高 |
| 8 ericls 2019-12-18 12:58:10 +08:00 via iPhone 如果你的优化没有 assumption 那你就是万能的预言家了 |
 | 9 bk201 2019-12-18 12:59:14 +08:00 想太多的结果会造成工作量没法和老板交差 |
 | 10 shawnsh 2019-12-18 12:59:27 +08:00  1 除非优化对公司产生效益了，要不然白优化。还有你写的程序不一定是整个软件的性能瓶颈，说白了你在写的好，其他人写的垃圾，照样对产品没什么用。如果想重构倒是可以，优化就算了。 |
| 11 ericls 2019-12-18 12:59:59 +08:00 via iPhone |
 | 12 Freeego OP @ericls 确实是写 application 的时候…明知道用户不会有什么感受，但还是控制不住。过早的优化是万恶之源啊！ |
 | 13 hehheh 2019-12-18 13:00:54 +08:00 via iPhone 1 把代码写的更健壮更易懂比代码运行效率提高那么几个百分点更重要。 当然如果你是搞高频交易的当我没说 |
| 14 hehheh 2019-12-18 13:02:23 +08:00 via iPhone 还有上边有个人说的很好，你的代码速度可能根本不是瓶颈，这个只有写过很大的工程才能明白。特别是当一个工程由几十号人开发了好几年过来的 |
| 15 ericls 2019-12-18 13:03:12 +08:00 via iPhone |
 | 16 wangyzj 2019-12-18 13:08:08 +08:00 这是正确做法 大前提是你要规划好进度 |
 | 17 littlewing 2019-12-18 13:10:48 +08:00 1 写一个组件的时候一开始就尽量写得可扩展可重用 这个是好的 至于性能优化，开发阶段没必要，后续需要看瓶颈到底在哪里，再针对性优化 |
 | 18 dazhangpan 2019-12-18 13:21:23 +08:00 1 如果简单的操作能带来提升是完全可以一边开发一边优化的 但是这些操作对一位程序员来说是不是简单 是要看他对硬件 /操作系统 /软件架构的理解深度的 在这方面思考多了，积累多了，是能从一下手写出来的就是性能向的优化代码的 所以楼主完全不必纠结 你这是勇猛精进的必经之路而已 |
 | 19 LiuJiang 2019-12-18 13:26:02 +08:00 一样，看到垃圾代码习惯顺手改掉，顺手改不掉得，后买再改。 |
 | 20 WillGoh 2019-12-18 13:39:22 +08:00 如果时间够，那无所谓。如果不够，还是要考虑以下开发效率的，很多东西也不能一蹴而就不是吗？ |
 | 21 murmur 2019-12-18 13:40:17 +08:00 开发如果你并发只能到 100 堆硬件后面改也优化不到 10000 是吧 |
 | 22 newtype0092 2019-12-18 13:40:28 +08:00 1 以前我也这样，后来看了高性能 MySQL 才知道，这种根本不叫优化，就叫瞎折腾。 优化一定是先分析和测试，找出效率低下的地方，然后设计优化方案并预估成本和能带来的改善，最后根据前面的信息决策，如果改善大于成本，那么就动手修改。 所以修改代码只是优化过程的最后一小步，如果没有前面的所有工作，那这多余的一小步没有任何意义。 |
 | 23 dosmlp 2019-12-18 14:53:48 +08:00 性能优化绝大多数情况下属于多余，还是代码结构易读性等比较重要 |
 | 24 elekids 2019-12-18 18:32:26 +08:00 最大的毛病之一 一定要克服 |
 | 25 akira 2019-12-18 18:34:56 +08:00 和你反过来，如果换一种写法 代码看起来更好阅读，即使会降低效率，那我也会换一种写法。 性能优化是需要数字支撑的。 低频的代码 优先考虑是上缓存，其次才是代码优化。 高频执行的代码，需要确认瓶颈点以后，再进行优化。 说真的，现在的系统，大部分情况下，逻辑代码都是没有性能问题的。优先保障业务正常，系统上线以后，再来考虑优化都来得及。 有业务的系统，才有资格讨论优化。死掉的系统，没有资格说优化的问题。 |
 | 26 wuwukai007 2019-12-18 18:59:48 +08:00 via Android 有很多时候明明是加一个变量就好的事情，偏要在那边死磕的优雅一点… |
 | 27 uxff 2019-12-18 21:06:18 +08:00 处了内存优化，还有设计优化，我也是同样有强迫症，看到设计不够好的代码，有强烈的冲动去把它改好。 |
 | 28 Honwhy 2019-12-18 21:26:43 +08:00 首先完成需求是第一任务,至于优化需要看时间是否紧迫 然后是优化的需要做好准备,涉及关联逻辑不影响到,这里做好单元测试,相信重构的力量 《重构》 |
 | 29 XiLemon 2019-12-19 08:04:34 +08:00 via iPhone 这是病，得治（手动狗头 |
 | 30 saltedFish666 2019-12-19 09:37:07 +08:00 你优化现在做了,以后还怎么优化赚钱??? |
Select Language