编程界说的效率是一个带有误导性的概念。有经验的程序员通常把效率定义为，用更少的代码行数，实现更多功能。极客们反对使用代码模板，因为它们为实现更多功能，往往导致算力滥用。
对一般水平的程序员来说，编程效率可以归结为一点：至少在星期五之前，尽可能多地实现他们技术 Leader 定义的功能点。
在一个朝九晚五，一周工作 5 天的日常工作环境中，这会给你一种成就感：运行顺畅的 Demo，不算太糟糕的反馈——无论 3 个月后这些代码会引起多大程度的退化。
所以下面我将介绍一些关于编程效率的小技巧，它们能让你避免出现事后补救这样的尴尬场面。
总是先进行 UI/ 测试用例开发
如果你的项目涉及到 UI，先实现 UI 然后再实现功能开发，这总是会带来一些好处。不管你想怎样辩驳，用户体验(UX)决定了带给用户的价值。
但是团队里已经有了一个负责 UX 的人——难道这不应该是他的责任吗?
当然。但是，一个可以正常演示的 Demo 总是会激发团队集体心理上的二次思考。人们自然地会在第二次审视时容易发现需要改进的地方。
除非你写出了 100% 解耦合的代码，否则，UI 的改动多半会引起 view-model 的改动，这可能会导致模块 / 类的重写。
UI 的开发还会让相关人员培养起一种早期验证他们想法的意识。它会让整个团队感受到项目的进展，也会给你这位功能开发人员在添加功能之前带来一些缓冲余地。你可以利用这段无压力的时间来开发模型和网络部分。
如果项目里不涉及 UI，你就可以从测试驱动开发(TDD)起步了。TDD 的好处在其整个工业界都是广受欢迎的，而且你肯定会因此而从后面的开发周期中受益。
……除非你应该开始编写糟糕的代码
如果你从没有写过压缩文件的代码，你将怎样开始开发一个全新的文件压缩工具?
UI 已经不在讨论范围内了。测试将会产生帮助，但这一开始不会给你带来任何的成就感或者认可度。
这里你需要的不是效率，而是一种能驱使你完成这次全新开发的力量，某种动机。
一种信念，坚信该项任务能够完成。你可以完成它。
首先验证一些核心想法，不要去关心 UI/ 测试 / 功能参数。衡量你的结果：
和 gzip 及其他同类型算法相比，你的压缩算法在时空上的效率如何?
产业界如果选择你的算法，而非其他免费的解决方案，产业界愿意向你支付多少?
和团队成员讨论你的发现。在周五聚会上，或者投资人峰会上，给他们一些值得吹嘘的发现。
你是否把 COMPRESSION_QUALITY_RATIO 这个参数硬编码在了代码里，或者忽略了验证文件大小这个步骤，在这个阶段，这些步骤其实都不重要。
这里的关键因素不是成功完成任务，或者有一个精心设计的复杂实现。而是要确定你是否能做这件事情，以及整个团队能否开发出这个工具 / 方法，以此赢得更多的开发时间，争取成为一名 MVP。
对 CPC(Copy/Paste/Clone：复制 / 粘贴 / 克隆)开放一些
曾经有一代程序员流行过这样的思潮，即一个程序员如果从 StackOverflow 或者 GitHub 复制粘贴代码，那就不是一个优秀的程序员。
这种思潮属于纸质程序员的年代，那时互联网发展还不成熟。同一时期，他们也很少接触多元化的技术 / 语言，所以他们会从 API 文档亲自实践写代码。
而实际上，为了在真正重要的事情上变得有效率，所有高效的程序员很大程度靠着复制粘贴来完成常用的功能。
一段摘自 StackOverflow 顶尖开发者回答中写文件操作的代码，将会比你自己通过阅读可怕的文档写出来的代码效率要高 1000 倍。
当然，你的才华将在以下方面展现出来：你将决定是从 UI 主线程还是后台线程实现写文件操作，或者通过某种缓存来解决它。
同样的，从其他地方复制粘贴这段后台操作 / 缓冲操作代码，并把它们合在一起。
所有伟大的程序员都有过这样的经历。许多年之后，你就会写出带有自己风格的完美代码啦。
阅读、阅读，再阅读
如果我有 8 小时来砍到一颗树，我将先花 6 小时把我的斧头磨得锋利一些。——传统谚语
当浏览关于开发的技术故事时，你会看到学习重要的编程概念和及时完成开发功能一样重要。
产业界最佳开发实践的知识可以在以下方面带来极大的改进：
你编写的代码质量
你在会议上讨论的想法
你的长期职业规划
大致的技术范畴
如果你要在周四的活动上发布一个功能，你应该花上整个周一时间来阅读了解这个功能，不要写哪怕一行的代码。
把 Google 当做你的朋友，试着用不同词语组合搜索你的主题、代码库和涉及到的框架，以及更深层次的概念。
例如，如果你需要写一个网站的登录模块，你的在线阅读内容必须包括 OAuth 、 Passport 和其他第三方模块，以及密码加密。
Copy/Paste/Clone 理想情况下应该在周二晚上进行，甚至是周三早上，这时你应当完全熟悉相关概念、代码段和各种回调函数。
到那时，你将能够从最佳的代码源那里复制粘贴代码过来。
如果你的团队或者技术主管不赞成这个做法，哪怕只进行十分有限的复制粘贴，那这将为你在该公司亮起一盏红灯。请使用以下策略：
继续阅读，不用管他们是否赞成。如果你想避免冲突，那就阅读编程的书籍吧。
当然，办公时间建议的这些研究不包括观看你最喜爱名人的 Instagram，除非你在开发 Instagram 的竞品。那会是一个完美的理由。
保持发布代码。
继续求职面试吧，在你从阅读中有了突破后就跳槽。
一个编程公司如果把阅读视作低效活动的话，那就不值得继续为其工作了。
结论
不像其他产业能以每小时每人这样的单位来计算效率，编程效率没有普适标准。以上要点虽然可以帮助我们定义它，但仍然很主观。
遵循某些效率相关的技巧能帮助你提高产出估算的能力。随着更好的估算，你可以在更短时间发布更高质量的代码。切记效率绝不应该以牺牲你的个人生活质量为代价。
这些效率方面的小技巧只是一个开端。随着你的经验越来越丰富，在连续不断的实验中培养出你自己的最佳实践：在不同的任务中、与不同的同事，最重要的是，在不同的习惯中进行各种实验。
原文链接：
How to Be a Productive Programmer
