专栏名称: 宝玉xp
前微软Asp.Net最有价值专家 互联网科技博主 我是宝玉。
目录
相关文章推荐
爱可可-爱生活  ·  揭示了传统上下文学习在处理具有虚假相关性的视 ... ·  23 小时前  
宝玉xp  ·  补充一些 OpenAI ... ·  5 天前  
爱可可-爱生活  ·  【facad:一款现代、色彩丰富的命令行目录 ... ·  5 天前  
爱可可-爱生活  ·  晚安~ #晚安# -20241001222204 ·  1 周前  
爱可可-爱生活  ·  【Chital:macOS上的聊天应用,专为 ... ·  1 周前  
51好读  ›  专栏  ›  宝玉xp

//@universeroc:更关键的是,重构后的质量保障工作,-20241007082141

宝玉xp  · 微博  · AI  · 2024-10-07 08:21

正文

2024-10-07 08:21

//@universeroc:更关键的是,重构后的质量保障工作,缺少单元测试,只能集成测试或者增加单元测试,甚至是看似不重要实则有作用的代码,有各种隐藏彩蛋等着维护者中招。,防不胜防[允悲]//@宝玉xp:renew
烂代码是个有意思的话题,Martin Fowler 的著作《重构:改善既有代码的设计》里面就专门提到了代码异味(code smells),特别认同他说的:“代码异味是一种表象,它通常对应于系统中更深层次的问题。”

如果你的系统中到处都是烂代码,就要思考深层次的原因了,需求太奇葩?进度太紧?水平不行?没有设计?或者多个因素一起?

Martin给出的解决方案是重构,这绝对是很好的建议,只是执行起来有难度!
- 我想重构代码,但是我没有工期怎么办?
- 我好不容易重构完,会不会没多久又老样子了?
- 我自己没有能力重构!

归根结底不光是个技术问题,还涉及软件工程和项目管理。

我刚写代码的时候,都是烂代码,后来见过好代码,也开始学着提升代码质量,后来自己代码质量上来了发现别人写烂代码,等到带团队了就要去解决团队中烂代码。我现在团队的代码质量是很不错的,即使有几个刚毕业的新手程序员也没有让烂代码混进去,尤其是跟其他团队代码一对比,差距极其明显,所以我们产出也高,一个功能我们实现速度是别的团队的1.5倍到2倍甚至更快。

在解决团队烂代码问题上我做过很多尝试。

最先尝试的是代码审查,所有更新的代码都先在分支开发,合并到主干前要代码审查。顺便说一下:对于直接在主干开发,代码合并后再审查那种效果是会大打折扣的,事后改起来很困难,而且优先级会很低。

代码审查严格执行的话,效果是很明显的。但也遇到很多问题:
1. 代码命名、格式不符合规范,肉眼很难看的过来怎么办?
2. PR(Pull Request)太大,要审查的代码太多,看不过来怎么办?
3. 急着要上线的功能,代码质量一般甚至很烂怎么办?
4. 自动化测试覆盖不全怎么办?
5. 代码能实现功能,执行也没问题,但是结构混乱或者没有遵循最佳实践,批准还是不批准?
6. 原本的项目就是个“屎山”代码,新代码只能修修补补怎么办?

代码审查的一部分工作要工具化自动化

很多代码审查,靠肉眼是查不过来的,需要靠工具配合:
- 源代码管理工具不可少,可以清楚看到代码改动的代码审查工具不可少
- CI(持续集成)必不可少,每次提交代码要借助CI运行一些自动化测试
- lint必不可少,借助lint检查命名、格式等问题
- 自动化测试(单元测试和集成测试)不可少,代码的更新不能破坏现有功能,新增了功能,相应的也要新增自动化测试代码

PR不能太大,大PR要尽可能拆成小PR
越小的PR越好Review,反之太难,尽可能拆小

对于工期紧,急于合并的PR,质量差的不要轻易合并,需要后续改进的要有Ticket跟踪

生产环境的紧急补丁、deadline将近的新功能,这些PR很难说NO,只能先合并,但大部分时候就是合并了再无后续,最终一点点污染了整个代码库。所以后来我总结的经验就是:质量差的,我宁可推迟发布;质量没问题,但是测试不全的或者可以有优化空间的,都要求创建一个或多个Ticket去跟踪,并且这些Ticket的优先级和其他正式功能的Ticket优先级是一样的,必须在后续的Sprint里面去尽快完成。

对于稍微复杂一点的功能,写代码之前要先做系统设计

