36

等重构完这系统,我就辞职

 5 years ago
source link: https://blog.csdn.net/csdnsevenn/article/details/81212458?amp%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

点击上方“ 程序人生 ”,选择“置顶公众号”

第一时间关注程序猿(媛)身边的故事

mq2eUj2.gif

作者

五五

白天搬砖,晚上砌梦想。相信每个人有故事,程序员更是有许多事故,书写最接地气的程序员故事。

如需转载,请联系原作者授权。

Part.1

为什么程序员一言不合就重构代码?

iMVFVfy.jpg!web

当你看到前任写成一团毛球的代码块;新增几行代码需先捋半天逻辑的超级大函数;好不容易在迷宫里找到方向,小心翼翼地添加上新代码,却将别的调用系统给弄垮时;还有运行缓慢的老系统……

此时程序员只有两个选择: 要么忍,要么重构。

忍是有极限的,重构的“三次法则”表示:程序员第一次看到乱代码可以绕过去,先将手上的代码堆好;第二次再碰上这块,心里虽反感但再一次勉强绕过;第三次肯定忍不住动手。

以下的场景是不是很熟悉:

测试: 这么小的功能,你为什么改动300多个文件?

开发: 嘿嘿嘿,我顺便将老代码挪了地方。

测试 :你知道这给我增加多少测试工作量吗?那些我都得回归一遍。

开发: 不用测试,没有风险的,我就整理下代码。

测试: 你上次也这么说,结果偷偷改了某接口,影响到下游系统。还有那次啊你……

产品: 你又在弄重构?我这还有一大堆需求没人开发。

开发: 我这的重构系统也非常重要的。

产品: 哪里重要了?你浪费这么多人力重构,用户也看不出来系统有什么变化,搞不好还弄坏老功能。求求你别重构了。

开发: 我……

虽然重构不被其他角色认可,但你的程序员同事会理解和感谢你的,重构是优化代码设计,使代码可读性更强。

只是重构是个大坑,不小心就掉坑里。

Part.2

“等重构完这个系统,我就提离职。”龙哥说。

mq2eUj2.gif

由于核心系统初期设计不当,权责界限模糊,只要沾点边的代码都往上堆,造成系统过于庞大,逻辑混乱,一出现问题,造成核心业务瘫痪。

过老过大过中心的系统像个不定时炸弹,吃过几次亏后,业务组决定拔掉这隐患:将系统重构,按照业务处理逻辑拆分成各功能单一的子系统,降低耦合度。

大伙把这事当作季度最重要的计划来开展:热火朝天的开会划分系统,梳理代码逻辑,安排测试,声明注意事项。

各人领了任务后,开始埋头苦干起来。

但是重构系统像从一个大迷宫捋线路,捋的过程耗费巨大,而且极易遗漏。产品后来提的新需求直接在重构后的系统里新增。开发团队进入恶性循环:新增功能有的人在老系统分支改,有人在新的改,导致提交的代码分支混乱,搭建过程缓慢,计划的任务delay,最后测试人员发现很多遗漏点,又返工重构。

大家不断埋头地捋代码,重构,测试,想百分百完美地完成任务,而忽略整体项目进度的把控。

上线时间从9月份推迟到12月份,再到年后,最终来年6月份系统才上线完成,耗时一年多。

每个人被重构折磨得疲惫不已,还短时间看不出来效果,可已经投入人力物力,大家只好硬着头皮往下走。

后来大家已经想不起当初为什么要重构,到底要重构到什么样子,只想着这重构何时到头,什么时候才能解放。

从重构半年时开始有人离职,到上线时仅剩一个原项目组的产品,他说这项目终于结束,我也该走了。

Part.3

上面的重构没有合理的项目规划,还犯了重构的大忌:边重构代码边新增功能,这样相当于将原系统推翻重做,风险极大。

那么该如何合理的安排重构呢?

mmuaIzU.gif

1.遵循“两顶帽子”重构原则

在重构时,两个不同的操作分开进行:重构代码和新增功能。

先在不改变原系统功能的基础上修改现有代码的设计,这样采用原有的测试方法可以轻松地验证这些修改的正确性。

再在已重构好的基础上增加新功能,使得新功能与老功能合理解耦。

上述例子里,业务组边重构边在上面新开发功能,给测试人员的压力巨大,原有的测试方法全不适用,增加回归测试工作量。

2.使用“小步快跑”的重构策略

重构避免使用“大布局”规划项目进程,如果从整理需求、设计接口、开发联调、测试上线,经历几个月的时间,如果其间有问题,整个团队又得人仰马翻地去调整方向,试错成本过高。

“小布快跑”是让我们重构时只关注一个问题点,只解决这一个问题。小改动,小局部优化,耗时短,见效快。

这便需要我们将重构当作一个习惯,融入在每一次代码修改中。

3.测试驱动开发

上文例子里将代码的质量保证全丢给测试人员,光是对整个系统接口的性能测试就耗费大半个月的时间,等测试人员将问题列表整理后又得重新改代码,不单浪费时间,还可能引入大风险。

正确的重构姿势是将测试融入在每一次重构中,小步快跑,修改一块代码便自测这块,等调通后再继续往下走。重构有风险,开发测试两手捉。

《重构》一书里说道:任何一个傻瓜都能写出计算机可以理解的代码,唯有写出人类容易理解的代码,才是优秀的程序员。

- The End -

「若你有原创文章想与大家分享,欢迎投稿。」

加编辑微信ID,备注#投稿#:

程序 丨 druidlost  

小七 丨 duoshangshuang

上期精彩内容

7bY7FvU.png!web

neIvUbQ.gif


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK