面对一堆代码，如何开始重构？

[v2byy]

无单元测试

[neptuno]

读懂了重写一份。。。

[nicenight]

那就先创建单元测试

[linglongll]

我做重构就是 把方法提取出来 不管他啥样给他包装出去 然后在调用的场景里加上注释 根据原有的逻辑重新组装一份人能看懂的 至于这些方法写成啥样 只要不是跑不了我就不管 大多数情况下这么处理 不这样的话还不如重写 当然 最好的方法还是避免重构 这就需要一手开发的时候的团队是不是给力了 这辈子真的再也不想给别人擦屁股 T.T

[tf2017]

ctrl + a
delete
-----
然后，重新开始……

[keysona]

理清脉络。

从小入手，如：修改变量名 /函数名，提取函数，封装对象等。

同时，有空自己写下单元测试。确保自己没有改错。

最后，熟悉整个项目后，就可以大刀修改了 --> 这种时候，如果有空的话，我会选择重写。

[likaka]

ctrl+f , 谁也逃不了

[micean]

如果对项目没有 90%以上的了解
一点都别碰

[ren2881971]

你确定要重构？ 有那时间干啥点不好。。 你确定能承担风险么。。

[xiaoshenke]

1 如果你是从第一版开始开发的。那就理清项目架构的，然后根据单元测试一个模块一个模块的慢慢迭代。
2 如果你是中途接手的。额，算了吧。重构是吃力不讨好的事，干得好没你功劳，干得不好(比如某功能出问题)是要背锅的。

[v2byy]

@xiaoshenke 中途接手，我也不想改，领导说现在代码结构有点乱，可能看我最近工作不饱和，叫我重构一下。

顺便我想重构看能否提升下自己。。。

[d18]

吃力不讨好的事情

[waytoexplorewhat]

先写单元测试，在确保功能 OK 的前提下重构。可以了解下测试驱动开发，建议看书，网上博客三言两语很难说清

[ben1024]

抽象是开始的第一步，然后在想着构建业务层，数据层，在后是服务层，仓库层

[jatesun]

最好的方法就是不重构，如果你非要重构，请叫上原来核心开发人员以及组里两三个高手先评估一天，然后从不重要的业务模块逐个重构攻破，当然单测是很有必要的

[limuyan44]

没有测试的重构都是在开玩笑

[zlmdaybreak]

看乱到什么什么程度，建议现将功能比较乱的类整理、将某个简单的业务进行整理，这些不会影响太广而且容易上手。等全部都整理完之前你的工作量应该就会上来了。

[xcjx]

我最喜欢干这种活儿了
楼主一定要注意：
重构前进行代码量统计，分析待重构部分的各方面性能指标，一定要做好记录，最好是找测试人员来做；
这样重构之后就能邀功了…
你不要担心没有功可邀，只要你的编码水平比之前的开发人员平均水平高那么一丢丢，各方面指标一定会有提升，因为你是一个人在架构整个模块（系统），考虑得必然比之前要全面；
到时候就拿着这些玩意儿再写个工作汇报，写出你的思路、改进点什么的。这个活儿保准比开发新功能还有改 bug 回报更高（绩效、技术等）
明明是重构，你要把它干成是性能优化，最后再来个技术分享，完美了。

如果你不这么干，你就是被欺负了……

[hiluluke]

先加测试吧

[posebear1990]

新建两个目录，一个叫 new，一个叫 old，然后把老代码丢到 old 里，以后新功能在 new 里开发，重构完毕。如果是老项目的话，你可以在比较深一点的目录里看一看，弄不好就有有某个目录有个 new，同时也有个 old。

[lucky2javascript]

@xcjx 我现在在重写整个前端，求指点啊，感觉时间不够

[zhangjiabin1010]

做好回退备份，理清全部代码。
按维度分类 先设计好新架构（要考虑到未来功能的扩展）。
代码方面的，什么命名,解耦,封装 。看情况慢慢来就好。
测试要完备，不然以后出问题都是麻烦啊~

[zichen]

重构代码我觉得最难的不是功能，而是理清业务，最近在带着组里的人将一个项目从.net 重构到 java，因为这个项目之前的负责人都走了，也没有什么像样的文档交接，所以只能扒代码看业务，然后还要求重构完的系统和老系统功能保持一致，关键是产品经理也走了，以前一些老的业务流程是啥样的，谁也不知道，只能靠猜，然后这个项目 50%的业务逻辑还是封在存储过程里的，存储过程可读性多差我就不用说了，总之现在刚重构完了一半，一堆坑，因为到现在我们还是没有一个人能 100%了解老项目的业务逻辑。

[aikin]

我一般都是先加测试，再重构。因为没有测试保障的重构，就是“耍流氓”。hahah

分享一个之前练习重构时，整合的所有重构手法练习的栗子和测试。https://github.com/aikin/refactoring-kata