谈一谈我对协同开发的一些认识

如今各互联网公司普通都使用敏捷开发，采用小步快跑的形式来进行项目开发。如果是小项目或者小需求，那一个开发可能就搞定了。但对于电商等复杂的系统，其功能多，结构复杂，一个人肯定是搞不定的，所以都是很多人来共同开发维护。以我曾经待过的商城团队为例，光是后端开发就有七十多人。

为了更好地开发这类大型系统，往往把这种大型系统拆分为多个模块，团队成员也进行分组，每个组负责开发其对应的模块。于是，当有涉及到多个模块的需求进来时，往往就需要多个组的人协同开发。

这里我想谈两个问题：

1、假如有涉及到多个模块的需求进来时，有的组需求已经拉满了，所有人都在做别的需求，当前没有空闲的人力，这个时候怎么办？

2、参与此次需求的每个开发同学，是否都应该对这个需求有足够的了解，知道需求的来龙去脉以及各个模块之间如何做配合的？

对于问题1，通常是由PM或者项目owner去找到对应组的组长去做资源协调，组长给出一个可以进行开发和联调的时间，PM或owner再根据这个时间来协调其它组的时间，制定出整个项目的开发、联调、测试与上线的时间。

但我曾经待过的一个开发团队，在某个组当前没有人力时，就把这个组的开发需求分配给其它有人力的组，直接让其它组去把这个组的代码一起开发了。于是后来大家都这么干了之后，慢慢的，当有多模块的需求再进来时，直接就分给某个组了，然后这个组就去改其它组的代码，把所有的模块都给开发了。

但这样就衍生出了许多问题。首先，你去改其他组的代码，你不清楚他们原来的代码逻辑，所以你的先花一定的时间去熟悉被人的代码。假如你改到了一些隐藏的逻辑，那就容易出线上问题，而且别人来改你的代码，也会有相同的问题。其次，别人把你的代码改了之后，可能就破坏了你原有的逻辑。当你的同一段代码多其他人多次修改之后，你可能都不知道它现在是什么逻辑了。如果此时出现线上问题，你又改去找谁来看这个问题呢。

所以，如果开发去跨模块的进行代码开发，就会存在以上的问题，开发效率低，并且容易出线上问题。所以大家经常说：一个人走得快，一群人走得远。多人协同开发虽然增加了沟通与协调的成本，但当公司达到一定的体量，当项目达到一定的规模，靠一个或少数几个人是很难完成的，它一定需要很多人协同开发，共同完成。所以我们现在看大厂社招的开发岗位，很多都要求开发人员具有良好的沟通与协调能力。

对于问题2，比较理想的情况，是参与开发的每个同学都清楚的知道当前需求具体是做什么，整个系统每个模块都要该什么，我的模块该怎么改。但从我这几年的开发经历来看，要做到这一点比较难，尤其是在产品快速迭代的时期。

通常当有需求来的时候，会先叫组长去沟通需求，等这个需求确定了，组长就会看看当前组内谁有时间去做这个需求，就安排谁去做。但在业务发展初期，产品都在快速迭代，开发同学的工作基本都处于饱和的状态，一般做完一个需求后马上就做下一个需求。有的甚至是几个需求并行在开发，开发同学会趁着一个需求在联调或者测试的间隙去做另外的需求。假如这个时候组长又安排了一个需求让你去做，你会从头到尾的仔细研究这个需求吗？

对于大多数人来说是不会的。这个时期为了追求迭代速度，开发质量都是可以做一定牺牲的，更何况去研究需求的细节。当组长让他去对接需求的时候，他这个时候可能还在忙别的需求，都没时间去仔细看这次的需求是什么，只了解到它大概是什么。现在让他去参加具体的需求评审，他不想关心为什么要做这个需求，也不想关系其它模块怎么做什么，他只想知道他该做什么。然后定个开发与联调时间，他就可以去做了，做完后再去对接下一个需求。这个状态下，开发人员缺少了对项目的思考，其实已经沦为工具人角色了。但目前的高强度迭代，也没有时间给你去思考需求了。

这种情况其实也不仅仅是项目初期才会有，在项目稳定之后也会存在。我之前做过一个大需求，商城要增加一种商品的营销玩法，光是把后端导购、商品、营销、交易等几个组参与开发的同学拉到一起，就有十几个人。在产品沟通完需求，各模块都对接好了，准备进行开发的时候，我们的领导在当天晚上给我们来了个突击检查，要求我们每个人必须了解整个需求的交互流程，以及各个模块的具体实现，明天上班时开会检查成果。于是那天晚上我们十几个人就放下了手头的工作，开始研究这个需求的每个细节，每个模块的人互相介绍各自模块的实现逻辑，一直熬到了凌晨几点。第二天上午十点刚上班，就进到会议室，领导随机抽一个人来做需求的各个模块实现细节的讲解。

其实领导的想法是好的，让大家了解到其它模块的设计，能对项目需求有一个更充分的认识，在具体开发实现的时候也能考虑到更多的因素。但在大体量的业务部门，团队之间按照功能模块分组，系统也按照模块进行拆分，组内成员所做的开发内容其实已经固化了。因为开发同学只做了本组所对应模块的开发，本组的项目有问题你可以去找他，其它组的模块是怎么做的，他或许能了解个大概，但细节问题他没做过也不知道。这个时候再来需求，他也只想知道自己的模块该做什么，然后去把它做出来。

现在的产品功能这么多，各个系统也拆分出这么多的模块，多数开发一般也只关注自己模块以及上下游模块，要清楚的了解每个模块的细节还是很难的。当然了，也不能排查一些比较优秀的开发同学，他们会去了解其它模块的功能以及实现，对系统整体有个清晰的认识。这样的同学一般都是组长或者晋升组长的潜力股，但代价就是会花费更多的时间与精力。

回到问题2，对于参与某个模块开发的同学，让组长或者项目owner直接告诉他要改的内容，让他去改，这种方式效率会高很多。虽然这样会牺牲掉开发人员的主观能动性，但很多情况下都是采用的这种方式。不会单独安排时间让每个开发去熟悉整个项目的细节，直接安排具体工作，提升整体的效率。如果开发想要自我提升，想去了解其它模块，就得自己去花时间了。有的开发可能就去花时间研究了，有的就没有，于是开发人员之间的差距就慢慢拉开了。

那你说要不要让所有开发都去花时间做这样研究呢？我个人的看法是没必要的。因为这需要额外花费更多的时间，增加开发的成本。对于业务团队，开发人员的时间是宝贵的，对于大多数的开发，应该让他去做更多有价值的需求，产生更多的收益。谁想要做提升，那就得自己去花时间。这种情况下，也就不应该再要求每个开发同学去掌握其它模块，了解整体系统的原理了。