对于大多数程序员而言，努力的方向是否应该是高效编程而非高质量编程？

[vevlins]

感觉自己追求的东西可能是错误的

并非认为两者是对立的，但总是两种方向。高质量编程可能会提高效率但也不总是，如果某个项目从立项开始一直是自己参与的，那高质量编程确实可以提高后来的效率。如果是交接来的烂项目，或者是 leader 不重视的项目呢，追求高质量似乎既不能得到认同，也没有实际产出(对于整个项目能否赚钱，节约人力等)，自己搞得还很累。

高效编程+适度包装似乎更容易在市场中胜出。

[yxx1993]

代码质量越高，代表可维护性好，少踩坑。你的效率也会提高，心情也会舒畅。快乐工作！人也会正能量点

[AoEiuV020]

说的好像努力了就有似的，方向当然是高效又高质量了，

[fe619742721]

团队开发，工作效率应该由有效的工作流程和好用的工具去保证
高质量编程指的是？

[MegrezZhu]

现在高质量，以后才能保持高效…现在低质量了以后总有不得不吃屎的时候（

[wszgrcy]

快速编程吧....有时候自认为完美的实现,下一个需求就给打破了

[cmdOptionKana]

看目的，编程只是手段，服务于目的。

比如，目的是赚钱的创业项目，肯定先追求快速实现需求，质量合格就行，如果过分追求质量必然会慢（或人力成本会高），结果都会降低竞争力。反而等发展起来之后可以花钱重写提高质量。

如果目的是练手提高自己的水平，或者在做一个自己热爱的个人项目，或者想通过开源来展示自己的实力，那就可以做得慢一点，提高质量。

[wjploop]

由于编程需要长期维护以及改动频繁的特点，我们所说的编程高质量不同于建筑工程着重于房子的可靠，而更多是指维护性高，即阅读理解快、修改方便；
而编程高效指实现需求的时间少，包括实现最初的想法以及后续的改动；
故而，我认为编程高质量的最重要体现就是达到编程高效这一目标了，换句话说，高质量的代码保证了后续的维护简单，修改代码快速高效。

而楼主所说的 ”高效“ 应该是说，是否应该追求短期的快，而牺牲长期的快，颇有使用贪心策略求不得最优解的贬义味道。

现实的问题不仅比普通的算法题复杂，也是变化的，很难说哪个更好，一般来说工程大使用高质量，工程小用高效。

实际上，我感觉我经历的工作都是追求高效，很难看得远。

[Jooooooooo]

努力方向应该是学会怎么写文档.

多读金字塔原理吧

[Leonard]

看工作内容吧，需要你长期维护的，你不高质量编程后续也别想高效编程。

[xingshu1990]

高效编程对自己友好一些，高质量编程，对自己对后人友好一些。
然后你要学会争取利益。

有很多人代码写的很好，但是人太老实了，太容易被洗脑，领导哄几句就软下来，久而久之，习惯了呆在舒适区。

[libook]

效率是由速度和质量共同决定的。

好的技术经理会根据实际情况调控速度和质量，并且对技术债务进行有效管控，该欠债的饿时候欠债，该还债的时候还债。

[icy37785]

质量不高效率怎么高的起来，高效和高质量没必要对立起来吧。

[loading]

上班：都想找点下班回家睡觉。
自己项目：先上线再（ bu ）优化。

[lazer911]

时间不够呀，业务复杂，谁管质量

[fkdog]

我觉得目前国内的互联网公司就和那些房地产一样，想着赚快钱，根本就不会太去注意楼房质量。

国内的互联网起项目完全就是为了进场抢份额，发展的好那么后续多投入点资源，发展的不好直接掐掉。
什么高质量有的没的，根本不 care ，项目问题多了就推到重构。

[Thinginitself]

我记得《重构》的作者好像说过，如果质量和功能产生矛盾的时候，开发人员应该尽量选择质量；原因不是因为功能不重要，而且开发人员是唯一对质量负责的人，如果自己都不坚持的话质量就无法控制了，功能方面会有人 push 你完成的。
从长远一丢来看高质量不会导致速度降低的。（理论上）当然实际工作里，你老板强行要求你明天就上线，那这个问题你也没得选啊。。。

