在博客中我也看到了好多关于系统框架的文章，就象有些朋友说的，这些系统框架大同小异，一般是分为数据访问层、实体层、业务逻辑层、业务外观层、表示层。然后就是这些层与层之间的调用，这些我想对于做过稍大一点的项目、或者小型以上团队开发的项目，都是会考虑到这些分层模式带来的系统扩展性优势。
有些朋友都建议加一个common层，把一些共公的类与方法集中在一起，让大家一起调用，可以减少重复代码，这个我也是很支持的，也是这样做的。
我相信目前摆在我们面前的，已经不是这些系统框架的问题了，而就是这些结构中体现出来的开发模式的问题。
大家所说的要把公共的代码放在一起，这就是“重构”所要体现的思想，重构就是为了让代码更具的扩展性、维护性，能减少重复代码，这可以从根本上提高代码的效率并减少修改导致的BUG恶性循环。
重构一般发生在什么时候？
代码设计期：这要求设计人员把公用的方法总结出来，放在公用的模块中，生成文档或是通过其他方式，反正就是通知大家这些公用方法，而这是非常有限的，设计人员无法思考出所有的公用模块与方法，相反，这些只是极小的一部分，因为更多的重构应该发生在下面。
代码开发时：当我们第一次写一段代码时不会注意，写第二遍时我们会想：算了再写一遍吧。准备写第三遍时，我们必须要醒悟过来，这些相同的代码可以放在一个公用的方法中调用，对，在第三次时我想我们最好是这样做，因为你现在这样做，不仅仅是为了现在，而是为了将来。我们就会写成公用方法，并一定要把原来的两个方法采用“调用”的方式，可千万不要偷懒，谁也无法保证今后不会修改这个函数，而如果真的修改了，你没有能力找出最先的那两段代码了，恶梦从此开始。
代码修改时：项目已经开发完成，在后期的维护中，一次次的修改会使每一位程序员痛不欲生，没有了当初的热情、有几位已经退出了团队、对原系统遗忘的很多、修改变的越来越没有道理了，就这样，曾经热情高涨的代码编写变的应付了事了，重构再也没有勇气了，就这样的，没有了重构，死循环的恶梦真正的开始了，后面的修改与维护变的越来越困难了。然后，在这个时间进行重构仍然是非常重要的，在进行修改时，我们要仍然保持这种心情，我们只要相信，每一次修改是为了减少修改，而不是相反，那么，我们还是要相信重构。
重构的过程就是这样，在慢慢的过程中，系统会变的越来越精简，修改也会变得变来越少，而且越来越容易，当我们在修改时发现：我只要修改这一个地方就可以了。这仍然是可能让我们保持热情的理由。
可是问题呢：问题就是在这些重构过程中，如何及时的通知其他的队友，重构不是针对开发人员的，重构是针对系统的，当一个人进行了代码重构后，如何通知其他的队友：朋友们，我添加了XXX方法了，参考请看YYY,请大家进行一下相关的修改或注意以后的调用。
其实我也是不知道如何维护整个系统的信息交流，我想首先想到的就是mail了吧，一封邮件的通知，可以完成一个重构人员的信息发布，可是接受者呢，在一封封的邮件中进行着一次次的修改，而且这些零散的邮件会让人找不到方向。
那么好吧，放在一个集中的地方，大家把重构都放在一个公共的地方我想是比较好的方法，不过，大家得经常注意这些信息，而且要由项目经理，下令大家严格按照重构机制做系统。这样也好，系统完成后，也会形成一份统一的重构方法集合，可以作为系统开发文档的一部分，而且这部分是相当重要的。
我其实找不到一种好的项目开发模式，从而有很多重构思想，在现实中没有充分的发挥，希望大家也讨论讨论，能让我们更多的进行实践，而不是纯粹理论。
关于重构的细节，我想网上已经有很多资料了，我相信，那对我们是非常重要的，当然我也是只懂一点点，这需要慢慢体会与研究的。
