好马也要吃回头草

经过上次机房收费系统的验收之后，在组长的建议和要求下，我重构了个人版的机房收费系统。

一、设计方面的重构

在验收之前，个人版的机房收费系统采用是纯三层的方法（没有加如任何的设计模式），这样的唯一的好处就是很好的理解了什么是三层，很快的熟悉了三层的用法。虽然在合作版中我们加入了好几个设计模式，但我负责的是外观和BLL层，这样以来我对外观是很熟悉了。但是对于其他不是我负责的设计模式，虽然在合作完成之后也看了看相应的代码，但这和自己亲自动手相差的很远。

虽说学习过《大话设计模式》，上面也有例子，但是它给人的感觉还是有些陌生，原因大概是自己对他给出的例子没有多少“感觉”吧。但是机房收费不一样，在这之前已经用VB实现了一次，对这个系统的需求、功能等都有了很深的了解，如果用这个例子来“实例化”设计模式，对设计模式的理解会很深刻。

所以在这次重构的过程中，我加入了抽象工厂+反射+配置文件、单例等设计模式。还别说，在代码完成之后的调错阶段确实出现了很多的问题，第一个问题就是登录不上去。这肯定是配置文件没有写好的原因，经过一番的查找、修改终于是可以登录了。对配置文件的认识和理解就是在排错、查找过程中解决的。

二、代码的重构

在开发个人版过程中，当时考虑的不是很全面。当时只是单纯的将需求实现了，而没有做其他太多的考虑，其中重要的一点是对异常的处理。当时根本就没有考虑那么多。

在验收的过程中，7期学姐问了我一句：没有异常处理啊？也是，前面接受验收的人大部分都考虑了这一点，并且得以实现，而我却没有，也许这也是组长让我重构的原因之一吧。在重构的过程中，对于异常处理这一方面，曹健新给了我很大的帮助，他给我和正权认真的讲过一遍，然后他又在博客中再次细致的讲解了一遍，这给予了很大的帮助，通过亲自做了一个小例子，结合那几篇博文，给我一种豁然开朗的感觉。

还有就是对注释的重构了。之前是自己眼光太狭隘了。认为注释这个东西只要自己可以看懂就可以了，能少写几个字就尽量的少写。自己能懂就行。有过合作经验的人知道，这种做法是不对的。清晰全面的注释有助于开发人员之间的交流，减少错误理解的机率，再往远处说，这款软件将来在维护的时候，注释就显得尤为重要了，维护人员根据代码注释可以很快的理解每个函数的功能，快速的维护程序。

三、UML图和文档的重构

重构之前的文档大部分是第一次尝试写文档的第二版本，甚至哪个文档该放些什么都不知道。在验收过程中，7期的各位“大神”在给其他人验收的过程中讲解了各种文档中应该放什么图，这才对各个文档有了重新的认识。

在验收的过程中，发现我的用例图中居然和窗体的名称是一样的。在这次重构中，又返回头看了一遍UML，然后就是在把上次没有画的其他图都画了一遍，虽说画的不是太好，但至少我实践了，感觉还不错。

通过这次重构确实收获了不少，填了很多的漏洞，现在感觉很踏实，至少以后在遇到不会惊慌失措，因为我曾经实践过。