注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

小葫芦君(汉斯的博客)

博客迁移到新博客:https://blog.ssxingshou.com

 
 
 

日志

 
 
关于我

小小葫芦商城,为您提供高品质的商品,一流的产品,一流的包装服务,一流的物流服务,放心购买

网易考拉推荐

看人家的Spring开发总结和自己的开发总结对比  

2007-03-28 09:57:37|  分类: 默认分类 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

首先是把人家的总结贴上来,然后对比自己的(不同颜色)

从这里开始:

对spring框架和开发模式进行了验证。大家有什么问题或好的建议,请回复,大家一起讨论!

一、 项目目标及完成情况

目标

 完成情况

 

技术验证和推广

 完成较好。

1. 共有7人实际参与项目开发,我们引入maven2作为构建工具,eclipse作为ide环境。大家都能在很短的时间初始化项目,并快速掌握各自需要的技术(如spring,spring mvc等)进行开发。

2. 对分层开发的模式也进行了探讨,证明它是可行的:可以各层并行开发,提高开发效率;而通过分层可以隔离关注点,使得各层开发人员可以只关注本层相关技术和接口,减轻开发人员负担,提高效率。

3. 在项目活动中碰到一些技术难点,我们将解决方案文档化,然后项目内共享,这样能在碰到同样问题时快速解决。现在还是碰到问题才解决,以后需要建立预研机制,较早发现可能出现的难点,尽早解决,避免对项目进展产生影响。

4. 平台还处于建设阶段,对项目的支持还不够,需要形成一些通用的组件。

 

过程和管理实施

 有待提高。

1. 测试1.0版已发布,目前开发1。1版,完善分页功能和采用更好的验证方式。由于对规范开发的项目周期估计不足,加上管理上的一些问题,导致项目有所延期,需要对实际的项目开发进行量化分析,确立比较准确的人员和时间计划。

2. UC文档规范和编码规范等的引入,为项目提供了较好的支持。

3. 在实施中比较缺乏必要的文档支持,如设计文档等;同时各层的接口定义也出现较多问题,导致一些开发瓶颈的出现,这都需要在正式迭代中改进。

 

系统功能

 完成较好。

1. 完成了UC文档确定的功能点,页面美观,使用方便,能给用户较好的页面体验。

2. 采用较好的面向对象设计,能提供一定的可重用性和扩展性。

 

二、展现层总结

经验与教训

1.         SpringMVC是一个简洁、标准的MVC实现,结构清晰,功能强大(主要体现在对日常WEB开发中可能遇到的各种常见问题的解决方案),有一定学习曲线,但是有其它MVC框架基础的开发人员可以较快上手;

2.         根据业务功能尽早确定接口,接口由展现层确定,由业务层实现;

3.         合理选择Controller可以减少开发工作量,前提是充分理解每种Controller的处理机制及其回调方法细节,Controller的编写更多的精力主要花在校验、出错处理上;

4.         页面工作量很大,特别是需要比较复杂javascript的页面;

5.         UI的流转设计等对于Controller的编写和业务层的接口有着很大的影响,应尽早明确,否则会产生较大的返工;

6.         展现层开发可以与业务层同步进行,推荐确定接口后,就编写业务层接口的mock实现,放在展现层的test包内,同时写单独的测试用spring配置文件;

待解决问题

1.         Controller是否应写test case,本次开发未做;

2.         如何减少校验的工作量,对于有业务逻辑的服务端校验如何实现,是否需要采用一些validator框架,如sun的JEF的validator组件,目前我们进行了研究,通过使用commons validator组件能够较方便的实现validator;

三、业务层总结

经验与教训:

1.         Spring,iBatis的应用还是很成功的,学习曲线比较平滑,好的框架好掌握;

2.         比较重视测试,编写很多测试案例,并频繁使用maven运行所有测试,使得问题能够及早发现,保证了各层能够快速成功集成

3.         对于很多问题都需要经过各层间的讨论来确定;

4.         接口由展现层定义,由业务层实现;

5.         持久层数据模型和领域模型是有区别的,但简单的情况下可以合二为一;

6.         Facade模式还是很有价值的;

7.         一些开源软件的使用需要比较小心,如iBatis的null的问题等,如果处理不当会花费较多的人力物力,需要技术较强的人对开源软件花费一定时间进行源码级的研究,才能找出较好的解决方案;

8.         认识到设计的重要性,需要对前置、后置条件等进行分析;

9.         数据类型分析简单,造成数据库设计对业务层产生不良影响;

待解决问题:

1.         沟通不够,需要建立沟通渠道,是否可以有专门的场合和时间讨论项目中的进度和问题;

2.         计划不明确,对于要完成哪些功能,完成到什么程度,没有明确的定义,需要设置里程碑目标。在正式迭代开始前,要明确每次迭代的任务和目标,需要结合业务需求进行计划;

四、持久层总结

经验与教训:

1.  通过代码生成工具,能够大大提高开发效率;

2.  工具使用者要求对ibatis和sql比较了解;

3.  在使用过程中对工具进行了完善,这对正式使用工具提供了保证;

4.  与业务层的接口,应该由业务层确定,由持久层实现,而不是由持久层决定;

待解决问题:

1.  持久层的测试该如何进行,才能真的有用;

2.  一些通用功能如分页代码生成,还在开发中;

自己的评论与看法可以在下面以不同的颜色进行标注。最后整理成一个日志!

  评论这张
 
阅读(929)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017