机房收费系统验收后的那些事！

       

      昨天师父验收系统，收获很多。自己的系统错误不多，但缺乏灵性，有很多地方欠考虑。

 

思考如下：

1.      在验收上机部分时师父用阅读器来测试我们的是否当用户将卡号输进去之后它就自动上机，而不是用户手动按enter键进入，需要完善的地方是编写一个响应enter键的方法来让用户自动上机。

2.      组合查询部分：组合关系的使用是需要一定条件的，你的系统应该引导客户去使用而不是让客户自己去琢磨。如只有至少两行条件不为空时才可以使用一个组合关系，三行全不为空时才可以使用第二个组合关系，这需要一个判断。

3.      上机人数的变动性。如何显示上机人数纯属技术问题，但重点是要考虑上机人数变化的好几种情况，比如在主窗体通过下机按钮下机；上机状态查询菜单中的上机管理包括的两种情况：所有学生下机和强制选中学生下机。在主界面中上机人数的变化应考虑这三种下机情况。

4.      代码的复用率：还是下机那部分，不论是正常下机抑或强制下机，下机方式虽有所不同，但代码大致相似，这样的话，把下机部分抽象成一个方法，定义在模块中，每次使用时调用此方法即可，提高了代码的复用率，还如导出excel这个功能也可以抽象为一个方法放到模块中，能应用于所有窗体。

5.      结账部分：首先明确结账是给老板看的。老板平时肯定很忙，怎样制作一个结账报表让老板一看就知道系统的运营状况，业绩情况是我们制作表单的出发点。一天中可多次结账，这样日结账单中会有多条同一天的记录。周结账单是一个时间段内每天结账的情况的汇总，它也可有多条记录，只不过每条记录的日期不同。

6.      注释部分：作注释是为了让别人看懂你的代码，怎样让已经做了一半的系统交给别人让别人轻松接手你的系统是做好注释的一个标准。这让我想到下一阶段的学习内容，软工视频看完后就应该对自己做的机房系统写文档了。写文档给谁看，目的是什么，不就是让开发系统的人做的顺利，应用系统的人用的舒服吗？代码中的注释和文档同样重要，它可以让编写代码的人对自己的系统有宏观的把控和微观的查看。秉着对自己负责，对他们负责的态度，我们在编写系统过程中都应该重视注释的必要性！

7.      还有抓取异常现象问题，往后肯定会更多涉及到，这以后再探讨。

 

我一直把这个系统当做一个任务去完成，从没有想它是一个有着生命和灵性的系统。最重要的部分当属算钱的部分了，怎样合理的设计既满足用户的上机需求，又考虑到用户使用时遇到的各种情况。让用户感受到系统的人性化设计不仅仅是算钱部分要考虑的，所有的功能都应把这当做标准！