重构 新人求助,是需要简单重构还是推倒重写?

pengedy · 2015年03月18日 · 最后由 liuyunfeng 回复于 2019年01月24日 · 8401 次阅读

最近接手了公司的一个 Rails 项目,发现这个项目的 Controllers 有 3118 行,而 Models 有 1762 行,也没有 Service 之类的分层。 我在摸清楚这套项目的业务逻辑的同时,也发现这里面的代码有各种不科学,所以问题来了:是重构,还是推倒重写?(时间相对充裕)

我第一次遇到这样的事情,没有太多相关经验,求指点迷津。

建议都不,能运行就行了!!!

#1 楼 @flowerwrong 真的么... 现在维护这个项目,感觉开发越来越困难了。

才 3000 行,以前碰到过单文件就 3w 行的都有! 看看需求更改的频率,评估一下后面项目的生存期,再打算吧。

才 1762 行。。。。这是俺厂一个函数下 if 语句的的长度

#4 楼 @est ……………………我写代码少,不要欺负我=。=

#3 楼 @king1990_cool 那样规模的代码,内部结构是怎样一种状态呢?

先写测试,再考虑重构

3000+ 行?所有 Controllers?还是其中一个

#7 楼 @foxzool 明白了,多谢。 #8 楼 @a4652097 所有 Controller。这些数据是rake stats出来的。

#5 楼 @pengedy 从代码行数看得出来贵厂负责人口味,重构是断然不会涨工资的。能拖就拖,不能拖了果断闪人。

我厂 app 部分也是差不多你说的情形,非常混乱,来了个高手来重构,搞了 3 个月屁都没见到一个。

#10 楼 @est 嗯嗯这些我明白。因为现在代码规模不是很大嘛,所以才有重构的可能性,如果是特别大的规模,那真的就不考虑重构这回事了。

#11 楼 @pengedy 重构是有风险的,不是你一个人的事情,你的时间是很充裕,但是这个系统的用户还要配合你测试。你能保证重构后,之前的所有功能都不受影响吗?

#12 楼 @libuchao 所以上面有人提到先写测试再重构。重构过程中开发进度稍微放缓,原有系统不下线。

#11 楼 @pengedy 你觉得这个坑会长期干下去还是可以重构的。

重构成本 = 立项做新系统 x 3

#14 楼 @est 嗯嗯,现在我已经大致清楚了。只是好奇,下面这个公式是如何得来的? 😄

听听同事和 boss 的意见,再决定。

直观感觉这种项目不可能重构,除非有极好的配套测试。

#13 楼 @pengedy 测试是要写,但是测试的覆盖率也不是 100%,人工测试也肯定是少不了的

#16 楼 @liwei78 看来测试是重点。明白了。

差不多情况 拆不动 后面写的时候再抽逻辑吧 重构还要保证正常更新和线上的没问题 工作量会很大的

这是准备跳坑啊

不要读了几个博客就想当然认为你必然写得比别人好。别人的可能不好看,但至少能用。

新人的话就稳妥一点,碰到哪里改进哪里,一点点地改善,至少还有人帮你盯着。

if it ain't broke, don't fix it 切记,切记

too young too simple,这是我维护过的 application,看 controller 行数 model 行数 和 code to test rational

#23 楼 @317583395 Orz... 我真是忍不了这个+_+

| Name | Lines | LOC | Classes | Methods | M/C | LOC/M | +----------------------+-------+-------+---------+---------+-----+-------+ | Controllers | 3424 | 2635 | 38 | 321 | 8 | 6 | | Helpers | 543 | 535 | 0 | 6 | 0 | 87 | | Models | 351 | 257 | 30 | 8 | 0 | 30 | | Mailers | 0 | 0 | 0 | 0 | 0 | 0 | | Javascripts | 13629 | 8412 | 0 | 711 | 0 | 9 |

#10 楼 @est 你们一个 if 语句下面就有千把行,再牛的高手也不好使...

我现在的项目,测试比较惨,就不贴了…… 重构是为了更低成本地持续改进项目,而不是为了更优美的结构。如果你 自信已经搞懂了项目已有功能,并且有更好的办法让未来的功能实现起来更轻松 ,就小块小块地重构。不然碰到新功能或者要修复 bug,就只能沿用已有代码的逻辑,不停的打补丁,最后可维护性会越来越差。

+----------------------+-------+-------+---------+---------+-----+-------+
| Name                 | Lines |   LOC | Classes | Methods | M/C | LOC/M |
+----------------------+-------+-------+---------+---------+-----+-------+
| Controllers          |  2523 |  2010 |      50 |     263 |   5 |     5 |
| Helpers              |    35 |    31 |       0 |       5 |   0 |     4 |
| Models               |  2537 |  1938 |      39 |     197 |   5 |     7 |
| Mailers              |   175 |   141 |       8 |      24 |   3 |     3 |
| Javascripts          | 18302 | 13417 |       0 |    1995 |   0 |     4 |

建议从最容易的地方开始入手,逐渐将系统重构得逻辑比较清晰就应该可以了。不到万不得已,不要大刀阔斧,否则容易受伤。

代码的总行数不重要,关键是代码结构是否足够清晰,架构好的项目即使功能再多也易于维护

+----------------------+-------+-------+---------+---------+-----+-------+
| Name                 | Lines |   LOC | Classes | Methods | M/C | LOC/M |
+----------------------+-------+-------+---------+---------+-----+-------+
| Controllers          | 47826 | 19878 |     364 |    1836 |   5 |     8 |
| Helpers              |   196 |   165 |       0 |      17 |   0 |     7 |
| Models               | 15133 | 10429 |     289 |     643 |   2 |    14 |
| Libraries            |  1216 |  1003 |      29 |      65 |   2 |    13 |
+----------------------+-------+-------+---------+---------+-----+-------+
| Total                | 64371 | 31475 |     682 |    2561 |   3 |    10 |
+----------------------+-------+-------+---------+---------+-----+-------+

学到了新的命令 rake stats,哈哈,原来一直孤陋寡闻了

没事不用重写,可以进行一些小规模的重构,观察是否带来问题,逐渐的改善系统。

@billy @jimrokliu @cuterxy @darkbaby123 感谢各位提供宝贵意见,我确实没有足够的把握直接重构,那就分小块来做吧,首先要弄好测试,嗯嗯。

#15 楼 @pengedy x3 这个公式这样来的。

重构本身开发成本,x1 重构要兼容之前的运作方式 x2 平滑迁移之前的数据和模型到重构版本 x3

真是累死人的事情。

foxzool 回复

赞同 完善的单元测试才能让重构变得不那么危险

需要 登录 后方可回复, 如果你还没有账号请 注册新账号