东软实习总结

此次实习做的是日报管理系统（ B/S 模式），我们二十多个人作为一个团队共同完成这个系统。原来我们实习的时候五，六个人为一组做一个系统，几乎都是糊里糊涂的完成任务，做的系统根本不可能供别人使用，只是实现了基本的功能，没有权限控制，没有数据验证，没考虑到系统的安全性，没有规范系统编码（没有规范类名，包名 … ），没有规范页面风格（ CSS 样式之类的）。总之原来五，六个人为一组做一个系统时我们仅仅是为了完成老师布置的任务。这次东软实习不同了，我们二十多个人为一组共同完成这个系统，做的当然要比原来的系统完善的多。         

刚开始的时候我以为我们的任务很简单，二十多人二十天做完一个日报管理系统应该是件很容易的事情，这个系统无非也就是由一个个增，删，改，查组成的，这些我们早在原来的实习中就已经会了（这次东软实习用的技术是 Spring+Struts+Jdbc, 其中 Jdbc 在学校二十天的实习中我们已经基本掌握了）。但是问题远没我们想象的那么简单，就拿我负责的模块来说吧，我负责的是“日报登录”模块，拿到需求分析说明书一看，无非就是增，删，改，查（日报的增加，日报的修改，日报的删除，日报详细信息查看），起码从实现来讲是非常容易的（没什么技术难题）。的确这个模块实现起来很容易，我们很快就实现了“日报登录”这个模块的基本功能，但是我又花了一大半的时间来完善这个模块。那么我们除了实现基本的功能以外还要做什么呢？其中哪些是必须要做的，哪些是应该要做的呢 ?

首先我来谈谈必须要做的事情。我认为我们必须要做的事情就是数据验证。例如我们实现新增日报的时候不可能仅仅是编写好数据库接口就够了，换句话说我们不能就写个 insert 语句就够了。我们还要验证插入的数据是否合法，是否规范。我们都知道只要我们插入的数据类型正确，符合数据库的约束条件那么基本上我们的程序就会正确执行 insert 语句。但是这些数据虽然插入了数据库，你能保证这些数据对用户来说是有效的吗？你可能说这些数据是用户输入的，对用户来说当然是有效的。但是你可否考虑到用户在输入数据时一不小心输入错误，或者是故意输入错误的情况？例如我做的这个模块中就有这么一条限制：“工作量不可大于 16 （小时）”。也就是说用户不可在工作量这一项中输入大于 16 的数，那么你如何对此限制呢？你当然不能靠数据库做限制，即使用户数据输入 100 ，那么这条数据也会被插入数据库（数据库不会做出任何提示，也不会抛出任何异常）。当然你可能会说在编写数据库接口时做验证，就是在执行 insert 语句前验证数据，如果工作量大于 16 就不执行 insert 。但是你可曾想过如果那样做的话，那么一个数据库接口将会拥有太多责任，数据验证它来做，数据插入也是它来做。那么这个数据库接口的重用性将非常差，因为它的职责不够单一，内聚性太低（总之违反了一堆设计原则）。而且如果客户要修改数据验证标准，例如把“工作量不可大于 16 （小时）”改为“工作量不可大于 20 （小时）”那么你就会去修改这个数据库接口。然而如果你要修改 insert 语句，例如新增一个字段或者把一个 varchar 改为 number 型时，你也要修改这个数据库接口。总之给人的感觉就是什么事都找它，什么活都由它来担负，这样势必会影响的这个模块的性能，不仅仅是对它的执行速度有影响，还对它的可维护性和可重用性有影响。

