这些日子有幸经历了一次大规模的代码交接,发现了不少问题,更总结了一大堆经验。回想起来,这真称得上是个技术活儿了,所以,捡一些觉得比较重要的体会记了下来。
再乱的事,总有头绪,理清楚了掌握好节奏,一步步来。先说一下交接的顺序:
1、整体结构分析。列出各模块的功能图,以及模块间的调用关系图。
2、列出需求,排出产品期望的优先级。然后按模块做技术分析,优先级高,难度小,牵涉代码范围小的优先级最高,其它依次后排。
3、无论从哪个角度来讲,交接的过程都要和新版本开发并行。因此,需要列出每个版本完成的交接任务和需求任务。切记,交接过程中开发新需求一定要按模块来,不要在前期去搞那些影响范围过大的需求。
4、新版本开发过程中,一次调整一部分模块,借机整理结构,熟悉细节。在这个过程中,发现有问题的地方,该换人的换人,该重写代码的重写代码。经历几个版本的迭代,相信会稳定下来。
有几个需要严重注意的地方:
1、“Read the fucking code”是全世界程序员头疼的事,推倒重写是很爽快,但这是工作,工作的目标是:用最小的成本换取最大的收益。
2、不要想着一步到位,所有代码理顺了再接需求。你不是一个人在工作,要和老大,和产品沟通,让他们看到你在忙什么,到什么阶段了。交接过程中最好的沟通就是按模块交接,交接到哪个模块,把需求铺到哪个模块。
3、交接代码必定要按模块分给不同的人去做,但读别人的代码需要经验和技巧,为了避免因为人员水平参差不齐或者理解不一样而影响交接质量,一定要定出可以量化的交接目标,让每个负责模块交接的人都有标准去参照执行。
另外,有几点很深体会,以前是潜意识地去做,但通过这次交接,加深了理解:
1、注释的重要性。
精巧的结构、核心业务逻辑、关键算法、工具类。这几个东西一定要在代码中加上注释。
2、模块分包。
一个好的分包方式可以让你在一个包中找到你想要的所有东西。
3、结构与人。
好的结构一定是能够做到靠增加人数可以解决问题,同时每个人的重复工作又不多。
本站仅提供存储服务,所有内容均由用户发布,如发现有害或侵权内容,请
点击举报。