学校教务系统开发学习

     一个假期都在和教务系统在一起。这其中的滋味就像是五味瓶。咸/酸／苦／辣／甜为什么这么说呢，听我一一道来
    咸的开始：第一次接触教务系统，我是负责教师工作量计算这一部分。一旦涉及到计算必不可少的就是逻辑上很复杂的数学运算之类的东西。虽然我们还是在校的学生，但说实话对于教务上的东西我还真的不是很了解。因为不了解，也就意味着对需求的一无所知。
系统刚开始着手，我们的原则很简单，根据自己对教务系统的了解来拟定需求。快速建模，然后让我们的项目经理审核。第一次初步建模通过，心中暗喜自己分析的需求竟然通过，谁知.....
     酸的难耐：虽然第一次快速建模通过，但心里隐隐约约的感觉自己对需求的理解有很大偏差。为了不浪费人力资源，我向六期的师兄师姐讨了点经。这时候才发现自己理解的需求和学校的真正需求相比差距很大。和师兄交流的过程中，师兄说了很经典的几句话：要做就做好，不要去凑合。可以集中的把某一部分做好，但绝不能任何一部分作的都很凑合。解释一下我师兄说这些话的原因，因为我做的那部分是没有可参考的需求（资料）所以都是凭空自己想的。而且在刚接触教务系统的时候，有人说我们做的系统是在练手，根本不让运行。这样的话多少给自己添加了几分“想凑合”的想法，不应该啊。。。。
     苦的继续：需求的重新分析模型重建，让我看到了一点点欣慰。接下来是数据库的设计。数据库的设计可以说我没有参与。都是我们组长全权负责，三范式/外键关联/表与表之间的关系等等我都没有通过这次实践来验证。都怪自己不争气。。。数据库设计出来后，我们的数据持久层也伴随诞生。DAL层我们是用EA直接生成的。只需要在向框架里添加点内容就可以了。工作量是巨大的，技术含量是没有的，这时候体现出了我们的工作本质（代码工）同时也体现出了项目组长的才能（框架设计），通过单元测试我们的DAL层一一暂时通过。由于需求的不明确，DAL层还有很大的改动空间。
     辣的刺激：DAL完成后，我们迈向了BLL层。到了业务逻辑层，我们组每个人都没有精力在管彼此的模块了，剩下的只有埋头苦干。有了模型，对业务的分析也就有了思路。这时候才发现自己负责的教师工作量的业务很复杂（偶认为）。同时DAL层写的方法也都被推翻重写了。教师工作量这里的业务大部分涉及计算和“视图”，通过对视图的不断摸索，现在自己可以熟练建造不同数据库下的视图，对视图的使用也是有了深刻的认识。一句话“视图是个好东西呀”。标注：因为这里的业务很复杂，自己在代码实现的时候对三层的界限设计的不是很好。
     甜的快乐：业务是自己分析的，对系统的认识就更深了一步。到页面整合的时候（我们的教务系统由原来的C/S升级到B/S）也就更加顺手。一步一步地往前走，最后发现我负责的教师工作量基本功能实现了。但并不是很完善。回想刚开始接手这一模块时的那种恐惧，真的是耐人寻味。也许自己并没有想象中的那么差，是自己总在和最优秀的人进行比较，结果你懂得~
     总结：通过教务系统的实践，学会了，第一：自己如何解决问题，不再像原来那样一旦遇到问题，第一想到的就是找别人帮助。虽然现在偶尔也会需要别人的帮助，但自己的进步还是自己知道的。第二：对业务的认识，感觉业务是需求的细化。需求的明确/模型符合需求，业务也就相对来说很好理解了。不知道这样说是否正确。一句话，这个暑假，这个教务，让我学到了很多....