研发效率破局之道阅读总结(4)个人效率

研发效率破局之道阅读总结(4)个人效率

Author: Once Day Date: 2025年4月30日

一位热衷于Linux学习和开发的菜鸟，试图谱写一场冒险之旅，也许终点只是一场白日梦…

漫漫长路，有人对你微笑过嘛…

全系列文章可参考专栏: 程序的艺术_Once-Day的博客-CSDN博客

注: 本文内容摘抄于原文，文中"我"代表原作者【葛俊】大佬视角。

参考文章:

• 研发效率破局之道

---

1. 提高个人效能

（1）第一条原则：抽象和分而治之。

把一个系统拆分为几个有限的子系统，每个子系统涵盖某一方面的内容，并 将其复杂性隐藏起来，只对外暴露关键信息。

这个拆分处理的过程，就是我们常说的分而治之；而用子系统来隐藏一个领域的内部细节， 就是抽象。抽象和分而治之，是我们理解世界的基础。

拿到一个任务之后，我们要做的首先就是进行模块的定义，也就是抽象，然后对其分而治之。

提高抽象和分而治之效率的一个技巧是，在设计代码架构时注意寻找合适的设计模式。

设计模式指的是，设计过程中可以反复使用的、可以解决特定问题的设计方法，最经典的莫过于《设计模式：可复用面向对象软件的基础》中列举的 23 个设计模式，以及针对企业软件架构的《企业应用架构模式》。同时，我们还要注意公司内部具体的常用模式。这些模式都是经实践检验有效的，且传播较广容易理解，都可以作为你进行模块拆分的参照。

具体实现功能的过程中，也会处处体现分而治之的思想。最主要的一个表现是，每个开发者都会把自己的代码尽量做到原子性。代码的原子性指的是，一个提交包含一个不可分割的特性、修复或者优化。

在实际工作中，功能往往比较大。如果只用一个提交完成一个功能，那这个提交往往会比较大，所以我们需要把这个功能再拆分为子功能。

（2）第二条原则：快速迭代。

第一，不要追求完美，不要过度计划，而是要尽快实现功能，通过不断迭代来完善。优秀的架构往往不是设计出来的，而是在实现过程中逐步发展、完善起来的。

有些开发者过于追求技术，投入了大量时间去设计精美、复杂的系统。这样做没有问题，但 一定要有一个度，切忌杀鸡用牛刀。因为复杂的系统虽然精美，但往往不容易理解，维护成 本也比较高，修改起来更是不容易。

第二，在设计的实现中，尽量让自己的代码能够尽快运行起来，从而尽快地验证结果。我们常常会先实现一个可以运行起来的脚手架，然后再持续地往里面添加内容。

第三，为了能够快速进行验证，一个重要实践是设置好本地的代码检验，包括静态扫描、相关单元测试的方便运行，以及 IDE 能够进行的实时检查等。

第四，代码写好之后，尽快提交到主代码仓并保证不会阻塞其他开发人员。

（3）第三条原则：DRY。

DRY，也就是不要重复你自己，是很多开发模式的基础，也是我们非常熟悉的一条开发原则了。比如，我们把一段经常使用的代码封装到一个函数里，在使用它的地方直接调用这个函数，就是一个最基本的 DRY。

代码逻辑的重复，不仅仅是工作量的浪费，还会大大降低代码的质量和可维护性。所以，我 们在开发时，需要留意重复的代码逻辑，并进行适当的处理。

在编程工作中，除了代码的重复外，比较常见的还有流程的重复。比如测试中，我们常常需 要重复地产生一些测试数据，运行完测试之后再把这些数据删除。

2. 聚焦工作

在任务多、干扰多的现状下，如何最高效地利用时间，去做最重要的事儿，同时有更多的时间来放松和享受生活。

在我看来，这个问题的答案就是深度工作，聚焦最有价值的事儿。 深度工作这个概念，是由 卡尔 · 纽波特（Cal Newport）提出的，指的是在无干扰的状态下，才能专注地进行的专业 活动。这样的活动能够使个人的认知能力发挥到极限，从而让我们创造出最大价值，成为一个不可替代的人。

