为系统而生，为框架而死，为bug奋斗一辈子；吃符号的亏，上大小写的当，最后死在需求上！
----悲催的程序员
最近又在合作开发，带着两个人做教务系统中的其中一小部分，主要的功能就是计算教师的工资，计算教师的工作量，还有就是排整个学校的课程表。由于这个系统是仿照着上一个不太成熟的系统做的，也就是说我们需要重新理解需求，重新设计数据库。
这两天一直在做那个教务系统，让我感觉最难的部分就是需求那部分，从着手开始做的第一天起脑海里就不断的在理解需求，问了问六期的师哥师姐，基本上对需求了解了一点了，但是大姐（学宇）要求把系统要做活，做活，做活……*（……%￥&*（%*（）……&（）纵有千般无奈更与何人说啊！
用了大概五天左右的时间定了需求，然后三天把数据库基本设计完成。数据库定了实体类就基本上定了，实体类定了之后我们就开始了DAL的编写。目前为止DAL基本完成，正在写BLL。现在最怕的就是需求变化，或者需求理解不到位。因为一旦需求那里有严重问题那么很有可能数据库就要修改，数据库修改就意味着很多工作需要从头再来。自己这块还好说因为毕竟需求做了很长的时间基本上不会有太大的变化，最可悲的是数据库也设计好了，实体类也弄好了，按照别人要求的接口DAL也弄好了，但是突然别的小组的组长发过来一份文档说我们需要****接口，仔细看看那个字段我们这里根本就没有，解释了半天对方甩过来一句“不就加个字段么”。最烦别人要求我们改数据库，最最烦别人看也不看就直接朝我们要接口，然后我告诉他“我们没有这个字段啊”，他反而问道“你们是怎么设计数据库的！？”。我无语……
现在开始怀疑真正的软件应该怎么做？
整个软件的架构难道不是应该先由专人负责的么？
软件开发的过程中是一边开发一边修改，还是设计完成（不要求完美，起码也得80%完美吧）然后再开发。
一个大的系统数据库是否要分成很多小模块呢？这不是自己给自己找绊儿么？
……
伴随着这些疑问DAL是修了又修，改了又改。面对任何一个恶心的任务都不是问题，最怕的是一个不恶心的东西一直做，直到做到恶心为止，修改DAL，修改DAL，修改DAL就这样无穷无尽啊啊啊啊！
仔细想想发生这样的状况的原因是什么？就是因为前期的需求没有做好，常常看到网上说一个软件的开发周期中设计阶段要占三分之二的时间，而大部分的开发团队（我们也一样）为了赶时间稀里糊涂的了解了需求，然后就开始着手敲代码了。结果因为需求不明确或者设计不合理，后期就一直改啊改，最后把系统改的一团糟，什么设计模式，什么架构都是扯淡，能实现就已经是万幸了,整个软件也没有效率可言。
拿我们这次做的系统来说，由于是把大的系统分成了几个模块，每个小组负责一个模块。各个小组只顾着实现自己的功能丝毫不考虑整个系统的效率，或者说想考虑也无能为力，因为你没有权利去指点别人那块应该怎么做，不应该怎么做。效率低下很常见的一个情况就是要从别人的数据库中得到一个数据，首先需要从第三甚至第四个数据库中取得更多的数据，然后利用这些数据再去第一个数据库中查找自己需要的数据。现在真不敢想象这么个系统能否搭建起来，或者说能否经受得了较大数据量的考验，因为一个简单的功能就需要和数据库交互多次，那么一旦数据到了万级或者十万级，那这个系统的效率就可想而知了。
泪奔,继续……