正在阅读：经验之谈:我是这样领导一个学生项目的经验之谈:我是这样领导一个学生项目的

　　这些工作做完之后，我们认为需求分析的文档就基本成形了，于是我们举行了一次评审，这是一次审查（Inspection），由所有组员参与，评审对象就是需求文档。我们提前两天将文档打印分发给每个人回去浏览准备，一个小插曲是打印和复印的费用花去了我们第一笔集资经费（50元）的一半，让我们吃了一惊，后面要勒紧裤腰带省点用了，毕竟大家都还是学生，花的是自己的伙食费。其实我本来以为这次评审将是失败的，因为大家以前没有过经验，而且这段时间大家都比较忙，可能不会太认真的去阅读文档和找出瑕疵。然而事实让我吃了一惊，每个人都做了充分的准备工作，人均花费了两个小时阅读文档，这已经足够了。我们的评审相当顺利，问题接二连三地被提出来。当然有一点遗憾是评审的时间没有把握好，有点拖沓了，不是因为问题太多，而是花了一些时间在如何解决上。按照各种书籍的观点，评审会议应当着重发现问题而不是解决问题，我们不经意的犯了这个错误。然而这样做是有道理的，因为在完成需求文档时，犯的一些错误多半是对这个问题不理解，而不是不知道该怎么解决，也就是说不是很清楚what，一旦明白了what，那么how可能是比较容易的。所以我们有必要及时指出问题是什么，指出问题的本质，这样长远的看是节省时间的，减少返工的次数。为什么大家会愿意去花宝贵的时间阅读文档和找出瑕疵，我想一个直接的原因是因为打印这些文档的开支比较大，大家都很心疼钱，所以不忍浪费，于是才会认真地阅读文档。挺好的。

　　起初是我们的“首席架构师”完成系统结构的设计，为了节省时间我们试图同时完成系统架构的设计和模块的细节设计，于是碰到了问题，功能上有点不统一，直接原因是对需求没有做很好的回顾和了解，仍然比较模糊，于是，原型系统发挥作用了。我在拿到需求文档之后，花了一个晚上做了一个原型系统，只有简单的界面，示意一下，这大概也是原型系统的初衷之一吧，原型系统本来是为客户服务的，与客户有一个基本的交流对象。我当时的本意是直接做正式的界面（这个天真的想法是很不合适的，然而我当时相当自信，认为没有问题），而不是做原型系统，后来我们的“评审经理”提醒我说你现在做的应当是一个原型系统，用一下就抛弃的，我才察觉到险些犯了一个巨大的错误。庆幸的，这个系统正好可以被用作原型系统，为我们的分析设计做了很好的铺垫。我们的设计师不是很愿意阅读需求文档，更愿意直接看原型系统来发掘设计思路和要求，幸好这个原型是比较完善的，至少没有遗漏一些功能表示。

　　然而，第一个设计是失败的，原因之一是对RMI（远程方法调用）没有很好的了解，RMI是这个系统的底层实现，这是我的要求，我的另一个要求是力争符合MVC的标准，或者向着它努力，以它为原则。然而我们的设计师之前没有RMI和MVC的基础知识，就直接进行了设计，显然是不合适的。我们否决之后重新阅读了书籍，建立了第二个架构，模块分得也比较仔细和合适了，基本可以接受，然而整个系统结构显得有些冗余和不清晰，问题出在MVC中的M。我们的理解中，V就是界面，对应于分析类中的boundary方面的内容；C毫无疑问就是主控器了；然而M，都知道是模型Model的意思，起初的思路是寻找系统中的名词，找到之后形成类，也就形成了相应的M。于是，系统中充斥着M。去掉一些不必要的，还是有很多，我隐约的觉得有些不必要。我花了一个下午推翻了重做，建立的设计方案中几乎没有M，或者说实体（Entity）类，这样的方案是简单的：界面发出事件请求，相应的控制器进行响应，然后更新界面并反馈信息，没有实体什么事。这或许不是一个面向对象的系统，因为乍一看找不到对象。然而这样的系统实现起来相当简单和直接，难道是设计的倒退吗，还是或者根本没有弄清楚面向对象的实质。我们的设想是，所有的名词（实体对象）都通过数据库持久性存储起来了，访问或者更改的时候直接查库，然后直接把查询结果以ResultSet（结果集）的形式交给界面去更新就可以了，何必假惺惺的封装起来再给界面，然后界面那边又要解封装，似乎多此一举。我们没有找到这样设计的大缺陷，尽管我们知道这可能是不合适的，比如不利于扩展，不利于代码重用等等。另一个重要的缺陷是，界面部分也要完成一些业务逻辑，比如对结果集信息的提取，这显然是不符合MVC要求的。然而鉴于我们现在的编程水平，易于实现是相当重要的。于是，这个方案被接受了，这是一种妥协，更像是一种失败的妥协，或者说这样的设计更像是一种失败的设计。可能后面还会返工，适当的增加一些M的部分，比如至少不能把ResultSet交给界面吧。呵呵，偶尔想起来太荒唐了。

