等重构完这系统,我就提离职!

简介: Part.1 为什么程序员一言不合就重构代码? 当你看到前任写成一团毛球的代码块;新增几行代码需先捋半天逻辑的超级大函数;好不容易在迷宫里找到方向,小心翼翼地添加上新代码,却将别的调用系统给弄垮时;还有运行缓慢的老系统…… 此时程序员只有两个选择:要么忍,要么重构。

Part.1

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


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

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

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

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

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

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

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

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

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

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

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

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

开发:我……

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

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

Part.2

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

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

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

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

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

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

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

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

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

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

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

Part.3

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

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

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

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

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

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

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

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

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

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

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

3. 测试驱动开发

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

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

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


原文发布时间为:2018-09-25

本文作者:五五

本文来自云栖社区合作伙伴“Java技术栈”,了解相关信息可以关注“Java技术栈

相关文章
思考:如何写出让同事难以维护的代码?(2)
思考:如何写出让同事难以维护的代码?
61 0
思考:如何写出让同事难以维护的代码?(2)
|
程序员
思考:如何写出让同事难以维护的代码?(1)
思考:如何写出让同事难以维护的代码?(1)
75 0
思考:如何写出让同事难以维护的代码?(1)
|
API 计算机视觉
思考:如何写出让同事难以维护的代码?(4)
思考:如何写出让同事难以维护的代码?
78 0
思考:如何写出让同事难以维护的代码?(4)
思考:如何写出让同事难以维护的代码?(3)
思考:如何写出让同事难以维护的代码?
54 0
思考:如何写出让同事难以维护的代码?(3)
|
程序员 API 计算机视觉
思考:如何写出让同事难以维护的代码?doge
本文从【程序命名&注释】【数据类型&类&对象】【控制执行流程】和【程序/结构设计】四个方面梳理了一些真实案例,相信通过这些案例你能迅速get技能:如何写出让同事难以维护的代码doge。
|
消息中间件 运维 JavaScript
在公司混的差,不一定是能力不行,可能和组织架构有关!
在公司混的差,不一定是能力不行,可能和组织架构有关!
|
开发框架 Java 测试技术
【测试基础】五、这样提bug单,开发小哥还会怼你么?
【测试基础】五、这样提bug单,开发小哥还会怼你么?
【测试基础】五、这样提bug单,开发小哥还会怼你么?
|
前端开发 JavaScript 测试技术
为了降低维护成本(早点下班),我在组件开发中所做的那些优化(偷懒)
组件开发中为了稳定性、健壮性,经常需要为组件编写测试用例,然后还要为了开发者方便使用编写文档,都是非常耗时间的差事。作为一个独立维护组件库的程序员,为了能够降低组件维护的成本(早点下班),我总结了一下自己过去几年为了让组件开发更加高效所做的那些事情(偷的那些懒)。
|
缓存 负载均衡 算法
一对一源码开发,减少用户焦虑的三大优化要点
一对一源码开发,减少用户焦虑的三大优化要点
人员表设计思想 —— 也许会有点帮助
当我们出生的时候,我们有什么?性别、出生日期、姓名。除了这些还有什么呢?体重、属性、星座、血型、父母、哥哥、姐姐、籍贯、身份证号、其他。这些都是一出生就拥有的。 然后我们慢慢的成长,进入学校学习,进入社会打拼,打工、创业等等。
861 0