在代码审查时,我最初经常遇到的一个问题就是,一个功能安排下去,开发很快就实现,结果你一看代码,质量也不算太差,但是没有遵循好的实践,单个代码没问题,合在一起就很难阅读和维护。我要说PR不批准推翻重写吧,人家都花了几天甚至几周时间在上面了,说要重写肯定会很抵触,要是小修改也意义不啊。这种情况很难处理。

后来就找到一个好的解决方案,就是先做设计,因为设计阶段,只需要写简单的文档,画几张结构图,通过设计Review会议,一发现方向不对,马上就可以调整,很容易就对齐思路,等到最终实现代码,提交PR的时候,基本上和当初讨论的设计不会有太大出入,也不会再出现前面说到的要推翻重写的情况。

写代码之前先做设计绝对是磨刀不误砍柴工的好事,写设计文档倒逼着开发人员在实现前先想清楚,设计Review也是一个很好的机会让团队其他成员学习怎么做设计,怎么遵循最佳实践。唯一的问题就是要求团队里面有资深的开发人员,能在设计Review期间发现问题,指出问题,提出改进意见,否则就意义不大。

对于什么样的功能需要做系统设计,我们团队是用T恤尺码来对应任务大小的,比如S、M、L、XL等,我们的要求是M及以上的都要求做系统设计,S的可以不做。

强制代码审查后才能合并,以及强制先设计再写代码,很好的帮助了我的团队控制代码质量。

但这还不够,还经常遇到的问题就是:一些旧的屎山项目怎么办?技术债务怎么办?

老的项目我的策略是这样的:
1. 不值得维护的,隔离起来,保证它能运行就够了,只打补丁,不增加新功能,也不会再更新
2. 需要长期维护的,需要经常新增功能的,那么就要通过重构去改进完善。

老项目重构我的常用策略是:
1. 先补自动化测试代码,尤其是集成测试,这些自动化测试保证以后我做任何修改,都不会出大的问题
2. 逐个模块替换,而不是一下子推翻重写然后迁移。

比如我最近要用NextJS重构一个重要的前端项目,我不是先写一个新项目,然后整个替换掉,而是先写创建一个组件库,让这个组件库在新旧项目中可以共用,每次新的组件写好了,替换老项目中的相应模块,在老项目中充分测试后,再应用到新项目,这样等到老项目的模块都替换的差不多了,新项目也已经充分测试过了,迁移的风险就很小。

再说技术债务,借债不是坏事,但是债务是有利息的,最好的还债方式就是像房贷一样,每个月定期还一部分,而不是攒最后一起还,那太难了。

首先我会用任务管理系统跟踪所有的技术债务,每个技术债务相关的任务都会创建成ticket,对于复杂的,会进一步拆分成小的ticket。然后在每一个Sprint,我技术债务相关的任务在20%左右,这样的任务和产品需求任务优先级是一样的。这样基本上我的代码库的技术债务一直维持在一个很良性的水平。

我们部门另一个团队就是另一种情况,他们去年花了一个季度的时间去偿还技术债务,因为到了实在非还不可的地步,那个季度基本上无法响应来自产品的需求。我个人是不太推荐这种方式的,对开发团队和产品团队都是巨大的压力。

最近我们还探索出一个比较好的开发模式:就是两周的Sprint中,我们第一周只做产品的需求,然后第一周开发完成后部署到测试环境测试,第二周就是修复各种新功能的Bug,但是相应的bug修复工作量没多少,所以我们在第二周就可以有时间去做纯技术相关的任务,比如偿还技术债务、测试新的技术栈、开发公共组件。因为持续有产品功能交付,所以产品经理也接受了这种模式。

除了老项目的债务问题,新项目也有一个问题,就是架构设计出来了,代码实现的时候,程序员的水平是参差不齐的,有新手有老手,就是是老手,还有各自的个人喜好在里面,这也给代码质量带来很大挑战。

所以如果是我自己设计的架构或者我带的项目,我会在架构设计完成后,自己或者要求其他人基于架构设计,先实现一些基本的功能模块,把基本的场景都覆盖,在这些模块实现的时候,形成一个好的开发实践,比如前端项目,可以遵守Redux的状态管理实践。这个阶段也一样要有代码审查,团队里每个人都可以提出自己的意见反馈,根据反馈还可以对最佳实践做出调整。

有了最佳实践,其他人在实现时,就可以照葫芦画瓢,按照最佳实践就可以写出质量不错的代码,对于不符合最佳实践的代码,在代码审查阶段就应该果断拒绝。

简单总结一下:
代码审查很重要,而且一定要先审查再合并
系统设计也很重要,坚持先系统设计再对设计评审再实现代码
代码要有自动化测试覆盖
技术债务要定期还
老项目重构可以一点点替换
新项目或已有项目要有最佳实践供新手参考,并且大家一起遵守

#软件工程之美#