[p2pCoder]

大家都在商业公司工作，商业价值才是核心
谷歌的代码也看着蛋疼

[2i2Re2PLMaDnghL]

怎么算「高质量」？
:() { :|:& }; :
这段代码质量高吗？

[timethinker]

看场景啊，比如说就一个原型项目，就不会去考虑太多东西，怎么快怎么来，当然如果你在快的同时还能够依据自己的经验和知识构建出维护性高的质量那就再好不过了，因为原型也是需要修正的嘛。

我理解的那种超级规范的的大项目，应该是在构建之前就已经累积到了足够的知识，进行了大量的设计准备，完全具备可行性，那么编码只是体力活，要保证这个体力活干的规整。就像泥瓦工，一砖一瓦，结结实实不偏不漏，质量能够经受得住时间的考验。

[3dwelcome]

不论是个人的水平限制，还是项目的迭代重构，现在写的代码，早晚都要推到重来的，没必要那么追求完美。

代码自我进化，就是一个不断的试错过程。只有重构，才会进步。

我们都是普通人，很少代码写完能用好多年的，只有大神才可以。

[a1562619919]

需要中长期维护的，偏向高质量；不需维护发展的，只是挣快钱的，越快越好

[NewConn]

如果是 To C 企业项目，业务复杂，且一直有用户提新需求，个人建议还是快速编程吧。
原因：假如你采用高质量编程，基于现在需求，做出来了高质量架构和设计；但下一次需求变动，就可能让你的架构不得不加一些补丁般的 if-else 以及一些表字段；更有甚，有些需求来了之后，哪怕你写 if-else ，也会导致性能大幅下降。以上场景在 To B 的企业业务中经常见到，是不可预知的，不随你的远见和业务设计能力提高而改善。

当然如果是 To C 项目，业务需求完全根据自己节奏来，而不是根据用户需求堆业务逻辑，建议还是采用高质量编程。

最重要的是，根据 Leader 的偏好去做

[NewConn]

如果是 To B 企业项目，业务复杂，且一直有用户提新需求，个人建议还是快速编程吧。
原因：假如你采用高质量编程，基于现在需求，做出来了高质量架构和设计；但下一次需求变动，就可能让你的架构不得不加一些补丁般的 if-else 以及一些表字段；更有甚，有些需求来了之后，哪怕你写 if-else ，也会导致性能大幅下降。以上场景在 To B 的企业业务中经常见到，是不可预知的，不随你的远见和业务设计能力提高而改善。

当然如果是 To C 项目，业务需求完全根据自己节奏来，而不是根据用户需求堆业务逻辑，建议还是采用高质量编程。

最重要的是，根据 Leader 的偏好去做

[jones2000]

首先是功能完成验收,上线,收钱,发工资， 其他的有空时间就做做，没时间就不做了。

[jiayong2793]

国内的环境不可能涉及底层，所以努力封装各种组件吧，成立自己的组件库，并且文档明确详细的需求和适用场景，遇到适用的直接黏贴复制，类似的修改组件兼容类型场景并更新文档，慢慢的你会得到一个适用于大部分企业需求的组件库

[kkocdko]

设计模式对抗需求变更 balabala

[ClericPy]

自己找 balance 吧, 现在被逼着写了不少反模式的东西了, 需求方根本不在乎把事情做对, 只要做他们认为对的就行了

[shyangs]

敏捷開發.
高效編程.
推到重來.

[ericgui]

我觉得还是先把代码糊出来，然后再考虑重构，重构只有等到业务稳定了，你才有可能重构
要是天天变，你没机会写出来好代码的

[sadfQED2]

都不对，应该是提高 ppt 能力，提高向上管理的能力才能升职加薪。亲眼见过把 nginx 换名包装成自己的东西，然后一通演讲，最后升职的

[liuxingdeyu]

质量这事，在开始的时候注意，会慢，慢慢习惯了，也就肌肉记忆了，然后坑少效率其实也就高了，所以这俩加速，一个是相对线性，一个是更像一个反向抛物线