开发流程
kyfxbl
这个作者很懒,什么都没留下…
展开
-
多工程并行开发的项目,避免编译失败
最近这个项目,是几十个工程并行开发,通过ant统一编译以后打成war包今天编译的时候发生了一次编译不通过。检查了一下,原来是在工程A中有一个接口增加了一个异常声明,结果工程B中某个调用该接口的类,就编译失败了这里不吐槽java checked exception的问题,重点总结一下怎么避免编译失败的事情1、要把相关的(依赖和被依赖)工程和lib库都下载到本地,同时保证本地编译不通过的代原创 2013-09-24 11:32:03 · 959 阅读 · 0 评论 -
第3批定制需求开发中,教训总结
第3批定制需求,有几点做的不好,在此总结一下:1、有几个需求,因为当时觉得比较简单,涉及面也比较小,所以就没有很在意。整个开发过程中,将主要的精力和时间投入到别的几个大需求里,对这几个小需求关注不够。结果转测试过程中,这几个需求就出了比较多纰漏,甚至出现了阻塞业务的BUG。比较关注的大需求,反而没有出现问题总结:对整个开发过程进行跟踪管理的时候,需要对开发人员自身的素质(包括编码能原创 2013-09-24 11:05:34 · 801 阅读 · 0 评论 -
多人开发较大项目的一点总结
我有过自己一个人一条龙作完一个项目的经历(7万行代码),也试过在一个20多人的团队里参与一个更大的项目(40多万行代码)总的说来,我觉得做大项目的难度要大一些。过程中也总结了一些想法,在此记录一下首先,为什么说多人开发大型项目比较困难呢?我觉得主要有以下几个原因:1、沟通的问题。如果是我自己一个人做,我对自己的想法和思路肯定是很清楚的,就不存在交流的成本和障碍2、为了维持架构和设计原创 2013-09-24 11:13:16 · 1185 阅读 · 0 评论 -
一种不好的开发方式
最近接手一个系统的维护工作,发现该系统的现状有些奇怪:该系统是一个B/S系统。大家知道一般这种应用就是对应一个工程,工程的目录符合规范,比如在WEB-INF下的lib包里放依赖的jar包等。然后这个工程可以直接打成war包,放到servlet容器里就可以跑起来但是这个系统不是这样的,它是由30多个工程组成的。这些工程都不具备单独打包,单独跑起来的能力比如每个工程都没有lib目录(有的工原创 2013-09-24 11:00:34 · 771 阅读 · 0 评论 -
测试阶段流程
这次项目测试阶段的流程我觉得还可以,记录一下1、开发完成之后,先出一个版本,装到测试服务器上。这个服务器上的版本是稳定的,不允许打补丁2、测试人员每天测试,提交BUG。开发人员同步修改,可以滞后一点(比如1-3天),但不能滞后太多3、与测试服务器保持稳定不同,开发人员每天晚些时候,比如说17:00,都会锁定代码库,停止提交代码。然后用17:00的这个版本发布到开发服务器上,开发人员每天原创 2013-09-24 11:00:29 · 844 阅读 · 0 评论 -
多子系统集成项目的总结
这次做的项目,涉及到6个子系统的集成,其中有2个是遗留系统,4个是新开发的系统。我负责其中一个新系统前期还是比较顺利,提前完成了开发计划,并进行了比较充分的代码检视、单元测试和内部测试。但是在进入接口联调和系统集成以后,就变得非常痛苦,这2周平均每天工作时间超过16个小时。但是整个系统还是没有稳定下来,还是有非常多的问题,而且每天的效率非常低,大部分的时间都是花在等待中为什么这次在开发这么原创 2013-09-24 10:59:13 · 2173 阅读 · 0 评论 -
敏捷开发和瀑布开发的混搭
现在这家公司的开发流程很奇怪,和以前的公司很不一样一、首先拿到一个客户需求,这个客户需求(OR)可能就只有一句话:“做XXXX运维成本太高了,管理也很混乱,能不能给做个管理系统给控制一下”由于这个客户很重要,所以虽然需求很不明确,连系统该做成啥样都不知道,但是领导还是决定要做。于是项目组就启动了。这个时候所有已知的东西,就只有这个一句话的OR二、第一阶段,叫Chart开发,这个阶段找了原创 2013-09-24 10:34:01 · 1048 阅读 · 0 评论 -
代码依赖的2种情况
代码依赖有2种情况:第一种是“静态依赖”,这种情况最常见。比如项目A依赖了Spring框架,那么只需要将Spring的jar包引入。每次只要编译A就可以,不需要每次先编译Spring的源码,然后再编译A(因为可以认为Spring是稳定的)如果Spring升级了,那么项目需要引入新版本的jar包,然后重新编译一次。如果组件的API发生变化,造成项目编译失败,再调整受影响的代码即可第二种是原创 2013-09-24 11:11:43 · 1678 阅读 · 0 评论 -
主管一席话引发的思考
昨天主管召集开会,讲了一些事情,摘录其中我认为有价值的,在此记录一下:1、BUG修改之后,在转测试回归之前,开发内部要自行验证。这个是传统了,不过主管建议不要只依赖现有的DTS系统(公司的一个BUG管理系统),因为其内置的流程,只支持一个人审核问题,这样往往不够准确,有可能回归不通过。所以主管建议自行用EXCEL进行跟踪,关键是进行两轮审核,这样可以降低回归不通过的概率。这里有2点值得总结原创 2013-09-24 11:05:50 · 767 阅读 · 0 评论