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

[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 我现在在重写整个前端，求指点啊，感觉时间不够