重构的成本真是巨大

2013-09-11 19:12:39 +08:00
 sivacohan
最近在重构项目里面的一个小功能。

最初的预期是两周时间,到目前为止,已经做了一个月了。虽然说期间也有其他更高优先级的事情打扰,没有全力的投入到重构大业,但是重构的进度和影响的范围也让我震惊了。(几个月前,做这个功能只用了两天的时间……)

目前在重构过程中发现的问题:

1、原来的代码的层级不清晰,会造成一些接口的滥用。而这些滥用的部分。在重构的过程中,必然会被清理出去。然后,就会惊奇的发现,原来现有接口按照规范是无法满足这个业务需求的,需要重新设计或者修改部分接口。

2、项目中的僵尸代码。早就没有人调用这些接口了。但是不知什么原因,这些代码被留了下来。这些代码的清理也是一个不小的工作。

3、不符合规范的接口。这个没得说,只要项目的生命周期变长,肯定会或多或少的存在不符合当前规范的接口。修改这些接口,以及相关app接口调用也是一个不小的时间。

4、重构时引入的新问题。想要尽量保持界面的原有样式,尽可能减少对用户的冲击。这就给重构的时候带来了很大的限制。为了保持样式不变,不得不多写很多无聊的逻辑和限制。

重构时关注的问题:

1、规范性。重构后的代码必须符合当前的规范。

2、文档的充分性。为自己积德吧……

3、考虑未来项目的发展。我这里主要是在js的层面开放了和数据相关的接口,提供了一个简单的模版。小的变化基本修改html和js就能完成了。

4、考虑未来因为项目压力引入的黑魔法。有些时候项目要求xx时间之前上线,这时硬编码就算黑魔法里面最简单的部分了。我在代码里面提高了指定的位置用来写脏代码。就一个地方脏,总比到处都脏,跟捉迷藏一样要容易处理。提供的方式是给数据加了一个filter,目前filter是空的,未来就往这里写脏代码。

综上,我真的为我自己提出这次重构而深深的自责……

PS:希望各位也说说关于重构的经验,诸如如何预估重构所需要花费的时间,限制自己在重构的时候看到不爽的地方就想改的冲动等。
5160 次点击
所在节点    程序员
26 条回复
jjx
2013-09-13 11:07:34 +08:00
几星期,几个月的很难叫重构了, 应该算是重写了吧
HowardMei
2013-09-13 11:08:42 +08:00
快速迭代成功的典型例子37Signals在成功之前,做了很久咨询和外包,大概也是为了降低重构成本,才搞的ROR框架吧 :D

重构不能太深入底层,否则迭代快不起来,但不多次彻底重构积累经验,很多比较基础的模块质量很难提高,开发水平也上不去,技术和业务的平衡是两难,要看长期目标。
darasion
2013-09-13 11:19:49 +08:00
其实不用重构的~~

也许你可以只是删一些没用的代码,有时候这样比重构更有效。
bluntblade
2013-09-13 12:51:08 +08:00
建立一个新模块,接口保持一致,是以重建。
pipi32167
2013-09-14 13:24:01 +08:00
不要想着以后重构,现在就开始考虑代码质量,尽量考虑完善,把你的接口设计得尽可能解耦,最好还能尝试使用单元测试来辅助模块解耦的工作。

说白了重构就是改革嘛,你想想看历史上真正成功地改革有多少次,得照顾方方面面的,很多时候,重构是为了更好地工作,如果反过来阻碍了工作,反而不美。
qian19876025
2013-09-14 13:56:10 +08:00
楼主啊 有些东西不符合规范 但是千万别乱改啊
记得前年华为里面就有人觉得某段代码不符合标准规定擅自更改了
后果就是产品上线后直接崩溃 影响很大

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/82098

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX