`
chian_xxp
  • 浏览: 96633 次
  • 性别: Icon_minigender_1
  • 来自: 厦门
社区版块
存档分类
最新评论
文章列表
各种规范都是通过分解过程,制定过程中的规范
根据前篇的思路,将所有的struts2 hibernate spring3的源码全部放入到自己的项目中,可以更好地调试程序。 加入了使框架和程序能顺利通过编译的第三方包之后,部署到tomcat又遇到一些差包的问题,也解决了。 能顺利的启动,但在访问页面时却出现问题。找log4j日志文件发现: 11-2-23 下午9:59 main WARN com.opensymphony.xwork2.config.providers.InterceptorBuilder Unable to load config class org.apache.struts2.interceptor.validation ...
当有些第三方包,因为版本的变化,可能删减一些类,增加一些类。 而有时候,我们需要的是两个版本的一个整合。 可以使用eclispe中的功能,在你的项目中找到jar,然后右击出现merge jar的选项。 到这里,就明白了。
从javaeyer获得启发,改变自己的学习方法。 先说说之前的方法, 1 孤立地去学习常用的ssh,变成一种情况就是看着是懂了,但动手的时候,总是出现各种各样的问题。于是,无论是看书还是做项目都很烦躁。看的时候,觉得就是这么一回事呀。我知道了呀,做项目的时候又怀疑。 现在的方法是,把ssh的源码放到实际的项目中。出现问题的时候,可以直接跟进去。在这个时候,在结合理论看。感觉清晰多了。而且掌握得牢。
今天在搭建完整的struts2 spring3 hibernate3的源码开发环境时。(主要是受到javaeyer的启发,搭建三个框架的源码能跟踪出现错误的地方) 发现,自己的是jdk 1.5.而spring中有使用到com.sun.net.httpserver的包。 自己处理: 找到jdk1.6/lib  rt.jar,将com.sun.net包拷出来,在放到jdk 1.5的rt.jar中。 这样就OK 哈哈,
先把我的情况跟大家说个清楚,只有这样。大家所提供的意见才更有针对性。 我1980年出生,2001年毕业于一个师专的计算机科学教育专业。说实在话,学的烂.(为什么没有当老师,就不用问了) 因为学的烂,毕业出来找份工作都难。在一家工厂里面做仓管,呆到2005年10月,自己花钱参加了北大青鸟的软件工程师培训。全部学完。3W多。 06年底毕业,开始从事软件这行的工作。至今。。。。其中作过维护,开发。维护和开发的时间差不多。 现在在公司上班,感觉自己的技术没有什么优势,甚至有的技术还不如刚出来的毕业生(可能碰到一个强人).再加上我开发比较粗心(自己总觉得,这技术、那技术我都会,不会的,我学一下就会了 ...
需求是不断的改,直到今天还在改,都说周五要上线。 以为那代码都论斤称的是吧,这个简单,那个容易。 很讨厌,因为需求的变化,导致之前的工作,白做。 验收项目又老TMD的说,时间够充裕了吧。从什么时候到什么时候......,怎么还会完成不了。 我又嘴苯,也不愿意跟他们讲。命哭,只有拼命地改,拼命地赶。 老累,老受打击了。还真觉得自己的技术这么差劲。
1 概要设计一定要分析清楚。 2 一定要详细设计,如果有足够的项目经验。小项目就可以不做。 3 理解面向接口编程,接口是与业务操作对应的。要先定接口,再写实现。[我犯的错误是没有根据业务来定义接口] 4 写了接口,要写接口的测试用例。再写实现。 5 类包能简单就尽量简单。类包复杂体现出你的低水平。只写action+business+util的测试用例。其他的不用写。尤其是dao,使用了hibernate,就不要使用接口了。 6 吧不要的类删除。
同一个项目,只是由于开发的机器不一样。总会出现莫名其妙的错误。大概总结一下原因: 1 对于同一个包,不要导入多个版本。   当然,我们不会睁眼犯这样的错误。现实的情况是,我引入hibernate的包,于是将hibernate-dir/lib中所有的jar都到进来。这里面可能就包括了log4j的包,而其他的一个library又可能同样地导入了log4j一次。所以这样会出现版本错误。由此引起的莫名其妙的错误,你往往百思不得其解。 2 针对上面的问题,在一台机器部署正确好,应当将所有的lib/*.jar,在重新做个文件夹。无论哪台机器都指向这个文件夹中的jar就可以了。
自从我接触junit以来,我一直奉为准则。用了一段时间之后发现: junit适合的环境: 1 测试业务逻辑,模拟业务处理的输入数据。测试业务是否清晰、正确。 junit不适合的环境: 1 对外界的依赖很大,以至于,你模拟出来的外部环境于实际的环境相差甚远。这样的测试,就没有了效果。例如:dao中涉及到与外部数据的连接。   对junit测试的选择,依据就是。你能否模拟出跟现实环境很接近的数据输入。如果可以,junit测试就比较有用,而如果模拟的环境与实际的环境相差甚远。就不用单元测试了。   模拟能力的强弱,决定了测试的效果。
http://www.leadge.com/publish/html/36450.html 如何编写高质量“软件需求说明书”原著:Karl E Wieger,Process Impact   你的工程应该有个好的起点。一个小组要带领客户进入需求启发阶段而且你要写软件需求说明书。这份说明有些大,但客 ...
Balsamiq: 写这篇文章的目的,为遵循软件作者的licensee.为这款软件作推广,就可以获得licensee. 我也是从别人介绍中得知这个balsamiq mockups原型开发软件的,试用之后确实不错。 1 简单,不像Axure rp,那么复杂。跟客户交流,客户是不关心你怎么实现的,他关心最后实现后成什么样子,操作是否符合他的要求。 2 简单,但功能完全够用。在BS开发中,页面中会用到的组件,balsamiq mockups都提供了。   这也是我三个小时使用的心得,这三个小时,我不得不忍受无法保存和定期弹出注册框的烦恼。  
maven核心部分"项目管理模型"和“依赖项管理模型”。都放在pom.xml文件中进行配置。依赖项被称为工件。 maven坐标:是一个三维的数据。用来指定唯一依赖项。依赖项组织,依赖项名称,依赖项版本。 mojo:是插件中一个任务。    
UML建模的过程是一个步步深入,从面向问题转向到面向解决域的过程;一个从整体到局部的一个分析过程。但分析的对象仍然没有变。 一般情况下,有如下过程: 1 客户启动一个系统的开发过程。 2 需求调研:由软件公司和客户共同完成。  A 业务需求调研:面向问题域。以word文档的形式呈现。 与客户交流,提取出系统中的业务。形成用例列表。这个阶段将形成业务需求文档初稿。 在这个过程,只是去提取出系统中存在的用例。不需要去考虑系统中如何来安排。   B 系统需求调研:面向解决域,以uml的形式呈现。 画原型: 将业务需求转化成uml中用例。 用例: 对于复杂的用例,通过通信图和活动图细化用例,得到更为详细 ...
瀑布式开发方法:这是一种理想状态下的开发。所有下一级的工作基于上一级的工作。一旦上一级的工作出现问题,无法交付下一级的工作时,整个团队都停在那是。 螺旋式开发方法:要求对系统的需要有个框架性的了解之后,就可以进行系统设计。然后针对需求中最为简单和独立的部分进行开发。这部分交互客户测试,并收集反馈信息。再走一次软件开发的流程。这个是重复几次瀑布式的开发方法。 迭代式开发:这个过程是将螺旋式开发方法的工作粒度变细。在螺旋式开发方法中,我们每重复一次的工作量是整个软件开发的过程。而在迭代式开发中,重复的工作内容是软件开发的其中一个环节。 递增式开发:将整个系统的开发进行分析之后,我们提供最初级功能的系 ...
Global site tag (gtag.js) - Google Analytics