机房收费系统.Net个人版总结

          机房收费系统.Net版到前两天为止才算是彻底完工了。从寒假开始的初步文档+图设计，以及之后的代码实现,到三月中旬开始的文档规范、图规范、代码规范。这个生命周期真是一个长啊。给自己总结了一下：本次机房收费系统的难点——初期的设计（代码前的UML图+文档）；本次机房收费系统的麻烦点——后期的规范（代码后的UML图+文档+代码的修改（逐步向规范靠拢））

 

         刚开始设计架构，画图时一点头绪都没有。那时候刚刚学习完三层架构，敲了几个三层架构的例子，似懂非懂的根本无法下手，更困难的是图中要明显体现出三层架构（刚开始做只是按三层架构，之后加的设计模式）

 

     在师父青峰的点播下，我对三层架构逐步有了深的感觉，系统做起来更加顺手起来。

 

        现在对师父保强的那句话还是蛮有体会的：难者不会，会者不难。

        回想刚开始此系统时的毫无头绪、心急交迫，现在终于释放了，原来每个坎都不是坎，总觉得是座山，翻过后发现原来仅一块绊脚石而已，我拾到金子了。

 

1，深刻体会：学习是个过程；不，学习是个重复的过程；也不，学习是个重复+重新认识的过程：

 

（注：1，去年暑假学习数据库时：主外键、存储过程、事务、视图。当时觉得理解了，但是没有实际应用，还是认为很神秘；2，前几个月学习了那么多设计模式；3，三范式早就了解过，没用过；4，做这一遍机房收费系统时，刚认识，很快就用到了（Why？原因很简单：一个实际操作>>>>>>>上万条理论））

 

2，每做一个项目（一件事情）都要有所提高，如果只是重复以前会的东西，没有提高=白学=没意义的学习

曾经怀揣着如此愉悦的心情找保强师哥验收。

他提出了一系列的问题，让我几乎崩溃

——（1）代码、数据库的命名有没有按命名规范？

（2）代码注释全吗？每个类的注释、每个方法的注释、每个变量的注释、每个语句块的注释、每个语句块的每一行注释（例如：If...Else...End If     if 后的语句代表什么，语句块代表什么；Else后的语句代表什么？语句块又代表什么？）

<1>

（注：几乎每条语句都要有明确的注释：如果返回值是Boolean类型，True代表什么，False代表什么；如果返回值是Integer类型，不同范围的值分别代表什么…..）

 

<2>

类和方法的注释使用XML注释（我叫它“三撇注释”）

例如：

（注：一个方法1，要注明它的功能；2，要注明参数的含义及用到的属性，目的是合作开发时，上层调用下层方法时知道如何传参；3，要注明此函数的返回值含义，返回的值代表什么含义。例如：返回一个DataTable类型的值，DataTable中包含的是什么信息。如果不注明此函数改返回什么值的话，程序员是无法实现此功能的，因为此函数的编写是毫无目的的。只给程序员一个函数名，就让其写出代码，是不可能的，因为程序员不了解架构师的想法）

 

<3>自己创建文件注释

写在文件开头。每个类库文件开头都创建文件注释。

（注：我目前对此类型注释的理解：1，合作开发时，每几个人负责一层，每个人负责不同的模块。将自己负责的每个部分都创建此文件注释的话，如果将来哪一部分出了问题可以很方便的找到它的负责人。2，解释此文件的大致内容（例如：我没创建一个类，在类文件开头创建文件注释，标注它的说明）

 

（3）UML图中的解释

<1>以BLL包CardBLL（卡信息类）的IsCardIDExist（判断卡号是否存在为例）

 

（注：如果在EA中将方法的注释（功能、参数、返回值）标注的很清楚的话，EA将其类图导成代码时就会自动加上XML注释）

 

（4）文档规范

<1>内容是不是丰富？？（假如你是架构师，你的文档给别人，他们能不能找文档敲出代码。（当然，我的文档丰富度还是拿捏不准，但是我师父说了以后做一次架构师就知道了，我信了））——注意：丰富不是累赘！！！

<2>

不同的文档所需要的UML图。

例如：需求分析说明书（给客户看，要简单易懂）——用例图

概要设计（给经理看，全局把控）——包图、类图

详细设计（程序员看、详细到看图写码的程度）——顺序图、有复杂逻辑的活动图

 

<3>每个图的解释是否详细

每张图后面都要有相应的解释，至于什么图解释什么解释到什么程度，我现在还拿捏不准，所以不敢瞎说，大家都在学习进步中吧。

用例图：每个用例的解释，解释清这个用例的作用，是完成的什么功能

（例如：

说明：Recharge：学生充值；操作员输入卡号、金额，给学生卡内充值）

 

包图：

说明：此系统采用三层架构+抽象工厂+反射+配置文件为总体架构。

UI层：用户界面层；与用户打交道，负责数据的输入、输出。

BLL层：逻辑层；为UI层提供一个统一的方法。

DAL层：数据操作层；操作数据库（增、删、改、差）

抽象工厂+反射：使B层与D层成功解耦

 

三层架构的优点：1，大大降低了层与层之间的依赖，即降低了层之间的耦合；2，利于各层逻辑的复用，即增强了复用性；3，开发人员可以只关注整个系统的某一层，即有利于合作开发

抽象工厂+反射+配置文件的优点：

 

顺序图：

每个顺序图下都要对此解释说明，但是对此，我也拿捏不好度

 

总结：

总的来说此次收获还蛮大的，不论是技术上的提高，更是有思想上的升华。让我给自己准确定位。我那时候还抱怨保强师哥让我改的东西太多，别人都没改。但是，在最后一次验收时（碰见佳翰的师父给佳翰第一次验收），保强师哥让我给佳翰的代码、文档、UML图提建议，我找出很多问题（比如：命名不规范、代码注释太少、没有XML注释、图的注释太少、文档格式有问题、图和文档对应的不正确、文档内容不丰富...），当然很多问题都是我曾经犯过的。如果当时保强师哥不让我去规范我的代码、文档、图的话，也许我根本给佳翰找不出问题，没准看到佳翰的东西，还会跟他达成错误的共鸣，这样的话对我们都不是好事，不但没有提高，并且很有可能跑偏。

          保强师哥说的很对：我们将来不是要做码农的，现在就要以领导层的标准要求自己。