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

[asuka321]

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

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

[q397064399]

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

[daodao116]

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

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

[lishali12345]

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

[kinghly]

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

[catinsides]

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

[yiyi11]

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

[userdhf]

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