百度工程效率部技术教练经验分享
2019-12-26
来源：百度敏捷教练
背景
百度工程效率部工程组是专门为产品线输出工程技术能力的团队，最近某产品线的一个重要模块经常遇到上线回滚问题，希望工程小组的技术教练能支持他们完成此模块的重构工作，降低上线回滚率。
问题与目标
团队希望重构的模块是此系统最为复杂的模块，大约30+万行代码，重复代码14.5%，关键路径上的圈复杂度在60以上，最大圈复杂度147，100多全局变量的读写随意，单测覆盖率又只在5%左右。这样复杂的模块现状是至少每两周就会发生上线回滚，甚至曾经发生连续7次上线回滚的情况。经过产品线高工和 工程效率部技术教练们对回滚案例代码的分析，有些是代码质量问题，UT覆盖不足导致的, 根源还是软件设计问题。
所以产品线和工程效率部发起了对模块的重构计划，希望通过这次重构，提升代码质量，使得UT合理覆盖，降低代码质量和设计问题导致的上线回滚。
解决方案
领域知识学习
技术教练精通于软件设计，却不了解领域业务，因此在开始的时候，产品线同学讲解了领域业务和代码流程，技术教练开始2周业务学习与代码走读。这期间发现有效的途径有：
- 学习与搜索相关的视频，了解搜索架构
- 读与搜索相关的书籍
- 画代码的类图、时序图、流程图等等
- 技术教练结对走读代码或者每日沟通，且通过hi群和产品线同学保持问题沟通
取得产品线同学的信任
然而技术教练的介入在开始不会顺利，因为想要取得产品线的认可，并不是一件容易的事。我们在前期采取的方案是：
- 向产品线同学串讲代码走读的情况，且指出走读代码过程中发现的代码与设计问题
- 挑了2段复杂度高的代码，进行预先重构，将结果与重构的方法展示给产品线同学
- 将方法get_da从260行降到10行
- 将方法pack_parser从576行降到100行，圈复杂度从110降到了18
这样的方式在前期取得了产品线同学的认可与人力的投入，但真正的信任与合作，还是要在重构的过程中，通过展示技术与能力才能真正获得。
与产品线的合作方式
我们在模块内部分成了不同的处理阶段，如query变换阶段，召回阶段，调权，正排，摘要等等，于是重构的开展就按不同的阶段进行，5个人分成了 2组，一组重构query变换阶段，一组重构召回阶段。项目正式开始以后，所有参与重构的人员坐在一起。在开始的阶段，通过每日code review交流进展与技术方案，分享知识。
然而冲突是不可避免的，技术教练希望通过不断快速代码重构得到更清晰软件框架，而产品线同学则希望做更多的详细设计，经过产品线高级工程师的 review才能开展。在这个期间的磨合内，我们更借助产品线同
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
