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