关于代码交接的一点体会

这些日子有幸经历了一次大规模的代码交接，发现了不少问题，更总结了一大堆经验。回想起来，这真称得上是个技术活儿了，所以，捡一些觉得比较重要的体会记了下来。

再乱的事，总有头绪，理清楚了掌握好节奏，一步步来。先说一下交接的顺序：
1、整体结构分析。列出各模块的功能图，以及模块间的调用关系图。
2、列出需求，排出产品期望的优先级。然后按模块做技术分析，优先级高，难度小，牵涉代码范围小的优先级最高，其它依次后排。
3、无论从哪个角度来讲，交接的过程都要和新版本开发并行。因此，需要列出每个版本完成的交接任务和需求任务。切记，交接过程中开发新需求一定要按模块来，不要在前期去搞那些影响范围过大的需求。
4、新版本开发过程中，一次调整一部分模块，借机整理结构，熟悉细节。在这个过程中，发现有问题的地方，该换人的换人，该重写代码的重写代码。经历几个版本的迭代，相信会稳定下来。

有几个需要严重注意的地方：
1、“Read the fucking code”是全世界程序员头疼的事，推倒重写是很爽快，但这是工作，工作的目标是：用最小的成本换取最大的收益。
2、不要想着一步到位，所有代码理顺了再接需求。你不是一个人在工作，要和老大，和产品沟通，让他们看到你在忙什么，到什么阶段了。交接过程中最好的沟通就是按模块交接，交接到哪个模块，把需求铺到哪个模块。
3、交接代码必定要按模块分给不同的人去做，但读别人的代码需要经验和技巧，为了避免因为人员水平参差不齐或者理解不一样而影响交接质量，一定要定出可以量化的交接目标，让每个负责模块交接的人都有标准去参照执行。

另外，有几点很深体会，以前是潜意识地去做，但通过这次交接，加深了理解：
1、注释的重要性。
精巧的结构、核心业务逻辑、关键算法、工具类。这几个东西一定要在代码中加上注释。
2、模块分包。
一个好的分包方式可以让你在一个包中找到你想要的所有东西。
3、结构与人。
好的结构一定是能够做到靠增加人数可以解决问题，同时每个人的重复工作又不多。