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