机房收费系统.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注释、图的注释太少、文档格式有问题、图和文档对应的不正确、文档内容不丰富...),当然很多问题都是我曾经犯过的。如果当时保强师哥不让我去规范我的代码、文档、图的话,也许我根本给佳翰找不出问题,没准看到佳翰的东西,还会跟他达成错误的共鸣,这样的话对我们都不是好事,不但没有提高,并且很有可能跑偏。
保强师哥说的很对:我们将来不是要做码农的,现在就要以领导层的标准要求自己。