其实我们可以在前台验证数据，利用 JavaScript 的就能实现。但是我们怕有人通过修改 JavaScript 代码来破坏系统（可能我们想太多了 … ）。我们学校的教务系统就是个例子，本来如果系统登录人数大于一定数目时就会限制一下，让后来者排队等候，但是有人修改了页面的 JavaScript 代码，把这个限制去掉了。那么我们就可以使用那个人修改后的页面登录系统，而不用再排队等候了（这样服务器很容易崩溃，反应速度急剧下降）。如果不用 JavaScript 来实现，那么我们可以用什么呢？还好 Struts 框架提供了一个 ActionForm 类，它有个表单验证的方法。用户输入的数据被分装成一个表单，我们可以通过这个表单验证的方法来实现对用户输入数据的验证，如果数据有误就跳转回指定的页面。

其实我感觉表单验证挺难的，你要考虑周全才行（完成基本验证很容易，但是把方方面面都考虑到就难了）。例如就工作量这一项来说，你除了要验证工作量不大于 16 以外你还要验证它的格式是否规范，例如如果用户输入 10.1 和 10.4 那么你要把这个数转化为 10 和 10.5 （总之要使用户输入的工作量便于计算，这样好给他们发工资 … ），还有用户不可以输入空数据，即工作量不可为空。如果用户没有输入任何数据你的系统要给出相应提示。还有就是如果用户不小心输入 10.a （其实出现 10.a 的情况更有可能是用户闲的无聊，想玩玩你做的系统 … ），你应该做出相应判断并提示用户“您输入的不是数字” , 如果你不做判断的话那么数据库肯定会抛出异常（ 10.a 不可能做为 Number 型插入），这样你的系统会提示出莫名的错误（例如会提示“数据库异常”或“数据库访问错误”），其实这只是数据插入失败而已，不会对系统有任何影响，这种错误对我们程序员来说算不了什么。但是对用户来说就不同了，他们不知道到底发生了什么，用（玩）你系统的人一定会非常诧异，心里可能会想：“怎么办？我把系统搞崩了，会不会影响到其他人，老板会开除我吗？ … ”可见我们程序员的疏忽会对用户产生多大的不安。这就像我们第一次碰电脑的时候一样，总是小心翼翼的操作，生怕把几千块钱的东西搞坏了，当我们对它有更多了解时才发现它并没有那么脆弱，当我们对它有进一步认识的时候就直接上手解决问题，当我们对它彻底了解的时候干脆就动手造个系统出来给别人用。但是我们要清楚用我们系统的人可不是程序员，他们不关心系统是怎么造出来的，他们只关心这个系统用的是否顺手，是否舒适。

说实话如果要把系统做的更友好其实也是非常不容易。然而也有许多同学不屑于去做，认为这个东西没有技术含量，也没有什么必要。的确让你在插入成功之后弹出一个对话框提示“插入日报成功！”这是非常容易实现的，也是没有必要的，因为无论是否弹出这个对话框，也不会影响到系统的正常运行，那条数据照样会插入数据库。正如我前面说的我们原来 五，六 个人为一组做一个系统，只是应付一下老师即可，把基本功能实现一下就 OK 了，根本不会有用户用我们的系统，那个提示框自然就显得多余了（不过你要是做出来的话，老师好像会给你们组加分 … ）。但是我们不可能总是做没有人用的系统（那样谁给我们工钱？），所以我们应该在实习的时候多锻炼一下，把系统做的更友好，让你未来的用户用的更舒适，是的，这些就是我们现在应该做的事（今后到企业里应该就是必须要做的事了）。

