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

  96894b246dce26c23ced092edfabf34b.jpg

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