阅读更多

4顶
0踩

研发管理


最近我遇到了一位以前公司的同事。他提到了数年前我在那个公司曾经开发过的项目。他说这个项目现在已经变成了“职业杀手”。基本上,任何接触过这个“职业杀手”项目的人最终都会离开这个公司。如果公司想让名下的程序员人数>0,唯一的办法就是花数月时间完全重构这个系统。

对于这事我有两点要说。首先,在我离开这个公司前,这个系统的单元测试覆盖率已经达到了85%,所以,不要责备我。第二,这么大规模的重构?肯定会出问题。

每一个系统里都至少有一个成为人民公敌、让所有人害怕的组件。它承载了太多的任务,它拥有太多状态,太多的其它组件调用它。当时间到了偿还技术债务的时候,人人都会把目光投向这个组件。然而,如果你对这个组件只有一个不全面的理解,你放下所有工作来完全重构它,那你成功的几率会很小。这个组件,就它表现出来的令人恐怖的程度和复杂相比,它的实际情况会比你想象更复杂,更恐怖。

你认为这个组件是如何发展成这样一个不幸的状态的?是因为公司雇用了一个笨蛋,让他肆无忌惮的往系统里增加复杂度?或是因为这个组件最初设计的太抽象,由于多年来需求的变更,它的责任范围不断的扩大?(出于个人的自尊,我宁愿相信这个“职业杀手”属于后者)。十有八九,这个组件变成如今这个恐怖的状态,都有由“聪明人”的一些“好意”造成的。如果你决定做一次大的重构,你实际是欠下了另一笔技术债务留给后人。

为了能真正的彻底偿还这笔债务,你需要去分解这个系统的复杂度。你需要花时间寻找所有调用这个组件的客户端。你需要花时间跟你的同事交流,了解这个组件的历史和它是如何被使用的。你需要简化这个组件的周边环境,看看它是如何运作的。每周,你都需要花更多的时间来更清楚的了解这个组件的业务。只要有足够长的时间跨度,你最终能理清所有复杂的问题。

从实际方法上说,这个问题应该怎么办?与其现在花3个整月的时间做一次完全的重构,不如先用一个季度的时间做清理工作。最后还是要重写,但有了3个月的计划准备,你有了时间去分析和设计,你有了时间来理清业务。

英文原文:It's Not Refactoring, It's Untangling
  • 大小: 55 KB
来自: 外刊IT评论
4
0
评论 共 11 条 请登录后发表评论
11 楼 kidneyball 2013-04-16 19:45
dacoolbaby 写道
kidneyball 写道
作者完全在推卸责任嘛……

首先单元测试覆盖率85%不等于代码好读好懂,更别说好的代码还应该引导后续修改保持原本良好的风格了。
……


单元测试覆盖率不应该作为系统稳定性和可维护性的指标。
但是单元测试确实能十分有效地管理代码质量。

问题是,复杂的业务逻辑再加上层次不齐的编码,会让你原有的代码破烂不堪。
重构是个方法,但是摸清楚逻辑,更加重要。

我敢说,85%的公司注释很少,单元测试更少


我觉得作者是把重构和重写搞混了。单元测试覆盖率的最大作用就是方便重构,他辛辛苦苦写了85%的覆盖率,又不让人重构,不知道在想什么。“重构”的意思是在不添加任何新功能的前提下,改变代码结构让它更容易维护。所谓“不添加新功能”,不但是整个系统都不添加新功能,而且是绝大部分被单元测试覆盖的对外接口都不添加新功能。重构的过程本身就是理清业务逻辑的过程。如果这时候绕过代码本身去重新整理业务逻辑,把整个系统设计都改变了,那是重写,不是重构。
10 楼 freezingsky 2013-04-16 17:32
有时候,我只能说,代码混乱不是因为开发者的思维混乱,而是需求提出者的思维混乱,三天两头的改,能不乱?
9 楼 dacoolbaby 2013-04-16 16:09
kidneyball 写道
作者完全在推卸责任嘛……

首先单元测试覆盖率85%不等于代码好读好懂,更别说好的代码还应该引导后续修改保持原本良好的风格了。
……


单元测试覆盖率不应该作为系统稳定性和可维护性的指标。
但是单元测试确实能十分有效地管理代码质量。

问题是,复杂的业务逻辑再加上层次不齐的编码,会让你原有的代码破烂不堪。
重构是个方法,但是摸清楚逻辑,更加重要。

我敢说,85%的公司注释很少,单元测试更少
8 楼 yangxinxyx 2013-04-15 22:31
其实博主提到的关于重构的思路是正确的,先会更多的时间理清业务,找到是哪些业务逻辑增加了复杂度,而这个过程在软件工程学上来说是相对便宜的,一旦开始Coding后,成本就增加了。一个项目之所以要重构,或多或少和最初的设计有关,至少和后面累加的代码有着莫大关系,如果在重构的时候都不会太多的时间去分析与重新设计,那么重构出来的项目未必会有多大的改善。

