这是一个创建于 3879 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近在重构项目里面的一个小功能。
最初的预期是两周时间，到目前为止，已经做了一个月了。虽然说期间也有其他更高优先级的事情打扰，没有全力的投入到重构大业，但是重构的进度和影响的范围也让我震惊了。（几个月前，做这个功能只用了两天的时间……）
目前在重构过程中发现的问题：
1、原来的代码的层级不清晰，会造成一些接口的滥用。而这些滥用的部分。在重构的过程中，必然会被清理出去。然后，就会惊奇的发现，原来现有接口按照规范是无法满足这个业务需求的，需要重新设计或者修改部分接口。
2、项目中的僵尸代码。早就没有人调用这些接口了。但是不知什么原因，这些代码被留了下来。这些代码的清理也是一个不小的工作。
3、不符合规范的接口。这个没得说，只要项目的生命周期变长，肯定会或多或少的存在不符合当前规范的接口。修改这些接口，以及相关app接口调用也是一个不小的时间。
4、重构时引入的新问题。想要尽量保持界面的原有样式，尽可能减少对用户的冲击。这就给重构的时候带来了很大的限制。为了保持样式不变，不得不多写很多无聊的逻辑和限制。
重构时关注的问题：
1、规范性。重构后的代码必须符合当前的规范。
2、文档的充分性。为自己积德吧……
3、考虑未来项目的发展。我这里主要是在js的层面开放了和数据相关的接口，提供了一个简单的模版。小的变化基本修改html和js就能完成了。
4、考虑未来因为项目压力引入的黑魔法。有些时候项目要求xx时间之前上线，这时硬编码就算黑魔法里面最简单的部分了。我在代码里面提高了指定的位置用来写脏代码。就一个地方脏，总比到处都脏，跟捉迷藏一样要容易处理。提供的方式是给数据加了一个filter，目前filter是空的，未来就往这里写脏代码。
综上，我真的为我自己提出这次重构而深深的自责……
PS：希望各位也说说关于重构的经验，诸如如何预估重构所需要花费的时间，限制自己在重构的时候看到不爽的地方就想改的冲动等。
最初的预期是两周时间，到目前为止，已经做了一个月了。虽然说期间也有其他更高优先级的事情打扰，没有全力的投入到重构大业，但是重构的进度和影响的范围也让我震惊了。（几个月前，做这个功能只用了两天的时间……）
目前在重构过程中发现的问题：
1、原来的代码的层级不清晰，会造成一些接口的滥用。而这些滥用的部分。在重构的过程中，必然会被清理出去。然后，就会惊奇的发现，原来现有接口按照规范是无法满足这个业务需求的，需要重新设计或者修改部分接口。
2、项目中的僵尸代码。早就没有人调用这些接口了。但是不知什么原因，这些代码被留了下来。这些代码的清理也是一个不小的工作。
3、不符合规范的接口。这个没得说，只要项目的生命周期变长，肯定会或多或少的存在不符合当前规范的接口。修改这些接口，以及相关app接口调用也是一个不小的时间。
4、重构时引入的新问题。想要尽量保持界面的原有样式，尽可能减少对用户的冲击。这就给重构的时候带来了很大的限制。为了保持样式不变，不得不多写很多无聊的逻辑和限制。
重构时关注的问题：
1、规范性。重构后的代码必须符合当前的规范。
2、文档的充分性。为自己积德吧……
3、考虑未来项目的发展。我这里主要是在js的层面开放了和数据相关的接口，提供了一个简单的模版。小的变化基本修改html和js就能完成了。
4、考虑未来因为项目压力引入的黑魔法。有些时候项目要求xx时间之前上线，这时硬编码就算黑魔法里面最简单的部分了。我在代码里面提高了指定的位置用来写脏代码。就一个地方脏，总比到处都脏，跟捉迷藏一样要容易处理。提供的方式是给数据加了一个filter，目前filter是空的，未来就往这里写脏代码。
综上，我真的为我自己提出这次重构而深深的自责……
PS：希望各位也说说关于重构的经验，诸如如何预估重构所需要花费的时间，限制自己在重构的时候看到不爽的地方就想改的冲动等。
 |
1
ejin 2013-09-11 19:57:04 +08:00
楼主遇到了上帝，上帝愿意让楼主许愿次，于是发生以下对话
楼主拿着地球仪说到：上帝，我希望世界和平！ 上帝： 这个太难了，换一个！ 楼主：我想成功的重构这个项目的！并希望以后再也不用对它重构了。 上帝沉默了一会说到： 我们还是来谈谈世界和平的事情吧！ |
 |
2
missdeer 2013-09-11 21:00:08 +08:00
我前不久也是自以为对一个小功能进行重构，本以为三天到一周就可以搞定，结果断断续续搞了约1个月
|
 |
