多人协作大型项目重构时需注意的问题探讨

去年8月起，笔者参与了某大型影音视听类项目的重构工作。抛开其中的技术问题不谈，对于项目管理者如何保证成员按时保质保量达成任务目标，同时提高团队研发效率，节省人力资源，以及小组整体协作问题都是值得深入探讨的话题。这里笔者将自己的几点心得记录下来，希望与大家分享，也为今后的工作提供借鉴。
1.公共逻辑代码管理。
对于重构中涉及的大量复用的公共逻辑，必须由专人负责进行管理，代码落实到人，其他人需要改动时，要与负责的人沟通，共同修改。
相信各个大厂的项目一定已经这样做了，但笔者参与的项目没有这样处理，导致出现的问题包括：
①代码产生大量冲突，解决冲突占用提交者较多工作时间；
②不同的人写入不同逻辑后，由于代码思路不一致，产生了bug。这种bug一般较难解决，需要涉及到的人共同参与去处理，也造成了时间的浪费，同时增加了项目风险。
③在重构中，为了保证上线时间，有时会使用临时方案解决问题。当临时方案涉及的公共代码掺杂入很多人的逻辑后，就为日后的重新梳理和方案替换挖了新坑。
2.功能模块互换开发的方式。

这种方式本是一种促进成员快速进步的好办法，可以使项目组成员不局限于某一功能模块的实现，每个人都能对整个项目的业务逻辑有所了解，一旦出现人员变动等情况，其余成员可以快速接手工作。但此种方式的关键之处，有以下两点：
①衔接，前面负责的人要将对应的业务逻辑完整的交代给后续开发的人，最好能提供相关的设计文档。
②统筹安排工作计划的人，要根据每个人变动情况以及各模块、功能之间的先后顺序，合理调整研发顺序，避免出现相互等待的情况，也要为适应新任务预留时间，有备无患。
3.分组开发模式。
由于项目组内人员数量众多，故采用了分AB组开发的模式，A组任务在研发完成提交测试的同时，B组确认需求开始研发，A组版本上线后，再次确认新版需求开始研发，这时B组研发任务完成提交测试。这样的方式，满足了版本固定周期稳定上线的要求，也充分地利用了人力资源充足的优势。分组开发模式在运行过程中，也发现了一些问题：
①与互换功能模块开发相同，仍然是衔接与计划安排是否合理的问题，这需要管理者付出更多精力去确认实际情况，在组员之前清晰地了解业务模块与新版本需求，才能确保计划的高效性。
②分组后，需要增加组间沟通会议，让所有成员对项目当前进度都有所了解，方便在实际开发时贴近实际情况去设计研发方案。
③项目组人员众多的情况下，任务很有可能分配不均，有人负责的多，有人负责的少，要在每日会议中确定各位成员的进展情况，及时给与调整，而不是在一个版本即将提测时才发现问题，加班处理。
4.技术引入方面。
项目中引入一项新的技术时，要到研发过程中去不断确认技术的优劣点，从而确认技术的应用范围。切勿因为对技术的新鲜感就到处使用，反而造成开发成本上升。
目前暂时总结了以上四条，接下来的过程中，我会继续将心得更新在这里，欢迎持续关注。