机房合作--11期验收有感
“完毕了机房合作。我们就算是一名合格的IT人士了”米老师如是说。
參与了11期的机房合作验收，师哥师姐从功能、UML图、文档、代码走查四个阶段做出了点评。以下谈谈这个过程我所总结的想法。
一、收获：
（一） 站在“用户”的角度来思考功能设计
1、Login界面输入错误到底该提示写什么？
之前我做的时候，我的第一感受“假设提示‘您的username或者password错误‘有点太不专业了”就像今天师姐所说，详细提示到username还是password。这样更加方便用户去进行改动。之后坤哥说了。提示“您的username或者password错误”则更加符合安全性，我想仁者见仁智者见智。真是山外有山，功能设计过程中的思维重新被打开。仿佛呼吸到了新奇的空气。
2、注冊卡和学生信息之间的顺序到底该怎么办？
绍然组和我之前重构设计的是一样的，将卡和学生信息都分开注冊，可是在注冊卡的时候须要勾选学生信息。假设没有学生信息，卡就不能注冊成功，对于设计人员来说，注冊卡的时候自然会先去注冊学生信息，然后对应在注冊卡的时候去勾选学生信息，可是用户会这样去做吗？注冊卡的时候会感觉为什么学生信息加入不上？系统有问题了吗？
这就要求我以后再设计程序过程中，不要全然从开发者的角度去设计程序，思维要开阔。
3、至少上机金额真的只该在上机时才体现吗？
举样例，至少上机金额设置3元。注冊卡时候注冊资金1元，即使卡注冊成功了。可是还是上不了机。试想，注冊卡的目的不是为了上机吗？为什么不把至少上机金额的限制同一时候提到注冊卡上呢？这样刚刚注冊的卡不就都能上机了吗？当时设计的时候还是被“至少上机金额”中“上机”两个字给限制了……
4、组合查询中符号下拉列表是否“=”、“<”、“>”都改设置呢？
老师一直都在强调“全心全意为人民服务”。为什么体如今详细功能上就这么难？选择人名的时候难道该选择“<”和“>”吗？听了这次验收才发现多么的肤浅。
近期也在和九期和十期师哥师姐做考评系统的需求，发现想要设计出好的功能，做需求要比写程序复杂多了，这部分我感觉除了经验之外，更重要的就像今天收获到的这一点，思维非常重要，思考时候站位相同重要。
（二）规范
尽管我不是我们合作组的组长，可是我想对于“UI规范、SVN规范、代码规范、数据库规范”等我还是非常有必要关注的，说不准下次某个项目我就是组长。
针对这次机房合作验收，我分别针对今天的系统总结例如以下：
1、UI规范
a.提示框位置要放在同一个坐标下
b.子窗口下除了右上角windows自带关闭button。系统要为每一个页面加上关闭button
c.文本框或者下拉列表要有默认数据。并且是真实数据。
d.提示框的图标首先要不一样，感叹号、问好、信息符号等用在不用场景，可是也不能乱用。今天的一组有两个界面。同一时候提交button，单击之后显示图片一个是感叹号，一个是信息提示符号“i”，非常明显的错误。
2、代码规范
Try catch语句的使用：
有一组在代码中用到了try catch 语句。可是只要系统有问题错误提示就出来了。提示界面都一样，不好，就像上面站在“用户”的角度来思考功能设计，考虑过用户看到这个界面的感受吗？在catch之后只须要写throw就ok了。expression就不要往上传了，我们在设计过程中为了方便调错能够有，可是上线公布了，就算了吧，或者详细的问题详细提示。就不要所有都用try catch了，通篇使用try catch也不是一个好的选择。
3、文档规范
软工学习时候，整个软件生命周期假设理清了，我想对于写和使用文档应该很收悉。慕夏师姐说了，“需求、开发、測试、维护”四大块就能够概括这个周期，简单明了，之前自己记忆这个过程一直都是混乱的……
a.写文档。要有文档封皮、名称、时间、版本号，细节要具体。
b.用例图的备注、说明要具体。
c.类图中要体现设计模式的运用，（能够在以后版本号中稍稍改动类图）。
（三）新发现
今天慕夏师姐验收过程中把电脑系统时间给改了。快进了一个小时，结果算钱的时候就直接消费了一个小时的金额，这简直就是一个天大的BUG,假设这样能够的话， 网吧里的客人趁着管理员不在偷偷改了控制端的系统时间，不就相当于请全部人白上网吗？试想他不修改详细时间。而是修改日期，往前该一天，网吧就亏一天的钱。有一次这种事情，老板就赔大发了。
所以，实时进行算钱，实时更新卡表剩余金额。非常有必要！！。
通过今天的验收，一些零碎上的点的总结。如上所述，最最重要的。让我的眼界开阔了，非常好。
