这是一个创建于 3783 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
ipoh 2014-07-15 10:33:13 +08:00
优化很重要么
|
 |
2
skybr 2014-07-15 10:36:37 +08:00  7
性能没构成瓶颈前不需要优化, 不然你们以后怎么拿出漂亮的性能提升比给BOSS看?
|
 |
4
qonco 2014-07-15 10:39:26 +08:00
too young too navie
|
 |
5
missdeer 2014-07-15 10:43:04 +08:00
过早的优化是万恶之源。
最近我们leader设计的一个项目各种丑陋到想吐的设计源头都是优化效率，真是受不了了。 |
 |
8
chundong 2014-07-15 11:18:40 +08:00 via iPhone
code review
|
 |
9
fo2w 2014-07-15 11:28:21 +08:00 1
我觉得在谈这个之前理清楚到底是不够优化, 还是没达到基本要求
比如, 明明一个循环可以搞定的事情, 写了2个循环, 这是没达到基本要求, 要说! 但是, 如果是因为一些代码看上去技巧性不够, 或者想当然认为是没有写成最优写法 那还是听ls的, 过早的优化是万恶之源, 一切等最后profilling |
 |
10
nooper 2014-07-15 11:41:57 +08:00 1
code review.
keep small refactor. modify his dirty code. make his branch more conflict files exist.lol. |
 |
11
ine181x 2014-07-15 11:43:40 +08:00
如果是代码写的缺乏可维护性，让其他人需要接手后续工作或他人review时根本看不懂，是问题；如果是性能问题，不是问题。
|
 |
12
leavic 2014-07-15 11:44:49 +08:00
我觉得你可以跟他委婉的说,例如这样:
傻逼你再不改行早晚饿死! |
 |
14
anubiskong 2014-07-15 11:53:56 +08:00 1
你可以让这个人负责审核代码
|
 |
15
summic 2014-07-15 12:05:55 +08:00
我的经验：前期各种设计得很好的项目都不怎么赚钱, 反而是那些 Quick&dirty 的代码赚到了
|
 |
16
Zuckonit 2014-07-15 12:07:47 +08:00
过早的优化是万恶之源。 首先考虑的是可维护性
|
 |
18
princeofwales 2014-07-15 12:12:51 +08:00
原来你们写的代码不考虑性能问题，怪不得还没有成为“资深同事”
|
 |
19
wangdaimishu 2014-07-15 12:13:13 +08:00
请记住互联网六字真言：先上线，再优化！
|
 |
20
66beta 2014-07-15 12:15:09 +08:00 1
码农是不是都想太多，自己做项目的时候，虽然开始前多想好的，但是做着做着就觉得这样更好，那样更好，结果时间拖了再拖，这是不是一个坏习惯？
|
 |
21
solar 2014-07-15 12:28:23 +08:00
lz 图样图森破 拿衣服
|
 |
23
lazyphp 2014-07-15 12:36:57 +08:00
关于过早优化是万恶之源，我不认同。
这得有一个前提，就是你没经验。 如果你做的项目，你有过相关的瓶颈经验。那么过早的优化肯定是一件好事。 不过，能够做相同项目的经历估计很少。所以，多数都是走 先上线，后优化。 |
 |
24
ravenw 2014-07-15 12:52:44 +08:00
你得先确认你的判断是正确的，既然是资深，究竟是别人拖后腿还是你太弱没看懂还不一定呢
抱着请教的态度讨论一下先 |
 |
25
huoshanhui 2014-07-15 13:01:03 +08:00
“还不知道瓶颈所在就匆忙进行优化，这可能是唯一一个比乱加功能更损害设计的错误。”
--《Unix 编程艺术》，优化原则。 |
 |
26
wdlth 2014-07-15 13:03:52 +08:00
你一开始让我优化的时候我是拒绝的，优化得好怎么叫老板加钱上E3？
|
 |
27
vob636 2014-07-15 13:05:32 +08:00
绝壁是互联网箴言！千万别过早优化，产品经理能玩死你，你放心吧
|
 |
28
wenbinwu 2014-07-15 13:15:07 +08:00
新来的同事对我的代码也有这感觉，我只有哈哈一笑
|
 |
29
dustinth 2014-07-15 13:27:24 +08:00
那得看你同事这么写是为了可读性特意为之还是真实的没有注意到, 新手常常犯的错误就是为了优化局部代码让代码可读性变差, 最后实际上瓶颈根本不在那里.
|
 |
30
Livid MOD 3
性能和内存占用这样的东西，是应该有一个系统持续去监控的。并且团队里所有人应该都可以看到这个系统的数据。
在一个有责任心的团队里，如果团队成员在系统中看到了一个可以优化的点，那么有把握的话就进行优化，然后或许第二天整个团队都可以在 APM 系统中看到某个柱子降下去，这对于所有人都是非常有意义的正向反馈。 |
 |
31
t2doo 2014-07-15 14:25:51 +08:00
只求能运行，再丑的代码都是亲儿子，`爹爱你们啊~~~`
|
 |
32
zenwong 2014-07-15 14:32:41 +08:00
为什么要把心思放在研究如何纠正别人的不对上呢？多看看自己，多想想自己。
|
 |
33
raynix OP |
 |
34
jiawenjun1126 2014-07-15 15:42:26 +08:00
@summic 而且很多项目都是设计死的。
|
 |
35
Email 2014-07-15 15:46:01 +08:00
直接打击, 你们的项目根本没有面对市场的希望, 就这样吧,洗洗睡.
|
 |
