重构代码一般从哪些方面入手？

[scarlex]

最近想重构以前的代码，但不知道应该从哪些方面入手。
有木有人可以给点经验？

[Akagi201]

@dongbeta 有同感, 想把相同功能移植过来, 测试ok了, 再添加和改进

[zhanglongyang]

我们最近一周都在做重构，我们面临的问题是由于耦合度太高导致在现有代码基础上无法有效添加某个新功能，我们的思路是通过这个新功能的需求为驱动去解耦。一个比较重要的体会是：重构过程中要不断设定比较具体的目标。

[venson999]

任何没有测试的重构都是瞎改！

[Ricepig]

@Mutoo 然后需要“测试的测试”先行，然后再是“测试的测试的测试”更先行，然后子子孙孙无穷溃也

[Mutoo]

@Ricepig 你这个观点和“一尺之竿，日取其半，万世不竭”一样没有什么意义，TDD只是让程序变得比没有测试更靠谱，比测试后行更优美而已。这样就够了。

按你的观点，TCP三次握手可以引伸出无限握手，然后推导出网络传输一点都不靠谱的结论；

[vietor]

重构代码，有可能费力不讨好，换一批人，又会觉得以前写的是SHI。

依据我的经验，都是“方法”替换，逐步“向上推进”的，绝对不能“大删大改”。步骤谈一下：
1）找出，没有被调用过的方法，删掉。
2）找出，C-c C-v明显的代码，合并到一个方法中。
3）将功能相近的函数，封装到一个“新类”中，逐步替换“旧类”的引用，直至最后删除。

当然，根据使用语言的不同，还有一些不同的细节:
1) C#这些能够在一个文件中存放多个类的语言，我可能将一个整体功能放入一个文件，文件可能很长。有人批评过我的做法，但它有一个好处就是让“功能”更加“集中”和“独立”。对于这种“模块”是有选择要求的：“足够独立”，比如一个HTTP服务器模块。
2）如果可能，还是采用“显而易见”的语言特征。如，在避免在C++中使用lumbda；C#能够用callback表达的，就不要用Event。

[Ricepig]

@Mutoo 哈哈，开个玩笑。不过，TCP的三次握手是保证在“绝大多数”情况下网络靠谱，如果要严格说起来，网络传输确实一点儿都不靠谱呢。哈哈

[winnie2012]

弄一本《重构》看看就OK了，一般是指坏味道

[wenjixin]

不要重构

[egen]

不要因为看代码不顺眼而重构

[luikore]

不管是升级依赖的库版本, 还是重构, 或者优化, 先要有测试, 有了测试怎么玩都可以. tdd 更容易保证测试和实现是两套不同的 mind set (测试是用户视角, 实现是程序逻辑视角), 以及实现不冗余. 但就算是测试后行, 也胜过没有测试.

如果说没时间写测试, 那只有两种可能:
错误估计了需要花费的时间, 你的"重构"是能搞完, 但是之后还有一大堆 bug 等着修.
或者是之前缺乏测试, 浪费在修 bug 上的时间已经太长了, 造成了恶性循环.

测试容易落入的两个误区:
1是有些语言(先天缺陷, 尤其是java, c#)和环境(设计模式粉的架构)很难搞自动化的功能测试和集成测试, 所以很多人只写点皮毛的单元测试了事 -- 这样的测试用处就很小了 -- 但就算很难写, 写出来以后就是沉淀在那里的价值了. 多数老公司还有很多专门的测试人员去手动做集成/验收测试, 那么你重构以后必须让测试人员去各种点一遍...
2是测的东西体现了太多关于实现的知识, 不得不使用很多 mock 和 stub (多见于后行的测试). 测试时最好换位思考, 从使用者角度去想问题, 或者直接换个人写测试.

[sivacohan]

@vietor 有些时候还会把一些函数展开成C-c C-v 目的是减少依赖的复杂度。

[hunter]

熟悉整个业务流程，抽象出来模块交互行为，订立接口规范，评估现在的代码和目标代码间的差距，估算出来时间。开始重构。。。

[williamx]

从合并代码，修改变量的名字，提取函数开始。

[pipi32167]

不写测试的结果就是作死。。。你知道的，不作死就不会死。。。

补测试，模块化重构。