养成编程好习惯

　　机房收费系统第二版做完将近二十多天了，这几天开始挨个检查验收，昨天终于轮到我了，本身第二版自我感觉就不怎么样，存在很多的不合理性，不过昨天给我找出来的这几个问题反倒不是我之前所关心的问题，而是作为一个程序员最根本也是最重要的东西。

　　1.注释过少和不规范化

　　刚开始做的时候还比较有精力，基本上在每个方法都写注释，参数返回值都写的比较清楚，随着到后面的进行，类越来越多，方法也随之

增加，总感觉到写注释是一件累人的活儿，而且参数返回值什么的用自己的名称就已经表达的很清楚，所以就节省了这一步。

　　正确写注释的方式其实微软已经为你提供了，你所要做的只是在键盘上敲击三下注释键后填充就可以了。

　　如上图这样注释有很多的好处，一是便于自己和用户阅读，二是便于追踪问题，三是能直接生成文档。

　　很多人不写注释主要原因就是为了节省时间，但是相比程序员的打字速度写个小小的注释是不需要多长时间的，而是主观上想不想写，

想不想养成一个良好的习惯，让别人拿到你的代码是在赏心悦目，而不是紧锁眉头骂你写的烂代码；说小了这是在未别人为自己以后看代码

提供方便，说大了这是在为中国软件业得发展添砖加瓦，为自己将来很好的发展埋下伏笔。

　　2.画UML图的艺术

　　先来看第一张图：

　　再来看第二张图：

　　两张图所要表达的意思是完全相同的，但他们里面包含的讯息却是不同的，第二张图看起来貌似更简洁一些，它将业务的主线一目了然的

展现开发人员的眼前，也从另一个侧面说明了画图人心里非常清楚业务的主线和副线，思路非常明确；让其他看图的人也能随着架构者的思路

向下发展，从图里读出架构者的用意，省去了很多不必要的时间和语言交流。

　　第二张图没有画依赖实体类(Entity)的连线，并不是说这条线不存在，而是这条线在心中，这里面包含一个哲学----“有既无，无既有”，

放在本例中就是说：既然下面每个包(Factory包下面)都和Entity这个类存在依赖关系，那么这就不需要展现出来了，放在心中即可，画出来反

倒添乱；但是如果其中一个包(如CashStrategy)和Entity没有任何关系，则需要把其他包和Entity包之间的依赖关系画出来，来表明两个包之

间(CashStrategy和Entity)是没有关系的。

举个简单的例子，比如现在扩招之风吹遍祖国大地，等将来有一天人人都是大学生、研究生，那么在填写简历的时候就没必要写自己是大

学生或研究生了；相反，如果你不是，那你还真得在简历中写明自己不是大学生。

　　3.写程序要严格按照图中引用关系

　　图既然是按照世界统一的UML来画的，那么程序中要严格按照图来引用各程序集（包）之间的关系，因为这就是国际认可的，大家都以这

个为标准，切不可为了一些其他原因乱引用关系。在做收费系统的过程中，用到反射时出现了一个“未能加载或找到程序集Dal····”的

错误，上网一搜看大家的解决方案是直接让UI层引用Dal层，很多网友还在博客中记录下了这个过程，但这里要问的是：如果UI层直接Dal层，

那Bll层、工厂、接口等这几层要它还干什么？这又不是返回原始社会了么，耦合性又加大了。综上所述，引用关系很重要，切不可乱用！

　　收获很多，需要一言一行中去消化。