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

[vevlins]

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

[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]

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