两个方法中有相同的部分就会想办法把这些相同的部分独立作为一个新方法，再在原方法中调用，浪费了不少时间

[kaiki]

每次写东西都会去“优化”这些跑起来根本没问题的地方，经常能优化出问题，然后再修复，有可能最后优化完了还是觉得第一版好用，但是两个方法中有重复代码，就觉得不舒服。 主要是自己的东西，给别人写的能跑起来就行，优化，不存在的。

[eason1874]

改进时：这会是完美的改进，改完就完美了
测试时：啊，操了
修复中：....
放弃了：嗯哼，去 NMD 吧
得结论：还是旧版好用

其实 1999 年地球人已经联系上了三体人，和三体人对话的地球人是一位程序员，他问三体人宇宙真理是什么，三体人回答：不要优化，不要优化，不要优化

[enchilada2020]

@eason1874 哈哈哈这小剧场真带劲儿

过早优化是万恶之源 by 鲁迅

[whileFalse]

这时候不应该反思自己的编程水平么。

[Lighfer]

永远不要仅仅因为“有相同的代码部分”就合并成一个方法，并认为这是一种优化

[Hurriance]

我的想法是，不要随便抽别人的方法，除非很明确能够处理好整个调用链路，即便这样，也抵不住业务频繁的变更，丑就丑点吧

[learningman]

"两个方法中有重复代码"
但是你抽出来作为一个函数，就要维护原来的整个上下文，累死，又不是 #define

[sagaxu]

我经常优化到一半然后回退代码，有时已经改了几百行了

[kaiki]

@learningman
我可以把它做得更好！->它这么做也不是没理由的。->又不是不能用。

[sundaydx]

@kaiki 这个内心剧场属实了

[qq296015668]

@kaiki 擦，真实。

大家日常协同的时候，比如发现自己或者其他同事的代码有类似问题的时候会一起沟通然后优化吗？还是不想多事 ctrl + c + v 完事？

我发现小团队大家关系比较融洽的时候，这样做往往会有意想不到的惊喜（沟通使人 ___）。
但是在一些比较大的团队或者项目中，很少会进行优化或者沟通（除非是老大发现喊一起改）。

[msg7086]

我写代码很少会单个方法写得太长。
如果你玩过 Ruby 用过 RuboCop ，这货的默认规则一个类不能超过 100 行，一个方法不能超过 10 行。
我感觉这是极端了一些，不过如果你一个方法上百行的话，一般来说是有点过长了。

我一般写的时候，比较独立的功能都会主动拆出来做成方法。
交上去的代码本来就不太会有又臭又长的方法。
这种情况下如果需要复制粘贴，我也就复制粘贴了事了。

比较大的团队的话，写得又臭又长的代码在我们这是过不了代码审核的。
就算我看的时候睁一眼闭一眼过了，更高级别的同事也会 reject 掉，打回去重新改。
（如果经常被打回去重新改，可能就要吃 PIP 滚蛋了。）

[nekoneko]

@msg7086 #11 我 java 的,按这个标准,那些写 java 源码的人都可以滚蛋了