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

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

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

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

        现在对师父保强的那句话还是蛮有体会的&＃xff1a;难者不会&＃xff0c;会者不难。

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

1&＃xff0c;深刻体会&＃xff1a;学习是个过程&＃xff1b;不&＃xff0c;学习是个重复的过程&＃xff1b;也不&＃xff0c;学习是个重复&＃43;重新认识的过程&＃xff1a;

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

2&＃xff0c;每做一个项目&＃xff08;一件事情&＃xff09;都要有所提高&＃xff0c;如果只是重复以前会的东西&＃xff0c;没有提高&＃61;白学&＃61;没意义的学习

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

他提出了一系列的问题&＃xff0c;让我几乎崩溃

——&＃xff08;1&＃xff09;代码、数据库的命名有没有按命名规范&＃xff1f;

&＃xff08;2&＃xff09;代码注释全吗&＃xff1f;每个类的注释、每个方法的注释、每个变量的注释、每个语句块的注释、每个语句块的每一行注释&＃xff08;例如&＃xff1a;If...Else...End If     if 后的语句代表什么&＃xff0c;语句块代表什么&＃xff1b;Else后的语句代表什么&＃xff1f;语句块又代表什么&＃xff1f;&＃xff09;

<1>

&＃xff08;注&＃xff1a;几乎每条语句都要有明确的注释&＃xff1a;如果返回值是Boolean类型&＃xff0c;True代表什么&＃xff0c;False代表什么&＃xff1b;如果返回值是Integer类型&＃xff0c;不同范围的值分别代表什么…..&＃xff09;

<2>

类和方法的注释使用XML注释&＃xff08;我叫它“三撇注释”&＃xff09;

例如&＃xff1a;

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

<3>自己创建文件注释

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

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

&＃xff08;3&＃xff09;UML图中的解释

<1>以BLL包CardBLL&＃xff08;卡信息类&＃xff09;的IsCardIDExist&＃xff08;判断卡号是否存在为例&＃xff09;

&＃xff08;注&＃xff1a;如果在EA中将方法的注释&＃xff08;功能、参数、返回值&＃xff09;标注的很清楚的话&＃xff0c;EA将其类图导成代码时就会自动加上XML注释&＃xff09;

&＃xff08;4&＃xff09;文档规范

<1>内容是不是丰富&＃xff1f;&＃xff1f;&＃xff08;假如你是架构师&＃xff0c;你的文档给别人&＃xff0c;他们能不能找文档敲出代码。&＃xff08;当然&＃xff0c;我的文档丰富度还是拿捏不准&＃xff0c;但是我师父说了以后做一次架构师就知道了&＃xff0c;我信了&＃xff09;&＃xff09;——注意&＃xff1a;丰富不是累赘&＃xff01;&＃xff01;&＃xff01;

<2>

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

例如&＃xff1a;需求分析说明书&＃xff08;给客户看&＃xff0c;要简单易懂&＃xff09;——用例图

概要设计&＃xff08;给经理看&＃xff0c;全局把控&＃xff09;——包图、类图

详细设计&＃xff08;程序员看、详细到看图写码的程度&＃xff09;——顺序图、有复杂逻辑的活动图

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

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

用例图&＃xff1a;每个用例的解释&＃xff0c;解释清这个用例的作用&＃xff0c;是完成的什么功能

&＃xff08;例如&＃xff1a;

说明&＃xff1a;Recharge&＃xff1a;学生充值&＃xff1b;操作员输入卡号、金额&＃xff0c;给学生卡内充值&＃xff09;

包图&＃xff1a;

说明&＃xff1a;此系统采用三层架构&＃43;抽象工厂&＃43;反射&＃43;配置文件为总体架构。

UI层&＃xff1a;用户界面层&＃xff1b;与用户打交道&＃xff0c;负责数据的输入、输出。

BLL层&＃xff1a;逻辑层&＃xff1b;为UI层提供一个统一的方法。

DAL层&＃xff1a;数据操作层&＃xff1b;操作数据库&＃xff08;增、删、改、差&＃xff09;

抽象工厂&＃43;反射&＃xff1a;使B层与D层成功解耦

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

抽象工厂&＃43;反射&＃43;配置文件的优点&＃xff1a;

顺序图&＃xff1a;

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

总结&＃xff1a;

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

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