【中信软件教育中心】再见,亲爱的中信苏志宏.docVIP

高级项目总结暨告别中信感言 序 章·真正需要的是什么 紧张的培训已经悄然走过，经过了这八个月的磨练，班上的同学基本已经找到工作，对此，我也感到很高兴，同时，也有很多话想要和大家说。找到工作，也只是我们生活中迈出的一小步而已，在直面我们的职业人生之前，我们需要的到底是什么呢？ 中信给予我们很多：提供我们一个就业的机会，教会我们一种赖以生存的技能，或许，你也找到了一种学习的方法。是的，这些就是我想要的！然而，这些就够了么？ 如果，你需要的仅仅是一份工作，那么你在中信的使命已经结束了。如果，你需要的只是java技巧，那么你的使命早就已经结束了。如果，你来中信之前不曾知道你需要的是什么，只是觉得别人来你就应该来，那你从一开始就错了。 无论你如何规划你的人生，请永远记住你需要的是什么，那么你才是最精准的一只利箭！ 项目篇·我们都还年轻 一路盘带，临门一脚，却发现眼前的一切都是虚幻...比这还要痛心的，就是我们的这个项目了。他的失败，一瞬间磨灭了我所有的激情，我所有的憧憬所有的渴望都被这样被活生生的撕碎。气愤，留下的也是深思。走过了，我没有什么遗憾，失败了，我同样有收获。 语曰：败军之将，何以言勇。我也没有勇气展示我们的项目，对此我也只能简单的谈一下我对这个项目的感受。 ·项目的分析：项目刚开始的时候，我不知道用例图是干什么用的，我也不知道这东西到底要怎么画，有什么约束。曾经憋着我坐一上午却没有什么思路，网上这方面的资料也不是很多，经过反复的琢磨，我终于能马马虎虎的画出来。但是我还是不知道这玩意对我们的项目有着什么样的影响。随着项目的进行，开始类图设计，其实这个阶段我也是迷迷糊糊完成的，就在反复的看着需求文档找名词，生怕漏掉一个，最后一遍遍的推敲，试着砍掉重复无用的，确定了项目中所有的“类”，随之我们的数据库表就确定了。在接下来的功能设计中，我几乎颠覆了我之前所做的所有工作。先是DAO层的设计，针对每一张表进行操作，抽离接口、设计二级接口与抽象类，对每一个子接口进行特殊方法的定义，参数的确定等等，问题并不是很大。但是接下来真正麻烦的来了，就是Service层的设计，同样是接口、二级接口、抽象类、子接口的设计流程，却让我绞尽脑汁。因为这里的每一个功能的实现都要由DAO层来做支撑，因此我就反复的徘徊于DAO与Service的修改之间。这时候，之前所做的用例分析的作用就凸显出来了，用例中的每一个小圆圈，那就是我在Service中的一个方法！如果用例分析做的很完善的话，那么Service层二级接口中至少我不用在去想要有那些方法，我要考虑的也只是这也方法要那些参数而已，同样的，用例也可以约束我们的DAO层的查询与统计分析。 因此，总结的经验就是要把用例图画的尽量完善，哪怕是功能画的多了，我到后来看到重复了可以删掉，但是一旦少了，那业务就实现不了。DAO层的设计时要根据用例分析去思考都可能用到哪些查询，基本的增删改是相同的，只有查询五花八门，因此要将查询写的尽量的详细。在Service层的设计时，一个功能可能用到几张表的查询，也用到不同类型的查询，因此可以检验DAO层设计的是否完善，要根据DAO层的参数来确定Service层的参数。因此这个阶段是一个反复迭代的过程：设计Service—对照修改DAO—确定DAO—修改Service—确定Service，这中间或许也发现了数据库设计的缺陷，同样要求我们做出调整。这整个项目中，我们的数据库也修改了很多次。DAO层的修改就更是频繁。此外，我觉得在用例分析的时候首先就应该进行一次BrainStrom，不管是否合理，记录所有的功能，确保功能的完善，之后再进行过滤筛选。之前我没有体会到用例图的作用是如此之大，所以在设计Service的时候我就成了在用例分析—数据库—DAO设计—Service设计四者之前反复的迭代，增加了设计阶段的难度，浪费了很多时间。 ·基础代码的测试：DAO层和Service层这些代码的准确性是要得到保障的。就像我前面所说，我们的开发思路是从DAO层到Service层最后Action层，每前进一步都是以前一步作为铺垫的，因此前一层代码的正确对其后的代码编写和测试起着至关重要的作用。因此我们要对之前的代码进行单元测试，确保其能正常且正确的运行。对此还需要对两个层次进行异常的定义。在DAO层的异常要抛出到Service层，并记录具体的异常信息，在Service层进行捕获处理，比如会员登陆的查询如果没有输入的用户名，那么查询结果为null，那么在Service层时必定会抛出NullPointerExpection，这时要做捕捉处理，继续向上抛出Service的异常给Action层处理。在此期间，我也进一步熟悉了JUnit的应用，也对框架有了进一步的了解。 ·技术点准备：在这一点上