36
dopcn 2014-07-15 15:57:09 +08:00
我觉得要看自己的位置
如果自己也是资深同事甚至架构 Boss，那直接交流 如果自己是菜鸟，先用代码证实自己的想法吧 |
 |
37
davepkxxx 2014-07-15 16:01:02 +08:00
要避免过度优化
|
|
38
raynix OP > 为什么要把心思放在研究如何纠正别人的不对上呢？多看看自己，多想想自己。
王对张说: 为什么要把心思放在研究如何纠正别人的不对上呢？多看看自己，多想想自己。 李对王说: 为什么要把心思放在研究如何纠正别人的不对上呢？多看看自己，多想想自己。 赵对李说: 为什么要把心思放在研究如何纠正别人的不对上呢？多看看自己，多想想自己。 ... ^_^ |
 |
40
zaishanfeng2014 2014-07-15 16:30:59 +08:00
跟你有关系吗？小孩
|
 |
41
williamx 2014-07-15 16:31:38 +08:00
刚入行的时候写代码性能是第一优先级；不知道什么时候开始性能成了最后考虑的问题了。话说现在时间都花在了诸如：这个名字应该叫什么、这行代码放在这个函数是否合适、这个文件应该放在哪个目录下，这样的事情上了。
|
 |
43
Pixeller 2014-07-15 16:56:13 +08:00
依项目而定, 同时估计下优化能得到的效率或损失, 如果已达到n2增长的bug级别 最好还是趁早说, 如果不是 请别钻牛角尖-.-!, 关键是要求好自己, 对以后自己的项目和团队都有好处.
最后我只能说大部分不关心效率的80%的时间其实都是在写ui和相关逻辑, 优化待到项目完成才进行的我会说请不要搞笑么? 数w行的小项目, 看uml都能头大别说看代码. |
 |
44
zhangdawei 2014-07-15 17:02:39 +08:00
性能优化是迭代出来的，
可维护性优先级更高吧。 |
 |
45
guoxx_ 2014-07-15 17:42:44 +08:00 via iPhone
不是所有的烂代码都能用后期优化当借口的。
以我自己的经验来说，一个有可能比较长的有序数组的插入操作，如果实现成n的复杂度，那是不能接受的，实现成对数复杂度才可以（手机回复，不方便打公式）。这类代码属于写的时候就该想到的事情。 还有关于后期优化，我见过的代码里就真有我上面说的问题的，还是一个很著名的产品。作为library或者framework的提供者，你可能没有机会对你的代码进行详尽的优化，所以建议写的时候多留点心。 另外针对楼主的问题，@Livid的做法很好，条件不允许的话code review也是一个很好的办法。 |
 |
47
a591826944 2014-07-15 17:47:56 +08:00
@williamx 这叫架构。。兄弟你上道儿啦
|
 |
48
cmingxu 2014-07-15 17:53:40 +08:00
先活下来再考虑性能优化， 代码简洁吧；
写代码重在团队协作； 还有一点就是尽量不要给项目内引入只有少数人熟悉的技术， 语言； 这绝逼是万恶之源。 |
 |
51
vjnjc 2014-07-15 23:19:24 +08:00
关于楼主的问题我也考虑过，性能问题不是最优先的，我感觉代码的可阅读性很重要。毕竟机器性能和人力比起来我感觉人力比较宝贵。
|
 |
52
akira 2014-07-15 23:25:30 +08:00
既然是资深了，他自己心里也应该知道什么需要优化 什么不需要优化了吧
|
 |
53
em70 2014-07-15 23:58:44 +08:00
@lazyphp 99%的互联网项目死掉都是因为只有100个用户的时候去考虑一亿用户的事情，快速迭代，先上线跑，不断改进才是正道，QQ就经历过4次大的重构，早期就一个服务器跑，然后两个服务器数据和逻辑分离，然后再上集群，如果马化腾2000年就做个上亿用户的构架，QQ早就因资金链断裂死了
|
 |
54
zjgood 2014-07-16 00:16:27 +08:00 via Android
图样图森破。
飞鸟尽，良弓藏。 |
 |
55
mikuazusa 2014-07-16 00:17:55 +08:00
让测试人员去证明质量就行了。
|
|
56
mikuazusa 2014-07-16 00:19:56 +08:00
@Livid 我们部门已经把这个“APM系统”放到小米电视上去挂在每个部门的办公区显眼处让每个人出入都可以看到最实时的数据。确实很不错。
|
 |
58
hekailiang 2014-07-16 08:03:11 +08:00
可以考虑先设计benchmark test，先拿到性能测试的基准数据。
|
 |
59
2ex 2014-07-16 08:45:16 +08:00
我们这儿资深的都是不优化代码的，用最简单的方式方法完成一个项目，达到需求方的要求就可以了。
时间紧，项目多，如果每个项目都力求完美，那就是给自己挖了个坑。 |
 |
60
cai314494687 2014-07-16 09:52:57 +08:00
code review 是个好方法
|
 |
61
unnya 2014-07-16 10:09:05 +08:00
作为产品狗看完这贴声泪俱下
虽然我的team基本都是最简单实现（第一版）功能加强版（第二版）性能提升（第三版）优化总结（第四版） 做着做着，半年就过去了…… |
 |
62
aurorawu 2014-07-16 10:23:45 +08:00
每个项目都是一个坑～可读性太重要了，性能优化倒其次～
|
 |
63
jarlyyn 2014-07-17 00:22:30 +08:00
看到图标才发现是楼主……
你不是去澳洲了么…… 感觉优化不优化，还是看代码生命期，以及用途的。 非核心用途的，用个几年就要替换的，没必要去优化………… 到是可读性以及可修改比较重要。 |
Select Language