重构之可复用

   根据前一篇的思维我进行着第一步拆分，但是在拆分的过程中怎么才算是已经拆分到最小呢？这个我思考了很久。最后我想的决定是：
1. 拆分的最小方法能够重用。
2. 能够简单进行Junit单元测试。
3. 拆分的最小方法尽量逻辑单一。
因此暂时不能将公司内部的代码公布所有这里先不能暂时出源码。所以这里先将思路记录下来，之后我在适当的进行展示一部分源码，及其重构后的源码，及其我用Junit的测试的测试用例。如果大家有什么建议或者异议可以一起探讨，也可以给出你的一些源码来探讨如果进行重构和编写测试用例。

我认为重构的核心目的是消除重复，简化逻辑，使代码可读、可修改、可维护； 复用可能是随着重构得到的，不是所有代码都需要复用，因为不同的程序核心业务不一样。

这点我赞成，我会根据业务的热点来确认那些是真正必须进行复用的！我认为重构本身是一种思维，优化代码的思维，所以不同的人对它的运用不同。这也是重构算都知道说，但是同一段代码可能重构之后大不一样。

拆分粒度是个问题.太细会有可能陷入为了重构而重构的泥潭.

最近对一个2年的项目做了重构, 重构方式是以重做的方式进行的, 历时半年.

重构中主要做的工作:
1. 移动代码, 整理模块间的界限.
2. 提取公共代码, 形成项目的公共库.
3. 增加单元测试, 重点于外部接口调用的测试. 保证输入输出无误.
4. 提取网管操作的WebService, 可以适应公司新老网管的版本, 并且可以进行冷切换.

现在对重构的理解, 不限于代码级.  以软件层,以及服务为目标进行重构, 这样更容易抓住问题的重点.

嗯，代码重构 设计重构 人员重构等等，核心思想还是一样