研发效率管理之技能篇系列一

说明：这个系列主要描述一些自己在工作过程中的一些思考，仅代表个人观点，内容上会想到哪里写哪里，不存在严谨的结构性

一、抽象和分而治之

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

把一个系统拆分为几个有限的子系统，每个子系统涵盖某一方面的内容，并将其复杂性隐藏起来，只对外暴露关键信息。这样，我们在研究这个系统的时候，就无需考虑其子系统的细节，从而对整个系统进行有效的思考。如果我们需要深入了解某一个子系统，再打开这个子系统来看即可。

以此类推，如果这个子系统还是很复杂，我们可以再对其进行拆分。这样一来，在任何时候，我们思考时面对的元素都是有限的，复杂度也下降到了大脑的能力范围之内，从而完成对一个复杂系统的理解和处理。这个拆分处理的过程，就是我们常说的分而治之；而用子系统来隐藏一个领域的内部细节，就是抽象。抽象和分而治之，是我们理解世界的基础。

比如，我们在了解一张简单的桌子时，首先想到的是它由 1 个桌面和 4 条桌腿组成。那么，桌面和桌腿就是子系统：桌面就是一个抽象，代表实现摆放物品功能的一个平面；桌腿也是一个抽象，代表支撑桌面的结构。

如果我们需要进一步了解桌面或者桌腿这两个子系统，可以再进一步去看它们的细节，比如两者都有形状、重量、材料、颜色等。但如果一上来就考虑这些细节的话，我们对桌子的理解就会陷入无尽的细节当中，无法快速形成对整个桌子的认知。

软件开发也是这个道理，我们必须做好抽象和分而治之，才能做出好的程序。

提高抽象和分而治之效率的一个技巧是，在设计代码架构时注意寻找合适的设计模式。在实际工作中，功能往往比较大。如果只用一个提交完成一个功能，那这个提交往往会比较大，所以我们需要把这个功能再拆分为子功能。比如，某个后端 API 的实现，我们很可能会把它拆分成数据模型和 API 业务两部分，但如果这样的提交还是太大的话，可以进一步将其拆小，把 API 业务再分为重构和添加新业务两部分。

总之，我们的目的是让每个提交都做成能够独立完成一些任务，但是又不太大。一般来说，一个提交通常不超过 800 行代码。

二、快速迭代

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

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

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

在工作中，因为往往是在一个比较大的系统里工作，不能很容易地运行新代码。这时，我们可以编写脚本或者单元测试用例来触发新写的代码。通常情况下，我们更倾向于使用后者，因为这些测试用例，在功能开发完成上线之后，还可以继续用于保证代码质量。在我看来，在开发过程中，能触发新写的代码帮助我开发，是单元测试的一个重要功能。

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

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

实际上，这是代码提交原子性的另外一个重要特点，即代码提交的原子性，可以保证主代码仓在理论上能够随时基于 master 分支上的任何提交，构建出可以运行的、直接面对用户的产品。在这种方式下，每个开发者在任何时候都可以基于 origin/master 进行开发，从而确保 Facebook 几千人共主干开发时分而治之能够顺利进行。

关于实现代码提交的原子性，我还有一个小技巧，就是如果当前编写的代码提交实在不方便马上推送到 origin/master 分支上，我们也可以频繁地 fetch origin/master 的代码到本地，并在本地对 orgin/master 进行 rebase 来解决冲突。这样就可以确保，我们开发的代码是基于最新的主仓代码，从而降低代码完成之后 push 时冲突的可能性。

第三条原则：尽可能的避免重复（DRY）

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

具体来说，首先是寻找重复的逻辑和代码。在动手实现功能之前，我们会花一些时间在内部代码仓和知识库中进行查找，寻找是否有类似的功能实现，以及一些底层可以复用的库。找到重复的逻辑和代码之后，主要的处理方式是，把共同的部分抽象出来，封装到一个模块、类或者函数等结构中去。如果在开发新功能时发现有需要重构的地方，一个常见的有效办法是，先用几个提交完成重构，然后再基于重构用几个提交实现新功能。

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

这些重复的流程也需要 DRY，最主要的办法是自动化。以重复的测试数据产生、删除流程为例，一般的做法是，编写脚本进行自动化，当然有些时候也需要写一些复杂的可执行程序来生成数据。

流程重复还有一个特点是，它常常和团队相关，也就是说很多成员可能都会重复某些操作，这样的操作更值得自动化。比如，团队的很多成员常常都需要产生测试数据，这时我推荐你主动对其进行自动化、通用化，并提交到代码仓的工具文件夹中供团队使用。

第四条原则：使用工具

开发过程中有很多好用的编码工具可以使用，比如时下流行的AI编码以及IDE的一些自动生成或者补全编码的插件，我们要多利用，减少那些标准化、重复性的编码工作。

待续。。。。。。