等重构完这系统,我就辞职
Part.1
为什么程序员一言不合就重构代码?
当你看到前任写成一团毛球的代码块;新增几行代码需先捋半天逻辑的超级大函数;好不容易在迷宫里找到方向,小心翼翼地添加上新代码,却将别的调用系统给弄垮时;还有运行缓慢的老系统……
此时程序员只有两个选择:要么忍,要么重构。
忍是有极限的,重构的“三次法则”表示:程序员第一次看到乱代码可以绕过去,先将手上的代码堆好;第二次再碰上这块,心里虽反感但再一次勉强绕过;第三次肯定忍不住动手。
以下的场景是不是很熟悉:
测试:这么小的功能,你为什么改动300多个文件?
开发:嘿嘿嘿,我顺便将老代码挪了地方。
测试:你知道这给我增加多少测试工作量吗?那些我都得回归一遍。
开发:不用测试,没有风险的,我就整理下代码。
测试:你上次也这么说,结果偷偷改了某接口,影响到下游系统。还有那次啊你……
产品:你又在弄重构?我这还有一大堆需求没人开发。
开发:我这的重构系统也非常重要的。
产品:哪里重要了?你浪费这么多人力重构,用户也看不出来系统有什么变化,搞不好还弄坏老功能。求求你别重构了。
开发:我……
虽然重构不被其他角色认可,但你的程序员同事会理解和感谢你的,重构是优化代码设计,使代码可读性更强。
只是重构是个大坑,不小心就掉坑里。
Part.2
“等重构完这个系统,我就提离职。”龙哥说。
由于核心系统初期设计不当,权责界限模糊,只要沾点边的代码都往上堆,造成系统过于庞大,逻辑混乱,一出现问题,造成核心业务瘫痪。
过老过大过中心的系统像个不定时炸弹,吃过几次亏后,业务组决定拔掉这隐患:将系统重构,按照业务处理逻辑拆分成各功能单一的子系统,降低耦合度。
大伙把这事当作季度最重要的计划来开展:热火朝天的开会划分系统,梳理代码逻辑,安排测试,声明注意事项。
各人领了任务后,开始埋头苦干起来。
但是重构系统像从一个大迷宫捋线路,捋的过程耗费巨大,而且极易遗漏。产品后来提的新需求直接在重构后的系统里新增。开发团队进入恶性循环:新增功能有的人在老系统分支改,有人在新的改,导致提交的代码分支混乱,搭建过程缓慢,计划的任务delay,最后测试人员发现很多遗漏点,又返工重构。
大家不断埋头地捋代码,重构,测试,想百分百完美地完成任务,而忽略整体项目进度的把控。
上线时间从9月份推迟到12月份,再到年后,最终来年6月份系统才上线完成,耗时一年多。
每个人被重构折磨得疲惫不已,还短时间看不出来效果,可已经投入人力物力,大家只好硬着头皮往下走。后来大家已经想不起当初为什么要重构,到底要重构到什么样子,只想着这重构何时到头,什么时候才能解放。从重构半年时开始有人离职,到上线时仅剩一个原项目组的产品,他说这项目终于结束,我也该走了。
Part.3
上面的重构没有合理的项目规划,还犯了重构的大忌:边重构代码边新增功能,这样相当于将原系统推翻重做,风险极大。
那么该如何合理的安排重构呢?
1.遵循“两顶帽子”重构原则
在重构时,两个不同的操作分开进行:重构代码和新增功能。
先在不改变原系统功能的基础上修改现有代码的设计,这样采用原有的测试方法可以轻松地验证这些修改的正确性。
再在已重构好的基础上增加新功能,使得新功能与老功能合理解耦。
上述例子里,业务组边重构边在上面新开发功能,给测试人员的压力巨大,原有的测试方法全不适用,增加回归测试工作量。
2.使用“小步快跑”的重构策略
重构避免使用“大布局”规划项目进程,如果从整理需求、设计接口、开发联调、测试上线,经历几个月的时间,如果其间有问题,整个团队又得人仰马翻地去调整方向,试错成本过高。“小布快跑”是让我们重构时只关注一个问题点,只解决这一个问题。小改动,小局部优化,耗时短,见效快。
这便需要我们将重构当作一个习惯,融入在每一次代码修改中。
3.测试驱动开发
上文例子里将代码的质量保证全丢给测试人员,光是对整个系统接口的性能测试就耗费大半个月的时间,等测试人员将问题列表整理后又得重新改代码,不单浪费时间,还可能引入大风险。
正确的重构姿势是将测试融入在每一次重构中,小步快跑,修改一块代码便自测这块,等调通后再继续往下走。重构有风险,开发测试两手捉。
《重构》一书里说道:任何一个傻瓜都能写出计算机可以理解的代码,唯有写出人类容易理解的代码,才是优秀的程序员。
欢迎工作一到五年的Java工程师朋友们加入Java架构开发:468947140
点击链接加入群聊【Java-BATJ企业级资深架构】:https://jq.qq.com/?_wv=1027&k=5zMN6JB
本群提供免费的学习指导 架构资料 以及免费的解答
不懂得问题都可以在本群提出来 之后还会有职业生涯规划以及面试指导
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
【FAQ】新版maven.aliyun.com答疑
我们对maven.aliyun.com进行了代码和架构上的全新改造。新的maven.aliyun.com采用阿里云的OSS作为后端存储,下载速度快,支持高并发,而且全站进行了HTTPS加密,更安全。 以下列出了使用上遇到的一些常见问题。用户如有其它问题也可以留言。 Q: 为什么访问maven.aliyun.com/nexus/content/groups/public会返回404错误页面?A:新版maven.aliyun.com还不支持通过这种方式浏览仓库,但是并不影响正常的构建下载。如果想浏览仓库内容请访问maven.aliyun.com/mvn/view页面,点击对应的仓库进行树状结构浏览。 Q:为什么首页显示的仓库地址变了,比如public仓的地址为https://maven.aliyun.com/repository/public?A:首页上显示的仓库地址为推荐使用的仓库地址。为了保证兼容性也也支持以前的仓库地址,用户仍然可以通过http://maven.aliyun.com/nexus/content/groups/public来使用服务。 Q:首页无法浏览public库的内...
- 下一篇
MySQL并行复制的深入浅出
一、并行复制的背景 首先,为什么会有并行复制这个概念呢? 1. DBA都应该知道,MySQL的复制是基于binlog的。 2. MySQL复制包括两部分,IO线程 和 SQL线程。 3. IO线程主要是用于拉取接收Master传递过来的binlog,并将其写入到relay log 4. SQL线程主要负责解析relay log,并应用到slave中 5. 不管怎么说,IO和SQL线程都是单线程的,然后master却是多线程的,所以难免会有延迟,为了解决这个问题,多线程应运而生了。 6. IO多线程? 6.1 IO没必要多线程,因为IO线程并不是瓶颈啊 7. SQL多线程? 7.1 没错,目前最新的5.6,5.7,8.0 都是在SQL线程上实现了多线程,来提升slave的并发度 接下来,我们就来一窥MySQL在并行复制上的努力和成果吧 二、重点 是否能够并行,关键在于多事务之间是否有锁冲突,这是关键。 下面的并行复制原理就是在看如何让避免锁冲突 三、MySQL5.6 基于schema的并行复制 slave-parallel-type=DATABASE(不同库的事务,没有锁冲突) 之前说过...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
-
Docker使用Oracle官方镜像安装(12C,18C,19C)
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8编译安装MySQL8.0.19
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
推荐阅读
最新文章
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- 设置Eclipse缩进为4个空格,增强代码规范
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS7安装Docker,走上虚拟化容器引擎之路
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS8编译安装MySQL8.0.19
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- Docker安装Oracle12C,快速搭建Oracle学习环境