项目验收

       开始评教系统已经一个多月了,做多做少的来了次阶段性的验收,总体结果是值得庆幸的,因为整个系统从界面一直到数据库的整体评价也就四个字--"一无是处",值得庆幸的是还有如此巨大的进步空间啊 .下面来谈谈具体哪些地方需要注意.

       1.数据的一致性

       背景:评教系统需要用到基础系统数据库中有关学生,教师,课程等一系列的信息,我们做评教的人员为了某些原因将需要的那部分数据导入到了评教系统的数据库中,而这时候本应该早就引起重视的一个问题就凸显出来了,如何保持数据的一致性.

        问题的焦点不在于导表,而在于如何维持数据的一致性,当时其实也考虑到了基础数据有增加和删除时候的数据变动,添加了保持一直的手段,但现在想想自己当时的想法有点幼稚,自欺欺人的感觉.

         举例来说,比如基础数据库添加学生上课信息,或者删除学生上课的信息,我们都有想对应的策略保持数据在两个数据库中的一致性,可是如果学生既没有添加课程也没有删除课程信息,却将上课的信息做过修改,比如上计算机的课程,修改成了上英语,这种数据库不是增删的情况我们并没有应对策略,这并不是我们没想到,而是曾经了解过基础系统并没有这样的功能,不对学生的上课信息做更改,如果授课错误只能是删除了然后重新添加,也就是基础那边数据库只会出现添加或者删除的动作,于是我们依赖与基础数据库的能做出的动作进行了设计.

       这样的设计或许就导致了我们的系统必须每次都需要跟着基础系统的变动而变动,依赖性太强了.本应该逻辑上是独立的系统,弄成了基础系统的附属系统了.想到这里,个人感觉做系统需求的来源应该是"可能",可能出现的情况就应该想办法处理掉,这样系统才有更大的适应性.而不应该针对需求就出现了两种可能,我们就处理两种可能,而另外的很可能出现但并没有出现的情况,我们就自欺欺人的认为不会出现,所以不去理会了.

       解决方案:其实关于数据一致性的问题最好的解决方案就是用的时候直接去基础数据库读取而不是导表.当然如果迫不得已必须导表,那么数据的一致性问题就成了一个谈不完的话题了.

     

      2.数据库备用字段

      背景:  关于备用字段个人感觉情节很深,记得八期师兄鼓励过使用备用字段,而且后期还经历了好几个系统,机房管理系统,考试系统,基础系统等都使用了备用字段.

       这次因为备用字段挨训,个人感觉焦点其实不应该在备用字段是否使用,更应该关注的是在备用字段使用的时候有没有认真的思考和衡量使用备用字段真的合适吗?能带来多少好处?真的好处能覆盖掉带来的所有弊端吗?   如果很认真的考虑过,衡量过,最后决定了是否使用备用字段,哪怕是错误的也只能说明现在的阅历,技术等方面还不达标,而不是思想性的问题.技术,阅历可以增加,思想问题就难办了.老师不会因为技术问题发飙,但却会因为思想问题暴跳如雷.也就是这次备用字段事件.

       当初设计的时候既然叫它备用字段自然而然的作用就是以防万一,以备不时之需,防患于未然.等到时候需要的时候，就不需要在表中增加新的字段了，而且这样做的话，一个表的数据应该会被存储在相邻的物理空间中，这对于性能也是有好处的。并且这样做当需要用到备用字段的时候对实体类内部不用做代码的修改.还据说有人咨询过DBA如果使用add columns动态添加字段会改变原先的数据库存储结构，造成数据移动，移动需要时间，而且会移动到其他数据块。总之意思是add column会影响数据库性能，造成一些不可预知的错误。

       基于上诉一些原因都选择了使用备用字段,其实开发的时候或许考虑的都不够深入,而且人们也习惯于去思考对自己有益的事务,很习惯的忽略掉一些对自己不利的东西,觉得只要能解决自己的问题,其余一些不利的地方都是细枝末节的不影响大局.

        备用字段肯定很对弊端,首先增加大量备用字段，必定会浪费很多空间，尽管其中可能都没有具体的数据，但是仅仅是空字段也会占据一定的空间的。其次由于命名的特点，如果没有完善的文档管理流程，用不了多久就没有人能够说清楚到底哪个字段代表的是什么意义了。就算有文档管理，这些管理工作也会比较麻烦，还有可能会出现冲突的情况。还有就是增加了这些备用字段就真的会够用吗？

        解决方案：其实上面的这种设计方式就是一种“过度设计”，我们应该做的就是“按需设计”，在经过详细有效的分析之后，在数据表中只放置必要的字段，而不要留出大量的备用字段。当需要增加相关的信息的时候，就要具体情况具体分析：如果数量很少，而且信息的性质与原表密切相关，那么就可以直接在原表上增加字段，并将相关的数据更新进去。如果数量较大，或者并非是原表对象至关重要的属性，那么就可以动态添加一个表，然后通过键值连接起来。

        3.界面设计的焦点

        这是设计理念,设计思想的问题,试想一下,给客户开发一个系统,结果只有真正的开发人员会用,这将导致什么样的结果,人家不会用,当然就不用了呗,人家是出钱的人有权利告诉你我不用你的软件.

         如何让客户觉得你的软件简单可用呢?答案很简单,将界面做的简单了就可以了,也就是界面设计要有焦点,当用户第一眼看到界面的时候如果界面上只有一个 按钮,他自然知道肯定是要点,如果是两个按钮,就需要思考这按钮是干嘛的,如果再加上很多的下拉框,还需要思考按钮和下拉框,下拉框和下拉框等关系,这时候客户思考的越多说明你的软件可用性越差,最好是一眼就知道应该干嘛.当然现在还达不到百度,google一个输入框解决所有问题,不过我们要有这些意识,然后去提高.

         4.历史是用来被尊重的

          历史就是历史,不能被改变,更不应该被改变,只有历史的准确性和原始性才最有其价值,我们的历史数据同样如此,保持其原始性和真实性,当我们需要研究的时候通过这些数据得出的结论有意义,有价值.

          我们做评教的时候当评教工作结束的时候,我们将此次评教的数据就像垃圾一样丢掉历史库中去了,好像是对历史数据的不尊重哈.事实也是如此,还真是不怎么尊重,所以被老师教训了一顿,历史是应该用来尊重的.数据库数据用完了,自然成了历史,而不是我们说它是历史它最终才成为历史的.

         解决方案:每次评教开始的时候动态建表,当评教结束以后原来的数据自然而然的成为了历史.建立好索引,让历史同样的有其价值.

         小结:

         其实这次验收问题还很多,老师说了也很多,只是找出了几个典型的来说了说.其实说的这些都不重要,因为当别人告诉你的时候你下次很可能就注意这问题,重要的却是,为什么老师想到了这些,而我们却想不到这些?

         记得当时验收的时候,每当老师说的时候总会有人习惯性的狡辩,会说出自己认为的,自己感觉的.老师说这是坚定的维护着自己的错误,这或许是我们进步慢学习效果不好的最根本的原因吧.不论什么事情,我们习惯性的狡辩,习惯性的认为我们做的就是对的,不去改变,不去接受,不去进步.我们害怕改变,因为我们感觉我们控制不住变化,所以我们不喜欢变化的,希望一切都是死的,备用字段的使用是最好的体现,我们害怕出现未知的变动,所以我们想出来备用字段,将所有的变动自动的给套上死的模式.就像抓鱼,我们希望所有鱼都是不动的,动的鱼我们很可能控制不住,抓不住,人们最怕的也是脱离了掌控的事情,这些时候往往会给人带来恐惧.

        总体来说还是庆幸的,我们都还在努力的改变着自己.