一半来说,做一项重构,可能80%的时间在分析与设计,而Coding最多只占20%的时间
7 楼 longhaisheng 2013-04-14 11:54
为什么会的垃圾系统,归根结底还是最初架构设计的原因

为什么会有垃圾代码,原因很多,如时间紧,赶及程序员本身素质的原因

写代码时怎么不想着把代码写好点,觉着以后可以重构,企业老板大多不太懂技术,会

给你开发人员时间去重构吗,大多不会,有多少个企业认为代码质量重要,他们要的是

产品,要的是生产力,可是代码慢慢累加,人员不断更换,烂系统就慢慢形成了,时间

久了,这个系统就难以修改了,这时,系统想重构又很困难,遇到英明的领导,会重写

,但很多公司没有那么多时间让你重写哈,所以N多公司挂了,有部分原因是因为系统不

不行了,杯具




6 楼 kidneyball 2013-04-14 07:47
作者完全在推卸责任嘛……

首先单元测试覆盖率85%不等于代码好读好懂,更别说好的代码还应该引导后续修改保持原本良好的风格了。

其次作者是那个项目的负责人,他现在离职了。如果文档不完善(这点作者没有提,不过一般文档不会涉及到所有业务细节),他的代码就是理解业务逻辑的唯一来源。你总不能叫那家公司现在去问客户三年前都做了哪些特殊业务处理吧,客户只会跟你说,不知道,反正这东西现在能用,你的新功能不能影响旧功能。

这堆代码把这个公司弄得那么痛苦,如果不依赖这堆代码就能理清业务逻辑,早就直接重写了,还重构什么鬼。好了,现在我不重构就看不懂这堆代码,就理不清业务逻辑。你却叫我重构前要先理清业务逻辑……
5 楼 bigtian 2013-04-13 22:55
问题是很多公司不会给一个新人3个月的时间来做这件事情,他们一般会给新人2-3周时间熟悉系统,然后就开始分任务做了(改BUG或是加需求),如果不幸碰到这种杀手级的系统,那新人极有可能会崩溃,忍耐力强的能坚持改一段时间,不过最终的结果都是重构或者离职,运气好的也许能脱离这个项目。
4 楼 minn84 2013-04-13 22:16
3 楼 clxy 2013-04-12 19:33
引用
数年前我在那个公司曾经开发过的项目

引用
这个项目现在已经变成了“职业杀手”


