重构实践之一(zz)

昨天看了一下CSDN举办的SD2.0大会邀请的嘉宾，不得不说，确实阵容很强大，都是业界比较有名气的人，就小弟知道名有其人的，有JE的肉饼，翻译《深入java虚拟机》的曹晓刚，JE技术大牛李锟，《java夜未眠》作者蔡学镛等等。大会涉及软件开发的8个领域，我比较感兴趣的是架构和实践，或许我可以借此解决我工作中遇到的问题。



目前手上差不多有四个任务，其中2个是跟重构有关，一个是上面分给我的，一个是我主动要求的，我很感谢头儿分给我这么一个比较有趣而且有挑战性的任务，重构就是站在别人的肩膀上看问题，这不是一个简单的事情。虽然只是某一个小模块，但是我也满足了。小到一个变量，一个方法的重构，大到一个模块设计的重新架构，我都必须谨慎对待。我知道重构是一件神圣的事情，我更乐意叫维护人员为重构人员，软件的80%工作都是在维护和重构，在我看来，重构是大型软件企业急需的技能。



重构能力=企业持续的竞争力，这样说一点都不夸张，就拿我们公司来说，目前的项目组的架构已经不能够满足各个功能的修改，每一次小的变动都必须修改代码，每一次提交测试都会反馈大量的BUG，有几个模块因为当初设计的时候路线不对，现在修修补补了好多次还是有很多BUG。



拿一个我比较熟悉的任务来说，重构的需求，也是目标：

1.通用性（可复用性），头儿要求最好能够适用组内其他小项目，尽量将所有重复性的代码都写在一个地方集中管理，提炼出不同的业务逻辑，这一部分可以根据各个小项目自定义，不管是继承类也好，写在配置文件也好，只要将不变的和变化的分开，尽量做到代码层次的重用，业务逻辑层次的重用就好。

2.可维护性（可扩展性），模块必须满足目前面临业务逻辑所有可能的情况，意思就是说，在目前能够想到的业务逻辑变化时，尽量做到OCP原则，在我们头儿来看，OCP原则就是将业务逻辑变化之处写在配置文件中。

3.清晰性（架构优美），架构清晰，流程清晰，简单即是美，简单的问题，我们就不要把问题搞的太复杂，为了解决问题就不要把他演变成为了彰显自己的能力，过度设计就是这么一个例子。清晰性最好的解释就是，你的解决方案能够在评审会议上让大家欣然明白并接受。

4.可用性（用户体验性），如果不是GUI设计，那么我们这里主要强调的是性能的优化，性能的提升，包括战略上的，也有战术上的，战略上主要是在软件开发过程上的控制，包括了需求、设计、实现和测试的各个阶段的一些原则。战术部分则包含了Java各个技术环节的经验，包括I/O编程、内存对象、类加载的控制、如何使用Java对象、算法和数据结构、本地方法、Swing模型和渲染器、Swing线程模型以及部署等各方面的技术和方法，这些技术和方法可以帮助你极大提高Java应用程序的性能。



上面说的太笼统了，本来我是针对某一个任务来说的，但是思维发散到尽量使用所有的重构实践了，可能是平时设计方法和类的习惯，能够一般化，就尽量不要搞特殊。呵呵，不过有一句话时刻提醒着我，不要为了优化而优化，最后性能的优化，如果不是你的应用出现太大的性能问题时，你应该第一时间保持你的应用能够正确完成业务逻辑，减少BUG数量，然后再是可扩展性，可复用性，最后才是性能上的完美，还有架构和代码各个细节的完美。