（1）以终为始，寻找并聚焦最重要的任务

GTD 的创始人大卫 · 艾伦（David Allen）提出，日常任务可以分为 3 种：

• 预先计划的任务（Pre-defined Work），比如迭代之初就计划好了的功能开发任务；
• 临时产生的任务（Work As It Appears），比如 Bug、邮件、临时会议等；
• 自己定义的任务（Defining Work），即根据当前状况，自己决定需要做的任务。

在我看来，我们要把更多的时间和精力放到自己定义的任务上。你可能会觉得，前两种任务已经够多了，也非常重要。但其实，我们容易忽略的第 3 种任务，可以帮我们减少前两种任务中不必要的浪费。

因为，预先计划好的任务的优先级常常会随着情况的改变而改变，而临时产生的任务很可能当时觉得很紧急，但实际上是可以推迟或者甚至不做的。

（2）聚焦目标，以终为始

聚焦目标，以终为始，其实就是在自己定义任务。因为时间有限，为目标服务的任务才最重要。作为高效开发者，常见的目标包括业务成功、帮助团队，以及个人成长这 3 个。如果能找到三者重合的任务就最好不过了。

日常工作中更常见的情况是，三者不能兼得。这时，我们首先应该关注业务成功，因为它是我们工作的最基本目标，是基础。在此之上，我推荐先考虑帮助团队成长。因为帮助团队的同时，往往会给自己带来一些直接或间接的成长机会。

（3）无情的筛选，少即是多

生命有限，而工作无限，所以我们必须要无情地排优先级。

很多人都有一个倾向，就是贪多，认为越多越好，我曾经也这样。在自己的书单里添加了几 百本书，书签页中添加了几百篇要读的技术文章，Todo List 里添加的任务也越来越多，还 计划学习这个语言、那个框架。但实际做起来，却因为时间有限，不但只能浅尝而止，还让 自己很疲倦。痛定思痛，我下决心去做减法。

在我看来，“数字 3 原则”很有效，也就是强制把要做的事、要达到的目标，都限制在 3 个以内。

3. Git使用技巧

毫无疑问，Git 是当前最流行的代码仓管理系统，可以说是开发者的必备技能。它非常强 大，使用得当的话可以大幅助力个人效能的提升。一个最直接的应用就是，可以帮助我们提 升代码提交的原子性。如果一个团队的成员都能熟练使用 Git 的话，可以大大提高团队代码 的模块化、可读性、可维护性，从而提高团队的研发效能。

代码提交的原子性指的是，一个提交包含一个不可分割的特性、 修复或者优化。如果用一个提交完成一个功能，这个提交还是会比较大的话，我们需要把这 个功能再拆分为子功能。

为什么要强调代码提交的原子性呢？这是因为它有以下 3 大好处：

• 可以让代码结构更清晰、更容易理解；
• 出了问题之后方便定位，并可以针对性地对问题提交进行“回滚”；
• 在功能开关的协助下，可以让开发者尽快把代码推送到 origin/master 上进行合并。这正是持续集成的基础。

（1）把工作区里代码改动的一部分转变为提交。

如果是把整个文件添加到提交中，操作很简单：先用 git add <文件名> 把需要的文件添加到 Git 暂存区，然后使用 git commit 命令提交即可。这个操作比较常见，我们应该都比 较熟悉。

但在工作中，一个文件里的改动常常会包含多个提交的内容。比如，开发一个功能时，我们常常会顺手修复一些格式规范方面的东西；再比如，一个功能比较大的时候，改动常常会涉及几个提交内容。那么，在这些情况下，为了实现代码提交的原子性，我们就需要只把文件里的一部分改动添加到提交中，剩下的部分暂时不产生提交。针对这个需求，Git 提供了 git add -p 命令。

（2）对当前提交进行拆分。

可以先“取消”已有的提交，也就是把提交的代码重新放回到工作区中，然后再使 用 git add -p 的方法重新产生提交。这里的取消是带引号的，因为在 Git 里所有的提交都是永久存在的，所谓取消，只不过是把当前分支指到了需要取消的提交的前面而已。

（3）修改当前提交

