编程界说的效率是一个带有误导性的概念。有经验的程序员通常把效率定义为，用更少的代码行数，实现更多功能。极客们反对使用代码模板，因为它们为实现更多功能，往往导致算力滥用。

对一般水平的程序员来说，编程效率可以归结为一点：至少在星期五之前，尽可能多地实现他们技术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

创作场景

怎样成为一名高效程序员？