你需要的不是重构，而是理清业务逻辑

4顶
0踩

2013-04-12 10:00 by 副主编 WnouM 评论(11) 有12769人浏览

重构业务逻辑代码重写

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

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

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

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

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

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

英文原文：It's Not Refactoring, It's Untangling

查看图片附件

来自: 外刊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%不等于代码好读好懂，更别说好的代码还应该引导后续修改保持原本良好的风格了。
……

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

有道理，大型重构于理清业务逻辑之上。

发表评论

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

4顶0踩