如果只需要修改 Commit Message 的话，直接使用 git commit --amend 命令，Git 就会 打开你的默认编辑器让你修改，修改完成之后保存退出即可。

如果要修改的是文件内容，可以使用 git add、git rm 等命令把改动添加到暂存区，再运行 git commit --amend，最后输入 Commit Message 保存退出即可。

（4）交换多个提交的先后顺序

有些时候，我们需要把多个提交交换顺序。比如，master 分支上有两个提交 A 和 B，B 在 A 之上，两个提交都还没有推送到 origin/master 上。

这时，我先完成了提交 B，想把它先单独推送到 origin/master 上去，就需要交换 A 和 B 的位置，使得 A 在 B 之上。我可以使用 git rebase --interactive（选项–interactive 可以 简写为 -i）来实现这个功能。

（5）修改非头部提交

在工作中，为了方便实现原子性，我们常常需要修改历史提交，也就是修改非头部提交。对历史提交操作，最方便的方式依然是使用强大的 git rebase -i。

4. 命令行

GUI 图形界面的出现是计算机技术的变革，极大方便了用户。但在这么多年后的今天，命 令行工具为什么仍然有如此强大的生命力呢？

对软件工程师来说，想要高效开发就必须掌握命令行，主要原因包括：

• 虽然鼠标的移动和点击比较直观，但要完成重复性的工作，使用键盘会快捷得多。
• 这一点从超市的结算人员就可以看出来，使用键盘系统的收银员总是噼里啪啦地很快就可以完成结算，而使用鼠标点击的话明显慢很多。
• 作为开发人员，可以比较容易地使用命令行的脚本，对自己的工作进行自动化，以及和其他系统工具联动。但使用 GUI 的话，就会困难得多。
• 命令行通常可以暴露更完整的功能，让使用者对整个系统有更透彻的理解。Git 就是一个 典型的例子，再好的 GUI Git 系统都只能封装一部分 Git 命令行功能，要想真正了解 Git，我们必须要使用命令行。
• 有一些情况是必须使用命令行的，比如 SSH 到远程服务器上工作的时候。

5. 高效沟通原则

沟通是高效工作的重要软技能：

第一个原则是，沟通时要有同理心。我们沟通的目的，是在对方身上起作用，要从别人的角 度考虑怎样去沟通。所以，我们需要了解以下三个方面的信息：

• 一是，对方的知识背景，从而使用他能理解的语言去沟通；
• 二是，对方想要知道什么，才能不绕弯路高效答复；
• 三是，对方的出发点，根据他的出发点将对话引向双赢的方向。

第二个原则是，外在表现很关键。中国的文化比较内敛，我们从小受到的教育也强调内在美，忽视外表，这就会引导我们形成忽视外在表现的习惯。因此，我在美国工作时吃了不少亏，做出的东西，却被会表现的人抢走了大部分功劳。这才逐渐认识到，这种“内敛”实际 上是不对的，很多情况下外在表现更重要。

外在表现很关键这个原则，在开发工作上表现为我们不但要重视实际的工作，也要重视别人对我们工作成果的感知。很多开发者从内心抵触 PPT，我觉得这就是高效工作的一个重要阻碍。我们确实需要花一些精力，去考虑如何把我们做出的东西更好地呈现出来。

第三个原则是，冰山原则，是美国软件界大佬 Joel Spolsky(周思博)提出来的。

这个原则对软件技术人员和非技术人员间的交流非常有用，指的是一个软件应用系统比较复杂，就像一座冰山。但是，它表现在外面的只是一小部分，就像冰山露出水面的部分一样。 如果你沟通的对象对软件不熟悉的话，他就会认为，冰山上的可见部分就是全部工作，或者说是绝大部分的工作。

这样的结果就是，软件开发人员在做项目进展演示的时候，如果演示得很完整、漂亮，对方就会认为你的工作做得差不多了，即使你已经提前强调过这只是在界面上做的一个 Demo，也不会有效果。因为对方在潜意识里，就认为你的工作已经做得差不多了。

所以，我们在做演示的时候，要尽量把界面的完成程度和项目的进展程度对应起来。比如， 不要把界面做得太漂亮，显示的文字可以用“XXX”，而不要用真实数据等。