乐扑的了,感情这作者是个“杀手”之父,哈哈。
2 楼 spiderguy 2013-04-12 17:51
的基础上...打漏, 别会错意。
1 楼 spiderguy 2013-04-12 17:50
有道理,大型重构于理清业务逻辑之上。

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

  • 你需要的不是重构,而是理清业务逻辑(转)

    最近我遇到了一位以前...0,唯一的办法就是花数月时间完全重构这个系统。 对于这事我有两点要说。首先,在我离开这个公司前,这个系统的单元测试覆盖率已经达到了85%,所以,不要责备我。第二,这么大规模的重构?...

  • 一招教你看懂Netty!java业务逻辑设计模式

    拆分方法如下: 基于业务逻辑拆分 基于可扩展拆分 基于可靠性拆分 基于性能拆分 其中,对于无法修改的遗留系统,采用绞杀者模式:在遗留系统外面增加新的功能做成微服务方式,而不是直接修改原有系统,逐步的实现对...

  • 经验总结 | 重构让你的代码更优美和简洁

    前言 最近有幸对订单Push项目进行了重构,向大家分享一下代码重构相关的...这不是你的问题,而是你手中的代码需要进行重构了。 代码质量的唯一有效度量是:WTFs(what the fuck)/minute 何为重构 每个人对重

  • 一文教会你如何写复杂业务代码

    结合实际的业务场景,我沉淀了一套“如何写复杂业务代码”的方法论,在此分享给大家。 我相信,同样的方法论可以复制到大部分复杂业务场景。 一个复杂业务的处理过程 业务背景 简单的介绍下业务背景,零售通是给...

  • 【工程优化】代码重构

    认知有限,望大家多多包涵,有...本文先对代码重构做个简单的介绍,具体内容后续再更,其他模块可以参考去我其他文章提示:以下是本篇文章正文内容对系统和软件内部结构的一种调整,提高其可理解性,降低其修改成本。

  • 重构:开篇

    首先,重构的前提是在不改变当前代码的业务逻辑下对代码内部结构进行调整;其次,重构的结果并不一定在性能上有很大的提高,相反,有些重构可能还会比重构前的代码性能更低一点。 但总体来说,重构的目的是在不改变...

  • 复杂业务系统的架构设计思路

    比如电商的商品管理、订单交易等系统的开发和重构,业务相对复杂,开发人天在几个月以上,直接开发可能会老虎啃天,无从下手。

  • 基于openocd开源工具实现的C#桌面应用工具

    基于openocd开源工具实现的C#桌面应用工具

  • 精品-2025人工智能神经网络基本原理解析.pdf

    精品-2025人工智能神经网络基本原理解析.pdf

  • 施耐德ATV312变频器通过MCGS RTU通讯实现双机监控与控制的触摸屏集成解决方案,无PLC的施耐德ATV312变频器通讯示例:触摸屏控制监控两台变频器,功能多且省成本,改进型可调整步长 P&O

    施耐德ATV312变频器通过MCGS RTU通讯实现双机监控与控制的触摸屏集成解决方案,无PLC的施耐德ATV312变频器通讯示例:触摸屏控制监控两台变频器,功能多且省成本,改进型可调整步长 P&O MPPT(二区MPPT复现),光储系统MPPT 直流负载供电的单级离网光伏系统中,降压转器将太阳能光伏阵列和直流负载连接起来,同时确保最大功率点跟踪(MPPT) 和电池充电控制的良好运行。 在MPPT方面,提出了一种改进的自适应步长扰动观测(P&O)方法,以达到不同天气条件下太阳能光伏阵列的实际最大功率点(MPP),同时减少稳态振荡和功率损耗。 此外,电池充电控制侧使用三级充电控制器 (TSCC) 为铅酸电池站充电。 ,改进型P&O; 复现二区MPPT; 光储系统MPPT; 最大功率点跟踪(MPPT); 步长扰动观测; 降压转换器; 太阳能光伏阵列; 电池充电控制; 三级充电控制器(TSCC); 铅酸电池站。,改进型P&O MPPT技术,光储系统高效能量管理

  • redis学习脑图笔记

    redis学习脑图笔记

  • 大创项目_30.zip

    大学生创业项目源码

  • Spring Boot企业员工管理系统(包含万字论文+MYSQL)

    Spring Boot企业员工管理系统(包含万字论文+MYSQL)

  • 【css酷炫效果】纯CSS实现进度条加载动画

    对应博客地址:https://blog.csdn.net/u011561335/article/details/146312389

  • ClientB中的资源原本是在App.xaml的Application.Resources添加的,才能被各个页面调用。改为类库后

    相关文章:https://blog.csdn.net/liu_23yanfeng/article/details/146319189

  • 从春晚看科技技术-陈雄 - 公开版本.pptx

    从春晚看科技技术-陈雄 - 公开版本.pptx

  • 基于springboot框架的制造装备物联及生产管理ERP系统的设计与实现(Java项目编程实战+完整源码+毕设文档+sql文件+学习练手好项目).zip

    在计算机上安装制造装备物联及生产管理ERP系统软件来发挥其高效地信息处理的作用,可以规范信息管理流程,让管理工作可以系统化和程序化,同时,制造装备物联及生产管理ERP系统的有效运用可以帮助管理人员准确快速地处理信息。 制造装备物联及生产管理ERP系统在对开发工具的选择上也很慎重,为了便于开发实现,选择的开发工具为Eclipse,选择的数据库工具为Mysql。以此搭建开发环境实现制造装备物联及生产管理ERP系统的功能。其中管理员管理用户,新闻公告。 制造装备物联及生产管理ERP系统是一款运用软件开发技术设计实现的应用系统,在信息处理上可以达到快速的目的,不管是针对数据添加,数据维护和统计,以及数据查询等处理要求,制造装备物联及生产管理ERP系统都可以轻松应对。 关键词:制造装备物联及生产管理ERP系统;SpringBoot框架,系统分析,数据库设计

  • 采用springboot框架的基于HTML5的问卷调查系统的设计与实现(Java项目编程实战+完整源码+毕设文档+sql文件+学习练手好项目).zip

    传统信息的管理大部分依赖于管理人员的手工登记与管理,然而,随着近些年信息技术的迅猛发展,让许多比较老套的信息管理模式进行了更新迭代,问卷信息因为其管理内容繁杂,管理数量繁多导致手工进行处理不能满足广大用户的需求,因此就应运而生出相应的问卷调查系统。 本问卷调查系统分为管理员还有用户两个权限,管理员可以管理用户的基本信息内容,可以管理新闻资讯信息以及新闻资讯的租赁信息,能够与用户进行相互交流等操作,用户可以查看问卷信息,可以查看新闻资讯以及查看管理员回复信息等操作。 该问卷调查系统采用的是WEB应用程序开发中最受欢迎的B/S三层结构模式,使用占用空间小但功能齐全的MySQL数据库进行数据的存储操作,系统开发技术使用到了JSP技术。该问卷调查系统能够解决许多传统手工操作的难题,比如数据查询耽误时间长,数据管理步骤繁琐等问题。总的来说,问卷调查系统性能稳定,功能较全,投入运行使用性价比很高。 关键词:问卷调查系统;MySQL数据库;SSM技术

Global site tag (gtag.js) - Google Analytics