　　界面设计方面，仍然存在很大的争议，因为可以参考的系统很多，很难达成一致。这部分工作正在做，我把我的初始意见形成草案分发了出去，大家讨论之后试图在五一前达成一致，因为一旦放假，沟通将变得困难。一个合适的考虑是五一期间基本完成编码，当然前提是大家都对各自要做什么相当清楚，接口的定义要一致和清晰，这部分我们还比较弱，设计还是粗粒度的。我们渴望接下来的几天能够提速，现在也正在提速。尽管我们落后进度将近一周，不过通过加快设计并形成良好的设计方案，我们的编码能够节省很多时间，测试也是一样，大家对按时完成充满了信心。当然，没必要也不可能五个人都参与编码，可能直接编码的只有两三个人，我负责界面，另外一个数据库编程的高手，其他的适时而定，编码方面绝对不是人多了时间就短的，绝对不能用人月除以人数得到月份，我觉得对这样的学生系统，一两个人写代码就足够了。

　　最后用一句话总结这一周：紧张而充满希望。

　　五一期间一直在写代码，现在看来是个错误的选择。我本以为尽管是一个训练软件工程的项目，然而把程序完成仍然是十分必要的，甚至是最重要的。如果系统都没能按计划完成，那这个项目谈何成功呢。于是，我们决定利用五一期间的长假完成一些代码，主要是我负责的界面部分。为什么从界面开始，因为之前写过一个原型系统，对这个系统的轮廓已经略知一二；另一方面，更重要的是，我们还没有进行详细的设计。设计只是表面的，比如确定了RMI，确定了门面模式，确定了最简单的单控制器机制等等，然而一个核心是内部的方法、属性都没有具体定义，尽管有些可笑的是完成了数据库的初步设计。一切，都有些荒唐，至少顺序上是的，也许是我个人有些急功近利了，想早点完成这个事情，毕竟我们还有别的课要上，软件工程不是我们本学期的全部。当时的想法是：我写写界面，边写边进行类的设计，然后逐渐明确数据库设计方案，然后列出方法簇给负责数据库的拍档去完成内部逻辑。换句话说，所有的接口都是边写界面边确定的。这样做是完全错误的，本以为可以缩短时间，哪知道在我向其他人解释这些接口的时候费尽周折，以至于我自己都很难描述清楚某个方法究竟是做什么用的。这时我才渐渐明白为什么一定要先确立接口，这是大家共同的语言，有了接口，有了明确的子系统划分，大家可以舒适地并行开发。然而现在，我们的情况更像是流水线开发，我做出一个界面，扔几个方法给数据库那边去完成功能。可事实上我在逐渐往后开发时总是不免的又会修改前面的设计，越改越乱，这才造成了数据库那边的编码困难。核心是什么，核心是分析设计不充分，甚至可以追述到需求的不充分。比如确定一个订单，我们只是简单地提到了要有这个订单，然而订单具体包括哪些项目我们没有明确下来，而是打算留到后面的分析设计去完成。我们之所以敢于这样是因为这是一个学生项目，没有真正的客户，我们甚至可以随心所欲地更改需求，只要可以方便我们实现。于是，为了省事，我们将许多稍显麻烦的工作留到了后面，一次一次往后拖，逐渐的，越发混乱。