一、总括
近期终于做完了机房收费系统，看似使一种解脱，实质更是一种折磨。如果说开始着手做系统时，是将一张白纸涂满，那么做完整个系统进行反思，就是将白纸上凌乱的画面整理的清晰美观。将一张白纸画满很容易，将其布局整理的一目了然，想来才是最费神的一件事情，也只有从反思中超脱出来方可以解脱。
二、文档
在重构机房收费系统的时候，文档只是象征性的书写完毕。所谓的象征性，就是按照软件工程文档的范本，照猫画虎的一条一条将内容填在上面。看似这样还过得去，自己还算满意。自己在此基础上还对每个文档阅读的人群和作用进行了总结，觉得这样以后写文档可以会知道怎么写，或是可以给自己提供点思路。在将系统完结之后发现，文档自己从来没有参考过，当然这绝对不是做可怕的，可怕的是将系统完成之后，自己竟然都不可以将文档调理清晰的补充完整。
在这过程中遇到的问题：
1、不知道文档中该加什么图，该将此图放在什么地方；
2、生搬硬套，没有认真思考。
3、也是最重要的一点，就是没能领会写文档的目的，以及每个文档的作用和阅读的人群。
剖析问题的原因：
问题1：在看软件工程视频的时候没有进行具体的归纳和总结，知识点零散，没有系统性，没有对每种图进行分析归纳、总结和对比，因此导致不知道文档中该加什么图，这个图该画的是那部分内容，知道画什么内容也就相应的知道该放在什么位置。
问题2：也是我学习中非常致命的一个问题，如果说刚开始学习一个新东西照猫画虎是必由之路，那么接下来我们要做的就是领会照猫画虎中的精神，生搬硬套，死抠字眼，只能是让自己深陷泥潭，越陷越深，如对于详细设计说明书中的“输入项”、“输出项“不可抑制的陷入其中，其实经过提点和自己的思考，才恍然大悟，自己在对每一功能进行描述的时候已经包含了输入项和输出项，在后面何必又要苦苦纠结他们到底要如何抽象出来具体的描述呢。
问题3：也是我觉得我不能写好文档的最主要原因：虽然表面看似知道文档是什么，作用怎样，但是还是没有找住文档的本质，写出真正的文档来，只有真正的领会精神也才不会出现问题2的情况，也才不会觉得自己写的文档很虚。
总结：
写文档要做的就是领会这个文档该给是看，写这个文档的目的何在、怎么让看文档的人看到自己想要的东西且看的清楚明白，自就会写出好的文档，也就不会拘泥于条条框框。当然，我想这也是需要经验的，先阶段我们不但要自己摸索还要去挖掘别人的经验，然后与自己的知识融合贯通，才是王道，因为自己的认知是有限的，大家的经验融合到一起才能更好的发挥作用。
三、UML图
刚开始画UML图的时候迷迷糊糊，觉得也没有别人说的那么难，这不是挺好画的吗？现在想来，当时只是会用Rose工具而已，而不是会画图。
开始画用例图的时候，想着界面，一个一个的往上画，结果这个用例图画完可是不简单，画了整整一个界面，密密麻麻，真是好不热闹。后来经人提点重新进行了分化，先对功能进行大的划分，然后再对每个功能进行具体的划分，这样画下来真是清楚明了多了。
紧接着问题还是出现来了，当然这还是上面遇到的老问题，由于前面在看UML视频的时候，没有进行很好的归纳总结，基础知识出现了很严重的问题，对于用例与用例、角色和用例、角色和角色之间应该有哪几种关系，这几种关系该什么时候用都没有认真的进行分析和对比，导致在此云里雾里，上面欠下的帐到此偿还，实属更加浪费时间啊。
当然有些曾经遇到的问题可能影响不太深刻想不起来，期待着以后可以有真正的项目让自己来分析画图，体会一下没有界面，自己分析需求画图时的不同心得。希望自己可以到达对的认识画图从简单→复杂→简单。
四、三层
刚开始接触三层，觉得他很什么，就像一块难啃的骨头，查了很多资料，大概理解了各层的职责，可就是觉得纠结，觉得欠点什么。后来敲了一个登陆的小例子，通过断电调试感觉好点了，好像明白了大概明白是怎么回事。后来开始着手敲代码，敲了几条线后，发现B层与D层对应有点别扭，感觉很是不合理，又简单的对B层进行了一下整合，感觉好点。
前几天头脑风暴，我们谈到了对于B层该怎么划分，具体我们说来可以按照需求分类、也可以按照对象分类、当然还有对象加需求同时分类，我们认为这是不伦不类类。对于需求来划分，那么机房收费系统可谓一个界面一个功能，B层划分出的类是很多的，但是这样虽然多但是很清晰。对于用对象来划分，是差不多与D层对应，这样来说B层类的划分是会少很多的，清晰度也还可以。还有就是需求加对象同时对B层进行划分，即逻辑性比较小的功能采用对象划分，逻辑性强的采用需求划分，我不知道这样写是否合理，望大家给出指点。对于我对B层的划分还存在很多问题，有待继续思考。
在用三层的时候我还出现了一个致命的错误，在U层和D层中用到了逻辑判断。在不知不觉中来时忘记了每一层的本质，还是将其混淆，好待幡然醒悟，还为时不晚。
我对用完三层的感受是总体来说是减少了耦合，提高了代码的复用。对于D层只是进行数据库的访问。对于实体是起到桥梁的作用，这里还是想说一句，既然实体是起到桥梁的作用，可不要在写方法进行参数传递的时候是用到的实体层，如果你有的没有用，你可能就已经忘了实体层所起到的作用。对于B层就是进行业务逻辑判断，而不要将他只是进行需有的参数返回，那样就没有必要用到B层，直接U层调用D层或是只写一层岂不是更简单。对于U层就是跟窗体打交道。
五、设计模式
我目前用到了配置文件加反射，具体真正的好处还没有体会出来，领悟的好处是减少了耦合，可以方便的更换数据库。更深更详细的剖析还有待思考和应用。这应该是体现了面向对象的抽象性。
我还用到了外观模式，我将其用在了登陆窗体。我通过应用对其体会的好处是对于一件复杂的事情，给予方法进行封装，然后统一的去调用此接口，这用给予下一层引用的人极大的方便。这应该是体现了面向对象的封装性。
其他的设计模式还没有加，还在思考中，希望下面应用的越来越好。
六、代码编写
在代码编写这里，我是严格按照命名规范出发，倒是没有什么问题。
我感觉我在代码编写上出现的最大问题是没有遵循代码的重用性，好多地方都可以提炼出公共的方法，却懒得去提炼，看似此时复制很快捷，其实很占用时间，在接下来的几天望要解决此问题。
在看别人写的机房收费系统的总结中对于D层，崔师哥提到了觉得D层有好多重用的问题，提到解决办法是泛型。自己还没有去尝试和了解。
还有我在断点调试的时候在IDAL接口层处设置了断点，但逐语句调试时却不能通过，后来明白是因为用到的是反射，所以此处不用过，但还是有点晕，有待好好想想。
还有将D层的Debug保存到U层的Debug下面这都是需要注意的问题。其他遇到的都是具体细节，就不再赘述。其他自己认为注意的还没有想到。
七、SQLHelper
这个是来处理事务、存储过程等复杂的操作，可以提高代码的复用，可以利于以后系统升级。
刚开始没有添加SQLHelper，就利用纯三层写了一遍机房收费系统。然后开始提炼访问数据库的方法，将其修改到以前的版本上，刚开始觉得知道SQLHelper怎么写就可以了，在几个类中应用了以后其他的地方就不想做修改，我就向同桌抱怨不想修改，他劝说还是全部修改，说好领会其精神，我当时想我都知道怎么写了，还没有领会精神啊，但是我还是全部进行了修改。当全部修改完成我才发现现在这个版本比以前版本D层的类中简介了很多，看着也非常舒服，也真正体会到了其SQLHelper的好处，不只是说到的，而是实实在在的通过去做感悟出来的，其心情和理解自然也是完全不一样的。
我在网上查资料的时候，查询是否应该将SQLHelper放到D层，有人说这只是一个架构不应该放到D层，还给了个形象的比喻“枪只有在军人手上才是战争机器...一个组件的作用不在它可以做什么而在它正在做什么... “；有人说将应该其放到D层，原因是只要与数据库有关的都算。我觉得两种都有道理，不过该认可哪一种，真是云里雾里，此处也是问号啊！
八、打包发布
开始打包时，用到的是打包工厂，放在没有VS2010的环境下不可运行，查资料才知这是需要将.Net FrameWork 也一同打包过去，然后才可以正常运行。后来又用了VS2010自带的打包工具Visual Studio Installer打包了一次，还有一种是Install ShieldLE没有进行应用，因为还得下载只是查了一下资料，大概看了一下怎么弄。
这里面还有Debug和Release的两种编译，前者是主要用于调试用，后者适合发布打包，因为后者会对程序的幅度进行优化。
九、 数据库设计
那天头脑风暴，讨论了数据库这块。对于数据库怎么建这个问题上，提出将卡单独做成一张表，因为卡号它不属于学生本身的属性，当时没有对这个问题进行过考虑，其实也就是没有意识到在建数据库时，对于这个问题是不满足数据库的三范式。
在这里还应用了存储过程和触发器，说是用也不如说是简单的认识了一下，就具体来说该什么时候用，及其用了以后会有什么弊端等都有待好好思考和总结。
十、 数据备份
前几天关机的时候，不知道是不是不小心将便签也给关闭了，结果导致在便签中记录的在做机房收费系统中遇到的问题，解决办法，有待思考和总结的问题全部丢失，尝试了各种数据回复也无济于事，想想就难过，宁可代码丢了，这些记录也不能丢啊，怎么说这也是我小小的经验，从这我也不得不真正的提高认识，重要的东西要进行备份，及时同步到云端，不要丢了才追悔莫及。还有不要简单的以为贪图方便，自认为便笺小巧方便，启动快捷，结果吃了大亏啊。
十一、继续深入
对于自己遇到的这些问题必须进行系统的总结和归纳，找出问题的答案。对于后续的合作开发也是期待中。
十二、提醒
做完这个项目让我领会最深的就是两点：其一，对于学习的知识应该做好总结归纳，编织知识网，这样才不会用到的时候混乱不堪；其二，学习一个知识，要注意找住要领，就像写文章一样，要围绕主题，不然写的再好，也是枉然。