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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

这是一个创建于 1836 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

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

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

优化

难受

苦思冥想

降低

30 条回复 • 2019-12-19 09:37:07 +08:00

ericls

2019-12-18 12:48:04 +08:00 via iPhone

最大的毛病之一

一定要克服

waterlaw

2019-12-18 12:48:24 +08:00 via Android

这是对的，前期不优化后期都懒得优化，把控代码质量是个好的习惯，但也不要过度设计就是了。

xuanbg

2019-12-18 12:51:45 +08:00

这个正常，优秀的程序员都是这样一步步成长起来的。什么都应付应付能用就行，就不会有任何的成长。

darksword21

2019-12-18 12:54:47 +08:00 via iPhone

但是有时候时间紧就只能先做完再说了

dswyzx

2019-12-18 12:55:16 +08:00

只要按时交活,没有 bug.越优化岂不是越好
反之,优化了一句,还有 10 句没实现,或者 bug 没修复.那肯定凉凉

xhq

2019-12-18 12:55:45 +08:00 via Android

看标题还以为人被优化了，原来是代码的优化🤔

ericls

2019-12-18 12:57:18 +08:00 via iPhone

@waterlaw 楼主这个不是代码质量问题而是性能优化

自己写 lib 倒是可以
写 application 和 product 千万不可因为这些是给人用的人是很难预测的所以你对假定情景的优化成本太高

ericls

2019-12-18 12:58:10 +08:00 via iPhone

如果你的优化没有 assumption 那你就是万能的预言家了

bk201

2019-12-18 12:59:14 +08:00

想太多的结果会造成工作量没法和老板交差

shawnsh

2019-12-18 12:59:27 +08:00

除非优化对公司产生效益了，要不然白优化。还有你写的程序不一定是整个软件的性能瓶颈，说白了你在写的好，其他人写的垃圾，照样对产品没什么用。如果想重构倒是可以，优化就算了。

ericls

2019-12-18 12:59:59 +08:00 via iPhone

https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/

Freeego

2019-12-18 13:00:31 +08:00

@ericls 确实是写 application 的时候…明知道用户不会有什么感受，但还是控制不住。过早的优化是万恶之源啊！

hehheh

2019-12-18 13:00:54 +08:00 via iPhone

把代码写的更健壮更易懂比代码运行效率提高那么几个百分点更重要。
当然如果你是搞高频交易的当我没说

hehheh

2019-12-18 13:02:23 +08:00 via iPhone

还有上边有个人说的很好，你的代码速度可能根本不是瓶颈，这个只有写过很大的工程才能明白。特别是当一个工程由几十号人开发了好几年过来的

ericls

2019-12-18 13:03:12 +08:00 via iPhone

@Freeego 这还是建立在用户想用这个功能的假设基础上的

不过作为程序员写优雅高效的代码也是一种满足但是那是兴趣不是职业如果有个公司能让你工作时候这么干你好好珍惜吧

wangyzj

2019-12-18 13:08:08 +08:00

这是正确做法
大前提是你要规划好进度

littlewing

2019-12-18 13:10:48 +08:00

写一个组件的时候一开始就尽量写得可扩展可重用这个是好的
至于性能优化，开发阶段没必要，后续需要看瓶颈到底在哪里，再针对性优化

dazhangpan

2019-12-18 13:21:23 +08:00

如果简单的操作能带来提升是完全可以一边开发一边优化的
但是这些操作对一位程序员来说是不是简单
是要看他对硬件 /操作系统 /软件架构的理解深度的
在这方面思考多了，积累多了，是能从一下手写出来的就是性能向的优化代码的
所以楼主完全不必纠结
你这是勇猛精进的必经之路而已

LiuJiang

2019-12-18 13:26:02 +08:00

一样，看到垃圾代码习惯顺手改掉，顺手改不掉得，后买再改。

WillGoh

2019-12-18 13:39:22 +08:00

如果时间够，那无所谓。如果不够，还是要考虑以下开发效率的，很多东西也不能一蹴而就不是吗？

murmur

2019-12-18 13:40:17 +08:00

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

newtype0092

2019-12-18 13:40:28 +08:00

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

dosmlp

2019-12-18 14:53:48 +08:00

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

elekids

2019-12-18 18:32:26 +08:00

最大的毛病之一

一定要克服

akira

2019-12-18 18:34:56 +08:00

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

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

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