3
Xrong 2013-09-11 21:09:49 +08:00
不能同意更多，最近被重构搞的头晕脑大，旧代码各种逻辑混在一起，数据库存在冗余无用字段，接口不完善，清除各种无用代码，需求不清晰，越迁越无力...
同求重购大神给点意见... |
 |
4
felix021 2013-09-11 21:42:16 +08:00
感觉重构就是个大坑，遇到这些事情是必然的，能做的事情就是仔细考虑这次应该如何实现，避免下次重构，或者至少下次别人接手重构的时候不会想砍你……
|
 |
5
williamx 2013-09-12 09:00:15 +08:00
我觉得如果重构的时间在3个小时以外，那可能已经不是重构的范畴了。
|
 |
7
angelface 2013-09-12 09:09:12 +08:00
手滑，更正：你那是重写， 不是重构
|
 |
8
geew 2013-09-12 09:12:48 +08:00
确实 重构到一半感觉不会再爱了
|
 |
9
66450146 2013-09-12 09:49:19 +08:00
为了避免未来重构上的蛋疼，我在这个项目里面写每个类每个方法都很小心，尽量不要去破坏程序的结构。。。
现在这个项目花费的时间已经接近计划的三倍了 |
 |
10
jianghu52 2013-09-12 09:55:37 +08:00  1
说一个个人的重构的经历。一个网站，要修改后台的验证机能，一看，耦合太紧密，所以决定重构。后果就是：从测试式样开始写，包括详细式样，整整写了20m的文档。代码比以前大了2倍，但是整洁了很多。最最关键的是，客户不给钱！！！
|
 |
11
min 2013-09-12 10:13:55 +08:00
重写的成本是很大的lz
|
 |
12
jun0205 2013-09-12 21:48:01 +08:00
不要做无谓重构。重写就更不要了，一个产品不应该是看代码写的好不好。
|
 |
13
hitsmaxft 2013-09-12 23:59:20 +08:00 1
重构, 是看你对实际整体逻辑的把握情况, 所以.. 预想时间 * all/你实际了解的半分比 * 传说中预估时间放大因子(约为2) = 最终时间
|
|
14
hitsmaxft 2013-09-13 00:00:13 +08:00
半分比 -> 百分比
|
 |
15
so898 2013-09-13 00:20:51 +08:00 1
好在我现在写的项目都是充分或者强制OO的
我现在想要重构一个部分，都是先找张纸记好功能和需要优化的部分，然后来点小酒，删掉Class，重头开始…… 再不行的就直接删掉整个项目重来了…… |
 |
16
cmonday 2013-09-13 00:35:11 +08:00
重构是为了未来
|
 |
18
hekunhotmail 2013-09-13 08:58:43 +08:00
重构不如重写，这是我的经验，当然只是针对小项目 对于大项目重构的成本大 周期长 是必然的
|
 |
19
firsthym 2013-09-13 10:21:39 +08:00
我重构过1个C++写的web CGI，重构主要集中在MVC中的V和C，M因为是核心部分所以基本没有变动。
|
 |
20
eary 2013-09-13 10:53:33 +08:00
直接重写
|
 |
21
jjx 2013-09-13 11:07:34 +08:00
几星期,几个月的很难叫重构了, 应该算是重写了吧
|
 |
22
HowardMei 2013-09-13 11:08:42 +08:00 1
快速迭代成功的典型例子37Signals在成功之前，做了很久咨询和外包，大概也是为了降低重构成本，才搞的ROR框架吧 :D
重构不能太深入底层，否则迭代快不起来，但不多次彻底重构积累经验，很多比较基础的模块质量很难提高，开发水平也上不去，技术和业务的平衡是两难，要看长期目标。 |
 |
23
darasion 2013-09-13 11:19:49 +08:00
其实不用重构的~~
也许你可以只是删一些没用的代码，有时候这样比重构更有效。 |
 |
24
bluntblade 2013-09-13 12:51:08 +08:00
建立一个新模块，接口保持一致，是以重建。
|
 |
25
pipi32167 2013-09-14 13:24:01 +08:00
不要想着以后重构，现在就开始考虑代码质量，尽量考虑完善，把你的接口设计得尽可能解耦，最好还能尝试使用单元测试来辅助模块解耦的工作。
说白了重构就是改革嘛，你想想看历史上真正成功地改革有多少次，得照顾方方面面的，很多时候，重构是为了更好地工作，如果反过来阻碍了工作，反而不美。 |
 |
26
qian19876025 2013-09-14 13:56:10 +08:00
楼主啊 有些东西不符合规范 但是千万别乱改啊
记得前年华为里面就有人觉得某段代码不符合标准规定擅自更改了 后果就是产品上线后直接崩溃 影响很大 |
Select Language