机房重构总结

        经过差不多两个月的学习，机房收费系统的重构工作圆满完成了。在这个过程中，遇到了很多的困难和疑惑，也正是因为这些挫折才让自己的收获颇丰啊。

      机房重构过程中所遇到的问题：

          一：无从下手

              一开始自己进行重构时，不知道如何下手，所以在这个阶段拖了老长时间也没有一点进展。后来，发现师姐的一篇关于重构的类图，顿时有了一点思路。遵循着自己所获得的“灵感”，自己先画了一些简单的类图，而且还“沾沾自喜”的感觉挺不错（现在翻开那篇博客，都感觉犹如是为了凑博客数量）；即使是这样，那篇博客我也会保留，因为虽然它没有什么技术含量，没有什么让人感觉有用的地方，但是也正是由于这样一个看似没有用的过程，才让自己慢慢的走进机房重构这个过程。从这个角度来看，它是一笔不小的财富啊。

         二：命名混乱

              由于刚画类图的时候，没有仔细考虑各个功能中所要用到的自定义函数，也就没有给类赋予方法。所以就造成自己在敲代码的时候，总是想起某个名字就写下来，规律性不强，不能给人一种严谨的态度；后来伙伴给我调代码的时候，给我指出这个问题，命名的混乱造成修改代码时，给人一种无从下手的感觉，需要花费很大精力，这与我们目前一直学习的知识相违背。趁这时候还没有敲很多，就开始了该名称，根据代码规范上的要求一步步修改，其最后的结果还是令人满意的，调代码的过程也就顺畅很多了。

        三：过程复杂

             刚开始的时候，没有什么思路，就一直一步步的去实现一个小功能，根据实现的功能进行建类，但是随着功能的不断增加，类库的量也开始庞大起来。有的时候，明明是一个相同的过程，却也需要重新建立一个过程，大大增加了过程的复杂性，是程序的可复用性大大降低。然后就又开始代码的修改，对各个类库进行了分类，主要的依据是按照对表的操作将类放到一起，这样大大减少了类库的数量。而且，在这几次的不断改代码的过程中，更加体会到了三层或七层的好处，因为改代码的时候，只需要将命名重新归置或修改就行，其他的一些代码都没必要动。这时才真正理解了耦合性低带来的好处。

        四：细节问题

             除了一些思想上的难题外，就是一些细节上的问题，其中大多数是某个功能的实现；比如说子窗体既要位于主窗体之上，同时还要在主窗体的控件之上；模板方法的使用等各种设计模式的加入等问题，这些也是锻炼自己最近一段时间的学习，巩固自己学过的知识，加深理解。还有一些文本框的输入限制，主要字节的显示等问题，都需要我们在学习的过程中认真仔细，稍不留神就可能犯下让你一直纠结的错误，所以技术上努力固然重要，同时还要注意细节问题。

        还有一个问题就是自己再画UML图的过程中，一直犯着这样一个错：比如画时序图时，不是从原来的类图中进行拖类，然后就可以调用其方法，使所有的图都关联起来，而是通过自己手写而成。其实画图已经有好长一段时间了，直到今天才发现这个错误，这是自己在学习上的一个重大的错误。虽然现在已经明白了，但是相对来说自己这次的学习是失败的，还需要自己再认真仔细一点。尤其是，不能盲目的赶进度，一定要根据实际情况，一步一步的走下去，一定要脚踏实地。

 

   总结：

      这次重构给了自己一个巨大的收获，通过对它的学习，让自己对近段时间来的学习进行了充分的实践学习，这个的意义是远远超过从课本上学到的单纯的知识所蕴含的的韵味。也只有通过实践，我们的收获才能满满的，我们也将会迈向成功的大门。