1、在开发之前进行了完整的需求分析，形成了系l的需求文，需求文档中最有用的部分感觉就是界面原型，q有pȝ的菜单，q样l了用户一个初步的直观的印象，同时文档中的一些对于界面原型的描述以及计算规则{内容在后期的开发中也v了指g用?/p>
2、在需求分析完成之后，q行了概要设计，包括完整的数据库设计Q这样在后期的开发中Ҏ据库表结构方面没有大的修改了Q只是添加了一些表和视图?br />
再谈?font color="#0080ff">目中的~点吧：
1、首先就说说需求文档，虽说需求文写了很多，大概?00左叻IwordQ，但由于一文中集中的内容太多，对于用户来说只是x了界面原型，pȝ菜单{部分，对于其它内容用户x度不高；同时׃幅太大Q开发h员打开查看或者后l修改也比较ȝ?/p>
对于以后的需求文是否可以这L写：首先有一个正文，正文中包括大UԌ然后每一个具体的需求放在单独的一个文档中Q最好能cMhtml链接那样Q这h看也方便Q也一目了然?/p>
原来用RobotHelp写过帮助Q照此看来，岂不可以用来写需求文了Q呵?/p>
2、再说数据库设计Q还不够l致Q很多应用场景由于设计的不够l致Q导致数据库表也有所Ơ缺Q因此对于以后的目设计有两个注意点Q?/p>
a、加强应用场景设计，具体可以用流E图Q甚臛_列图描述清晰的业务流E，完善数据库表设计?/p>
b、要求一定先修改模型Q这里指PowerDesigner中的数据库设计）Q然后再M改POJOcȝ具体代码Q最好不要先改代码，再修Ҏ型，q样隑օ会有遗漏Q时间久了，׃D模型和代码的不一_慢慢的，模型文档没有h看，也没有hl护了?/p>
c、顺便提一下，模型文的好处一是方便后来者，二是可以方便的导出数据字典?/p>
3、对于命名规范没有在开发前考虑全面Q虽然在开发前对命名规范有一定的规定Q但是不够全面，造成了后期开发中各h各h的命名有所偏差?/p>
4、分层架构中的dao层和service层处理的不够好，Dservice层实际上是杂了dao和service的功能，业务代码不够清晰。以后的目考虑dao是daoQ提供数据访问的操作Qservice层则提供业务处理ҎQservice与dao的关pd该是多对多的关系?/p>
5、考核pȝ中用了JSF/Richfaces做ؓ表现层，好像不太好Q经怼出现多次重复讉KҎ的问题，后箋q需要加强对JSF的学习，避免cM问题。另外Richfaces在生成大数据量的面Ӟ一个表格有1440行数据，面巨慢无比:(Q后来没有用RichaFaces的表|直接使用jstl+html标签Q速度倒是很快?/p>
6、项目中的日志输出、异常处理不够明晎ͼq个和命名规范一样应该在目开始时l出清晰的思\Q在具体开发中应该l常查?/p>