其实如果你真的认真做起来的话还是会感觉这是件不容易的事。首先你要考虑很多东西，你要好好想想哪些地方应该弹出提示框。例如我原来就想在用户点击“修改”时候，弹出一个对话框“你确认要修改这条日报”，用户点击“确认”，则进入修改页面，点击“取消”则不做任何操作。后来我发现这是多余的，用户既然点击了“修改”按钮肯定是要修改日报，即使用户不小心点错了，回头取消操作不就行了。所以没必要再弹出个对话框，这样反而会引起用户的反感。然而在用户修改完成后点击“提交”按钮时，我们是有必要弹出一个“确认保存修改？”的对话框的（因为用户可能还想要做修改，或者还想要检查一边）。在修改成功后还应该弹出一个对话框提示“修改成功！”，让用户知道那条日报的确更改完成，让用户更安心，从而让他感觉你的系统更可靠。还有就是你的提示信息要简单明确，例如当用户输入的工作量为 19 时，你不能只是单纯的提示“你输入的数据有误”，你应该说的更具体点，如“工作量不可大于 16 ” 。还有当用户输入的日期不在某个项目的开始结束日期之间时，你不能只是提示“您输入的日期有误”，你应该提示的更加明确，让用户一看就懂，如“您输入的日期不在该项目的起始，结束日期之间”，然后最好还要把项目的起始，结束日期告诉用户，让他们根据那两个日期输入数据。

二十多个人一起做一个系统，组间协作显得尤为重要，组与组之间要随时沟通，遇到疑问一定要咨询一下相关的组。这次实习与以往不同，原来如果你有什么东西不明白与组员讨论一下即可，偶尔问问其他组的人也无妨。但是现在不同了，你若遇到相关问题一定要和别的组员一起讨论，因为现在是二十个人一起完成一个项目，而不是只有你们一组，有可能你们的决策会影响到其他组，同样其他组的决策也会影响到你们。例如你可能会修改公共的配置文件，你修改的配置文件可能有问题，可能会使服务器不能正常启动。这样别人并不知道是由于你的错误而导致的，他们会下意识地检查自己的程序，当检查自己的程序没有错误时才开始检查公共文件，这样势必会浪费很多时间。还有一个让我印象深刻的就是有关数据库设计的问题。我们做项目的时候并没有统一用一个数据库，而是先各用各的，我们一直以为“项目表”中的“状态”字段为 Number 型，但是有一个组也用到了“项目表”，而他们以为“状态”字段为 Varchar 型（其实数据库是老师设计好的，但是数据库设计的有点问题，经常改变，我们对有些字段的理解也有差异）。这样我们在整合测试时出了问题，这时我们才开始讨论，统一了意见。如果我们两组在编码开始前就统一了意见，那么我们最终整合测试时就不会出问题。

我发现其实最后的集成测试是非常有意思的。因为我们不仅仅是在测试我们的模块，我们还在测试别人的模块。例如我们要为某个人员分配项目，我们就要用到“项目设定”这个模块，在用的时候我们往往就会发现他们的一些漏洞。同样别人也会用到我们的“日报登录”模块，那么他们也会在用的过程中发现我们的缺陷。总之我们是在互相测试，互相指正。其实这时也能看出一个模块与其他模块的耦合度。如果一个模块被多个组用到的话，那么他就可以说是关键模块，它起着关键作用，如果它崩溃了，其他组的模块也别想正常工作（当然负责那个模块的人责任也最大）。总之集成测试可以让你发现很多错误，不仅仅是只有你们组的。

最后的组间测试可以说就是在单纯的“玩”别人的模块了，你可以随便玩，如果你玩出 Bug 了，那绝不是你的错误，相反你要告诉那个组的人，你们的模块有问题，要修改一下。你很可能会发现别人难以发现的错误，毕竟你是在肆无忌惮的“玩”别人的系统，发现错误了，受罪的却是别人，呵呵（这不像自己测试，自己发现的错误还要自己改正，郁闷）。当然我们要虚心接受别人提出的错误，毕竟他们是在帮助我们（如果让以后的用户发现问题，那还真不好办）。

短短二十多天的实习生活就这么结束了（大三暑假也这么结束了），我在此次实习中学到了不少。这次我们做了一个比较完善的系统，这个系统稍加修改应该就可以投入使用了（当然我们就不管系统维护了）。这也为我们进入企业打好了基础，起码有过一次二十多人合作的经历。以上是我的一些经验总结，如果有哪些错误的观点或论述请读者多多指正，谢谢。

                                                                                                                                                   Stephen S ong

                                                                                                                                                  2010年 9月 21日