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

oschina
 oschina
发布于 2013年04月12日
收藏 81

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

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

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

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

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

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

[英文原文:It's Not Refactoring, It's Untangling ]
本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 OSCHINA 社区 [http://www.oschina.net]
本文标题:你需要的不是重构,而是理清业务逻辑
加载中

最新评论(75

footmanff
footmanff

引用来自“xesam”的评论

一个季度的清理之后,只不过是另一个垃圾的开始。
哈哈,在理!
footmanff
footmanff

引用来自“xesam”的评论

一个季度的清理之后,只不过是另一个垃圾的开始。
哈哈,在理!
dongingdao
dongingdao
同意,现在有那么点体验到了这种情况。前期没有规划好, 后面不断加功能,导致了后面的困难
尧思齐
尧思齐

引用来自“winters”的评论

对简单系统来说,自解释的代码就足够了;但对复杂些的系统,这肯定不够。自解释的代码能够很好的解释自己的功能,但解释不了系统的架构、设计和业务逻辑。这些东西需要有文档来做说明。

顶。
尧思齐
尧思齐

引用来自“pillsilly”的评论

我觉得写注释是需要培训的.

这个得顶。
没事折腾
没事折腾
嗯!是這樣的。。。
雅各宾
雅各宾
瘘猪你当初做事业就是屎壳郎吃大便,自以为天下美味,至今不曾悟道!
雅各宾
雅各宾
我告诉你瘘猪,这公司缺少说真话的环境,老板没有接受现实的勇气。就这么简单!
JasonSE
JasonSE
我去,原来都这样啊。
梦之人生
梦之人生

引用来自“雅各宾”的评论

吵个几吧! 问题出在老板这里!短视,急功近利,资本压榨! 厂主! 没文化,还装屄!
你们都是他们选择的结果,都是垃圾。当然,作为成果,代码自然是垃圾!

楼上惊人的发现真相
返回顶部
顶部