重构，该不该大刀阔斧
最新开始做游戏了，没有用框架，纯手写的，写了几星期发现越写越乱了，现在打算重构一遍，应该遵循什么原则呢?对于有好多子类的应不应该改接口呢?改的话动作太大了。
------解决方案--------------------
重构是一个时刻和持续的过重，你现在还不重构一下，后面更是寸步难移了
------解决方案--------------------
差不多有同样的感觉吧。。
我做的是一套完成的商品上传的流程。
现在代码暂时是没有发现bug了，但是在对上传规则进行添加新功能或者修改的时候，找到相应的那段需要的代码特别累，而且改起来也特别的麻烦。
不过还是坚持在一点点的改，我估计如果改到符合我现在的这样审美要求的话，需要花大约4整天。
结合师父教我的以及自己的心得。总结几条，
第一，三层的结构一定要清晰，最上层只留一个最基本的调用方法，方法的代码行数不超过10行，最底层也是最基本的操作方法，代码也尽量的少。中间的service层尽量的多，尽量的全。
第二，service层可以创建一些servicehelper。service层可以相互多调用。
第三，注释尽量多，你懂得。
第四，每种方法尽量的简短，每种方法最好不要超过20行。当然，只有本类才会调用的声明为私有的除外。
------解决方案--------------------
重构，那得看你的架构 是不是很复杂或者说连架构都没有，太凌乱的话 你就有的受了
------解决方案--------------------
你自己将现有的代码类型划分归类.架构嘛,也就那么几个层次,什么数据层(Entity),DAO,Service.服务器的应用就这么几个类了.如果没有使用现有的服务器中间件的话,最好少用接口,因为抽象和具体就会增加现有程序的数量和纷杂,可以在后面再跟进.

其实你需要的就是整理出一个分层结构体.

增加结构的安全分布性时,使用抽象和具体两种技术.

这样就是你需要的自己建立的程序体系,也就是你的数据架构了.
------解决方案--------------------
楼主现在应该能体会到设计模式的好处了吧。。如果你不重构的话，以后维护代码会越来越慢。
------解决方案--------------------
如真的是乱七八糟一大堆的话，还是全部重构下的好。该接口的接口，该继承的继承，把层次分清，善用设计模式。再一个就框架了，有合适的框架还是推荐用一下，如果没有，可以在重构的时候自己造个轮子。当然这个轮子也许只适用于你现在的这个项目，但是在下个项目用的时候你就会继续改造这个轮子，久而久之你的项目也就条理清晰了。
------解决方案--------------------
现在感觉凌乱，不重构以后会更凌乱
------解决方案--------------------
建议看下这本书 重构：<<改善既有代码的设计>>
------解决方案--------------------
追寻低耦合高内聚