V2EX = way to explore
V2EX 是一个关于分享和探索的地方
Sign Up Now
For Existing Member Sign In
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 3193 days ago, the information mentioned may be changed or developed.
 |
1
Sirormy Jul 31, 2017  1
先备份，然后整理文档，review 测试。
|
 |
2
calpamomo Jul 31, 2017
先确定有没有需要继续使用这个项目的现有框架，还是推倒重来比较好
|
 |
3
111111111111 Jul 31, 2017
测试
文档 测试 |
 |
4
Fe1Fan Jul 31, 2017 via Android 1
先点根烟
|
 |
5
zjsxwc Jul 31, 2017 1
重构又不是重写。
一步步按照《重构》里讲的方法就可以安全重构了，无非多写几个变量名，挪下代码位置。 |
 |
6
XiaoFaye Jul 31, 2017
先问老板要 Budget ！！！！
|
 |
7
orderc Jul 31, 2017 1
写好辞职单
|
 |
8
xeneizes Jul 31, 2017
删除，重写
|
 |
9
Chyroc Jul 31, 2017
rm -rf *
|
 |
10
timwei Jul 31, 2017
做好灾备，这很重要
|
 |
11
soulmine Jul 31, 2017
准备几瓶安眠药
|
 |
12
nullen Jul 31, 2017
先做减法。
|
 |
13
Vvfan Jul 31, 2017
放弃这个念头
|
 |
14
Qlccks2 Jul 31, 2017
想到之前经历，有个同事牛逼哄哄的说他负责哪个模块代码太烂要重构，重构完了业务测试时候连测试数据要初始化哪个表都不知道。
|
 |
15
kukat Jul 31, 2017
1. 测试
2. JetBrains 家的 IDE |
 |
16
catror Jul 31, 2017 via Android 1
重构不是重写，想清楚自己想要的结果，一点点的搞就行，而不是大刀阔斧的这删掉那删掉
|
 |
17
hantsy Jul 31, 2017
在中国，大多数公司都是饮鸩止渴的开发，求的是第一时间做个界面出来，代码基本上都是垃圾。基本上从项目一开始基本上没什么架构设计的概念，初期 Research 也不会写 POC。本该重构的最后都是 Rebuild，Rewrite，Revolution。。。哪有 Refactor，Evolution，Migration 的说法。
|
 |
18
keysona Jul 31, 2017
睡个觉冷静下。
|
 |
19
LeoNG Jul 31, 2017
自问自己最近是不是太闲了，竟然有了这么冲动的想法。
|
 |
20
hellohello123 Jul 31, 2017 1
仔细理清现有代码逻辑，一步步来，步子迈大了，容易扯着蛋
|
 |
21
finian Jul 31, 2017 via Android
冲个凉水澡，抽根烟，然后取消这个念头
|
 |
22
xiaoxiao0 Jul 31, 2017 via Android
分批，重构一批测试一批
|
 |
23
Cabana Jul 31, 2017 via Android
哈哈，前段时间没事干傻逼呼呼的把公司 app 代码全部重写，写了 1/5，弃了…
|
 |
24
wangdu2012 Jul 31, 2017 via iPhone
理清楚业务，在规划业务，在设计方案，在逐步实现
|
 |
25
voocel Jul 31, 2017 5
反手就给自己来一巴掌！
|
 |
26
sagaxu Jul 31, 2017 via Android
如果不是代码实在维护不下去了，干嘛重构，成了没有功劳，没成就是没事找事给团队添乱
|
 |
27
akira Jul 31, 2017 1
1. 先点根烟，想清楚自己准备要做的事情有多炒蛋。
2. 备份，再三确认代码是否有做好备份。 |
 |
28
Rice Jul 31, 2017 via iPhone
单元测试？
|
 |
30
msg7086 Jul 31, 2017
申请预算，招几个人，然后把项目代码 Shift-del。
|
 |
31
IamRobot Aug 1, 2017 via Android
准备一箱方便面
|
 |
32
ie88 Aug 1, 2017 via Android
真的不开玩笑，冷静点，放弃这个念头
|
 |
33
flyingghost Aug 1, 2017
准备好细软。
|
 |
34
omygod Aug 1, 2017
先读几篇心灵鸡汤
|
 |
35
Wangxf Aug 1, 2017
重构一个项目技术倒是其次考虑的，首先要把业务梳理清楚
|
 |
36
ZhLTE Aug 1, 2017
抽根烟冷静下
|
 |
37
rswl Aug 1, 2017
抽根烟冷静一下 确定要重构吗
|
 |
38
RangerWolf Aug 1, 2017 1
不知道楼上一堆冷嘲热讽的人是怎么想的， 重构是一个项目很重要的一步。 除非业务业务已经不需要任何变动。
有单元测试的重构会比较保险。 |
 |
39
pljhonglu Aug 1, 2017
做好相关人员的心里安抚工作~
|
 |
40
hotdigger Aug 1, 2017
1、用户调查：当前项目的需求方是否都还在？当前用户对现有功能满意与不满意的地方是什么？程序员眼中的垃圾代码或功能往往对用户来说，却是很好用的功能或特性。
2、业务调查：分析业务对此项目最重要的功能依赖是哪些，是否允许分步骤平滑过渡。 3、文档调查：检查是否之前的需求文档、设计文档及用户手册以及重要模块的代码注释是否有？如果没有，当事人（需求方以及开发者）是否还在？相当多的自主开发项目都是文档不全，或者严重过时。更多的设计是在程序员的大脑里。 4、项目复杂度评估：重要项目重构，需要做详细的风险评估，特别是时间风险，老板往往不一定有足够的耐心让你投入大量的人力与物力进行项目重构，毕竞老板是结果思维，特别是老板不懂技术，需要老板的支持。 5、分步上线计划，重构最重要的事情，个人认为是将功能分步完成，测试，并分功能模块上线。让老板看到阶段目标，让用户更早接触到新系统。 6、用户期望的引导，在重构之前，根据第一步用户调查的结果，把新系统对旧系统的改进提升跟用户沟通，以及短期内还无法达到部分期望的原因。最简单的办法，是充分尊重用户的意愿，让用户参与进来，这是重构系统成功能的重要保证。如果用户参与了新系统的设计，新系统更替让系统遇到的阻力会小很多。 |
|
41
hotdigger Aug 1, 2017
汗，看成重写系统了。。。。如果对题主没有帮助，请忽略！
|
 |
42
chemandy Aug 1, 2017
准备跑路
|
 |
43
zengyuxi Aug 2, 2017
巧了，我这个两个星期正好在重构项目中最复杂的一个核心模块，使用了几个设计模式好好设计了一下，整体的可读性和后期的拓展性确实很大的提高！
我觉得不论是重构项目还是重构模块： 首先考虑的是架构，你是否能 hold 住？譬如 MVC 架构--》重构成 MVVC+RX 的架构！ 重构的复杂度问题？建议一点一点的重构，先重构架构，然后一个模块一个模块的拆分重构 个人认为，模块重构的话，时间充裕的话，直接重写！一来加深对业务的理解，二来重新设计重新写的过程对自己技术的提升是非常快的！（性能优化，设计优化，架构优化。。。） |
Select Language