从一个程序员的角度来说，相同时间内应该写更多的代码还是写更细致的代码

[asuka321]

抛开分配的工作量不看，对于一个程序员个体来说，下面 2 种哪个更好 /成长快 /快乐 1.写更多代码，了解更多的业务内容，开拓更广的技术眼界 2.写更细致的代码，如进行更多的容错考虑，更多的细节补充来对某一领域下的知识有更深入的理解

对我个人而言是更喜欢 2 的，写更细致的代码会让我更有成就感，但随着技术在一层层的演进，个人能思索到的细节或者优化点在以后可能就是框架或者语言特性所直接支持的，比如那个 c++程序员嘲笑 java 程序员用 go 写网络编程那个梗。那这样对于一个程序员来说花费的时间从长远来看就是不值得的，这其中可能有很多成就感，但这对于个人成长真的有帮助吗

[congeec]

前两天刚讨论的
https://kevinmartinjose.com/2019/04/08/programming-doing-it-more-vs-doing-it-better/
https://www.reddit.com/r/programming/comments/bam7wf/programming_doing_it_more_vs_doing_it_better/
https://news.ycombinator.com/item?id=19600440

[1KN6sAqR0a57no6s]

http://www.yinwang.org/blog-cn/2015/11/21/programming-philosophy

[ericgui]

看老板要求了

[rogwan]

代码可复用性高，就需要精写，反之能用就行。代码计划跑 10 年要精写，只准备跑 10 天能用就行，

[auciou2]

@rogwan 十分赞同！

[lkmountain]

@congeec 😃

[Everyman]

相同时间内写更细的代码，你写的多了，慢慢就会写得越来越快。
相同时间内写更多的代码，你写的多了，也只会越来越快，不会越来越细。

就像行走和跑步，走都还走不稳，怎么跑得快？

[xmitman]

好代码是财富，烂代码是垃圾，相同的时间当然是用来创造财富的。效率而论，生产垃圾太多，你还要花时间去扫垃圾，而财富是可以增值的

[yaoyuan131617]

看你在乎自己还是在乎老板了。。。

[xuanbg]

写更多代码❌
写更精细代码❌
解决更多问题✅

[qingfengxm]

关键很多需求不会给你很多时间的，实现功能了再说，再说了，很多需求说不定没上线就夭折了，还有一部分需求上线之后夭折了

[pipinstallpy]

我只能说编程明明是智力游戏，偏偏被一些人玩成了体力游戏

[kimqcn]

先完成功能，然后有时间再慢慢打补丁

[dnsaq]

一般公司都是仅仅完成需求，甚至不会考虑性能更别提优化了

[auciou2]

@pipinstallpy 赞同！

[auciou2]

编程不仅是智力游戏，而且是超高难度、巨大工作量。

[ben1024]

写最快的时间完成功能的代码
时间区间是一个周期性的问题（是一周，还是一年）

[ChnMig]

看情况啊，有时候就是要赶工

[passerbytiny]

大兄弟，生产代码不是车间生产产品，不走量。

[pmispig]

当然是更多的，因为写不完就要加班

[q397064399]

看老板给的钱 + 时间，任何时候都要考虑成本，要是每天都加班 收入又不高，为什么不多 copy 几次，
写好代码的能力 我也有啊，事先分析 做好良好的设计 做好业务模块隔离 抽象出能复用的业务代码 隔离会变化的代码。
这些我都会啊，但是看在钱 + 时间的面子上，ctrl + c 跟 ctrl + v 就能搞定的事情，费那么多脑子干嘛？

[daodao116]

个人提升来说，就是写更精致的代码。

项目角度上来说，主要看进度压力了，先完成任务为优先（不过这两者并不矛盾，有时候设计的好，可复用性，组件化的代码是能大幅度提高效率的），完成任务之后，有时间的情况下，可以整理一下代码，重构一下。（不过大部分时候都是没时间的了，哈哈哈哈）

[lishali12345]

程序员需要向工程师这个维度看齐吧，工程师通常都是在条件和资源有限的情况下进行交付的，我们需要提供的是解决方案。不同的项目，不同的时期，能够提供的空间应该是不同的，而不同阶段的程序员对自己的要求也是因时而异的，恐怕很难有很清晰的界限。从我自己的角度来看的话，我是愿意接触尽可能多的业务场景相关的代码工作的，因为这样才能应用，当然我们无法排除的一点就是，可能很多业务代码都是简单重复性的劳动，而在我们做简单重复的业务代码的同时，实际上可以考虑做细致的代码工作，因为重复得多了，就能发现很多的模式会出现，尝试去做抽象，慢慢地业务广度和细致也就都会有了。另外想说的一点就是不同的项目，不同的公司，产品不同的阶段，对于项目代码的质量要求确实会有不尽相同之处的，很难一概而论吧。而业务广度和追求细致应该不冲突，合理地分配时间和精力，在合适的时间点做出合适的选择，应该会更舒服一些。

[kinghly]

尽可能在有限时间内写更好的代码。先思考后动手。

[catinsides]

以前喜欢写自以为很牛波的代码，
现在是写更容易让别人看懂的代码。

[yiyi11]

写尽量平衡工作进度和维护工作量的代码。

[userdhf]

工作的东西吧，只要过得去就行，精益求精浪费时间