qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

数据库范式设计

 在软件开发过程中,数据库的设计是非常重要的。可以说,良好的数据库设计,是对用户需求的理解的精准定位。它不仅能够使得软件开发起来非常便捷,而且还能够使软件系统高效运行,同时,为日后的维护或者更换数据库提供便利。

  在最近开发系统的过程中,感觉收获最大的也是关于数据库的操作。最初开发机房收费系统的时候,由于没有经验,而且懂得的知识也非常少,数据库的设计根本谈不上,就是感觉到数据库中缺少某些字段的时候,直接在数据库表中去修改字段。这样就为自己徒增了很多工作量,相关的代码需要一处一处去修改。

  开发.NET版机房收费系统的数据库设计明显好多了,由于充分了解了需求,数据库设计当然比上一次好上很多。不过回头去看,数据库的设计还是存在很多的缺陷。表中仍然存在着大量的冗余字段,增删改后也会出现发生一些异常。

  在牛腩新闻发布系统中,由于系统非常小,对于数据库的操作也就那两下子,复杂也到不了哪里去。不过尽管如此,感觉牛老师的数据库设计还是非常规范的。类别、评论、新闻分别放在三个表中,完全没有冗余数据。

  废话太多了,开始步入正题了。良好的设计能够使程序员的工作事半功倍。

  首先,先来看官方解释:

  第一范式是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即是实体的某个属性不能有多个值或者不能有重复的属性。

  第二范式是指数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖。

  第三范式数据库表中不存在非关键字段对任一候选关键字段的传递函数依赖。

  简单来说,第一范式是讲数据库表中数据的原子性,数据不可再分,只要是关系型数据库都必须首先满足第一范式。看下图例子:图1中三个字段不可再分,故满足第一范式;图2将专业、年级、班级三个字段放在一个字段里面,就不符合第一范式了。

          

  下面再来看机房收费系统中的一个表设计——学生基本数据表。

图A

  图A中由于每一个字段都不可再分,故它是满足第一范式的。然而这样的设计就会产生大量的冗余字段。如果一个学生注册两个卡,那么该学生的信息就需要重复两次。

  第二范式就解决了上述问题。它强调其属性必须完全依赖主键,实体的属性不能仅仅依赖主关键字的一部分属性。如果存在部分依赖关系,那么这个属性和主关键字相应部分应该分离出来形成一个新的实体,实体与原始体之间是一对多的关系。

  像上面例子中,很显然主键是卡号和学号联合做主键,其中姓名、性别、系别、专业、年级、班级都只与学号有关,只依赖学号,而不依赖卡号,这样就不符合第二范式了。

  我们的根据第二范式的要求,将其与学生相关的信息分离出来,修改后,我们可得一下两个表:

图B

  然而,仅仅满足第二范式的数据库是远远不够的,满足第二范式,仍然可能会出现传递依赖。图B学生表中系别与专业存在传递关系。假如小红和小明的系别都是数信学院,专业都是数学专业,那么这样数据库中系别就重复了两次,增加了冗余字段。

 第三范式保证了同一类事物分在一个表中,消除了传递依赖的现象。我们再根据第三范式的设计要求,将其学生表在进行分离,得到下面的表:

图C

  下面给出图C的数据库关系图:

  好的数据库设计,是软件开发中非常重要的一步。三范式设计只是一个标准,对于基本表的设计,建议大家尽量按照三范式的要求进行设计;而对于临时表的设计,我们可以适量的增加一些冗余字段,毕竟单一表的查询检索速度比较快,提高了系统性能。

posted @ 2012-04-26 09:34 顺其自然EVO 阅读(212) | 评论 (0)编辑 收藏

以测试为核心的软件开发过程

 摘要:软件项目规模越来越大,开发团队人员越来越多,人员增加带来管理成本上升,于是引入ISO9000、CMM,但最后发现它们实施难度相当大。于是我们介绍一套行之有效的测试控制方法,它能够有效对软件项目开发进行控制。

  关键词:软件测试软件开发;软件项目管理

  1、引言

  TC(测试控制方法)是指以测试为核心控制软件项目开发过程的方法,它包括完整的规范TC 系统及其相关管理理论TC 理论。主要完成软件开发中开发流程的管控、软件测试、开发绩效评价、持续改进管控质量等功能。

  ● 我们先来看一看软件项目开发中经常遇到的问题。

  ● 各模块一拖再拖,整个项目无休止延期,开发进度无法得到控制;

  ● 改正了旧问题,又冒出更多新问题,问题层出不穷;

  ● 模块难度、工期质量考核无法量化,更无法与个人收入挂钩;

  ● 技术攻关、需求、分析与设计阶段任务难以进行验收;

  ● 项目负责人需要时刻关注各开发人员的开发过程,没有时间进行项目整体规划;

  ● 项目负责人经常感到失控,开发人员开发出的结果往往与预期效果差异很大;

  ● 项目负责人在模块严重拖期时,不知是应该换人重做,还是再让其开发几天;

  ● 项目经理对各开发团队的开发能力没有客观的认识;

  ● 项目经理对各项目的进度情况不能有效把握,经常被告之以“马上就完了”这样含糊的承诺;

  ● 项目经理对自主开发的产品没有量化的质量评价;

  ● 所有这些问题都在TC 系统中迎刃而解。

  2、TC 系统依赖全新的管理思路

  ● 做出好软件

  好的软件是做出来的,不是改出来的。软件必须依靠具有一定水平的开发人员集中精力开发,不可能靠反复的修改来完成。软件修改次数越多,出错的可能性就越大。

  ● 测试的任务

  测试的主要任务是控制开发人员随意提交低质量的程序。例如:我们在测试中有个定义叫返回,意思是,当开发人员提交了问题过多的程序后,测试人员可以不用告知程序中的问题,直接返回程序要求开发人员重新修改。这样既控制了被提交程序的质量,也使测试人员把工作重点从寻找简单的低级错误,转移到寻找程序中复杂的逻辑错误。坚决反对“测试人员是帮助程序人员发现问题的”说法,而强调测试人员是站在一个更高的管理控制层面上。

  ● 绩效考核

   项目开发中的工期与质量采用分值进行量化绩效考核,不单注重质量或进度,将二者统一起来。绩效是指某人在完成一个工单时,质量和工期的综合评价。一个理 想程序员完成工单的绩效为1,比理想程序员完成效果好绩效大于1,完成效果差绩效小于1,一般程序员的绩效在0.7 左右。

  采用量化绩效可以对项目人员绩效进行考核排队,并与个人收入挂钩。采用量化绩效还能将从事不同类型工作的项目人员进行排队,如:对开发人员和售后服务人员绩效进行排队。

  ● 弱化人际关系

  项目管控过程中对事不对人,由软件系统确定处理流程,邮件方式传递信息,避免人情关、面子关,减少在人为交流中的冲突与不确定性。

  ● 全面管控

  借鉴ISO9000 质量管理体系的思想,遵循“怎么想就怎么写,怎么写就怎么做,怎么做就怎么记”。所有工作做到统一安排、有据可依、有史可查。

  3、实现流程

  TC 可以在整个项目的开发过程中进行管控。需求分析,技术攻关,分析与设计,构造实现,测试部署阶段,甚至在售后服务阶段都可以使用TC 系统进行控制。

  所有工作都以工单的形式派发并跟踪验收。各工单按以下流程进行控制:

图一

  开发团队接到新项目,明确工作内容后,就可以使用TC 系统控制整个项目直至结束。制订工作计划;派发各阶段的工单,验收工单,封版;如此循环,直至所有工单都封版,表明项目开发完成。

 摘要:软件项目规模越来越大,开发团队人员越来越多,人员增加带来管理成本上升,于是引入ISO9000、CMM,但最后发现它们实施难度相当大。于是我们介绍一套行之有效的测试控制方法,它能够有效对软件项目开发进行控制。

  关键词:软件测试软件开发;软件项目管理

  1、引言

  TC(测试控制方法)是指以测试为核心控制软件项目开发过程的方法,它包括完整的规范TC 系统及其相关管理理论TC 理论。主要完成软件开发中开发流程的管控、软件测试、开发绩效评价、持续改进管控质量等功能。

  ● 我们先来看一看软件项目开发中经常遇到的问题。

  ● 各模块一拖再拖,整个项目无休止延期,开发进度无法得到控制;

  ● 改正了旧问题,又冒出更多新问题,问题层出不穷;

  ● 模块难度、工期质量考核无法量化,更无法与个人收入挂钩;

  ● 技术攻关、需求、分析与设计阶段任务难以进行验收;

  ● 项目负责人需要时刻关注各开发人员的开发过程,没有时间进行项目整体规划;

  ● 项目负责人经常感到失控,开发人员开发出的结果往往与预期效果差异很大;

  ● 项目负责人在模块严重拖期时,不知是应该换人重做,还是再让其开发几天;

  ● 项目经理对各开发团队的开发能力没有客观的认识;

  ● 项目经理对各项目的进度情况不能有效把握,经常被告之以“马上就完了”这样含糊的承诺;

  ● 项目经理对自主开发的产品没有量化的质量评价;

  ● 所有这些问题都在TC 系统中迎刃而解。

  2、TC 系统依赖全新的管理思路

  ● 做出好软件

  好的软件是做出来的,不是改出来的。软件必须依靠具有一定水平的开发人员集中精力开发,不可能靠反复的修改来完成。软件修改次数越多,出错的可能性就越大。

  ● 测试的任务

  测试的主要任务是控制开发人员随意提交低质量的程序。例如:我们在测试中有个定义叫返回,意思是,当开发人员提交了问题过多的程序后,测试人员可以不用告知程序中的问题,直接返回程序要求开发人员重新修改。这样既控制了被提交程序的质量,也使测试人员把工作重点从寻找简单的低级错误,转移到寻找程序中复杂的逻辑错误。坚决反对“测试人员是帮助程序人员发现问题的”说法,而强调测试人员是站在一个更高的管理控制层面上。

  ● 绩效考核

   项目开发中的工期与质量采用分值进行量化绩效考核,不单注重质量或进度,将二者统一起来。绩效是指某人在完成一个工单时,质量和工期的综合评价。一个理 想程序员完成工单的绩效为1,比理想程序员完成效果好绩效大于1,完成效果差绩效小于1,一般程序员的绩效在0.7 左右。

  采用量化绩效可以对项目人员绩效进行考核排队,并与个人收入挂钩。采用量化绩效还能将从事不同类型工作的项目人员进行排队,如:对开发人员和售后服务人员绩效进行排队。

  ● 弱化人际关系

  项目管控过程中对事不对人,由软件系统确定处理流程,邮件方式传递信息,避免人情关、面子关,减少在人为交流中的冲突与不确定性。

  ● 全面管控

  借鉴ISO9000 质量管理体系的思想,遵循“怎么想就怎么写,怎么写就怎么做,怎么做就怎么记”。所有工作做到统一安排、有据可依、有史可查。

  3、实现流程

  TC 可以在整个项目的开发过程中进行管控。需求分析,技术攻关,分析与设计,构造实现,测试部署阶段,甚至在售后服务阶段都可以使用TC 系统进行控制。

  所有工作都以工单的形式派发并跟踪验收。各工单按以下流程进行控制:

图一

  开发团队接到新项目,明确工作内容后,就可以使用TC 系统控制整个项目直至结束。制订工作计划;派发各阶段的工单,验收工单,封版;如此循环,直至所有工单都封版,表明项目开发完成。

● 项目绩效正态分布曲线

图六

  该曲线Y 轴为工单数目,X 轴为工单绩效。整个曲线描述用户培训管理系统在开发中各级绩效出现次数对比,其中绩效为0.2 以下和1.2 以上的很少,绩效为0.7 的工单最多,因此可以说明用户培训管理系统的开发绩效在0.7 左右浮动,平均开发绩效接近0.7。

  ● 公司绩效正态分布曲线

图七

  该曲线描述整个公司在项目开发中各级绩效出现次数对比,其中绩效为0.2 以下和1.2 以上的很少,绩效为0.7 的工单最多,因此可以说明公司的开发绩效在0.7 左右浮动,平均开发绩效接近0.7。

  若单从平均值来看,图六和图七表现的开发能力是相当的,其实不尽然,图七的正态分布趋势要比图六更向0.7 紧缩,从图上看图七要瘦于图六,说明图七的开发能力更趋于稳定,而图六的开发能力更难以预料。因此由以上分析得知用户培训管理系统开发团队的平均质量与公 司整体开发质量相当,但远不如公司整体开发能力稳定。

  5、适用对象

  TC 适合大多数软件开发团队。由于她的特点是以测试为核心控制软件开发过程,因此她更适合于软件测试人员配备不是非常充裕的团队,由有限的软件测试人员就可以担当起测试与控制的任务。

  对于开发一般企业级应用软件的开发团队来说,软件开发中一般低级错误是最多的,通过TC 系统能使一般低级错误得到控制,测试人员集中精力于业务逻辑关系测试。一般企业级应用软件的开发团队选择TC 系统将会比选择任何一家测试或项目管理软件更实用。

  对于开发控制系统或算法集中的平台类软件的开发团队来说,虽然一般的低级错误可能较少,但TC 系统能将任务分配、任务的追踪、工期质量统计、测试记录的整理与归纳等工作自动完成,自然可以大大减少测试人员的事务性工作,帮助测试人员关注核心的算法与逻辑关系测试。

  6、结束语

  TC 能有效对软件项目进行控制, 记录各阶段工作详细内容,并能够对原始数据进行挖掘整理,为各类项目人员提供全面多方位的信息表现形式,协助公司和个人客观认识自身的开发能力,寻找影响开发能力的主要因素,为持续改进提供帮助。

posted @ 2012-04-26 09:32 顺其自然EVO 阅读(203) | 评论 (0)编辑 收藏

软件项目“免坑”指南

 “谁也无法改变现状,唯有无数程序员血洒大地,才能使项目重建天日。”这一点也不夸张,软件项目做烂了就是个坑,参与者也不过是填坑的。就像是在魔兽世界战场遇到国家队一样,你赢也赢不了,出也出不去。

  一、坑有多深?

  当我们进入一个项目时,通过不断观察我们可以发现我们的项目到底是不是一个坑。造坑的项目,往往具有某些“臭味”,以下是我的一些认识,这些“臭味”即是项目健康状态不佳的明显标志:

  ● 编码规范形同废纸,代码质量低下。每个项目都有编码规范,但真正严格实施却是另一回事。太多的项目把编码规范作为形式的存在,没人在乎让开发人员写出“人能读懂的程序”,注释和命名也成了开发人员的随心所欲。project上永远只有开发任务,而几乎找不到单元测试的时间和代码审查的时间。在高压进度之下的项目,显得如此山寨。当我们还在抱怨自己工资低的时候,就先看看我们的程序还能称作OOP吗。

  ● 缺乏文档或文档质量低下。前 期文档很重要,不论是框架的API使用手册,还是需求或设计文档,以及各种既定流程的规范,不同种类的模板及核对表,等等这些文档,对于项目来说都是非常 重要的资源。而往往有些项目,这类文档就是交由非软件行业的人员来编写,或者前期根本不打算在文档上浪费时间。这就导致了,缺少相关文档或文档质量低下, 在软件构建过程中,开发者和团队,不得不为这种“表面工程”的产物而纠结。甚至会退回到前期准备工作,完成所需的文档。有些文档可以在后期补,但有些必须在前期进行准备,以保住团队降低风险,减少缺陷引人的几率并提高编码质量,如果前期这类文档没有做好,那么就会像考前不复习一样,自食恶果。

  ● 无尽的需求变更,永远追不上的进度。这 是最常见也是最可怕的,因为无论怎样,我们都无法完成它。客户可能认为改个程序,就像改个Excel一样简单省事,甚至会使用可动用的一切权利和资源来推 行变更。好吧,我承认这样的客户我遇到过很多。当我向客户解释过变更的代价并提供备选方案后,也就只能等待客户的选择了,这多少有些运数的成分,但也是无 奈之举。

  ● 仅仅靠加班应对进度落后。进度落后并不可怕,可怕的是仅靠加班来追赶进度。这是问题的 关键,长时间的赶工仍然无法赶上进度,这只意味着项目有某种更深层次的问题,已经不是单开赶工可以解决的了。留意那些长时间加班的项目,他们往往在管理上 存在很大问题,发现这些问题,在你成为PM时,不要犯类似错误。

  ● 沟通无门。如果你在一个“叫天 天不应,叫地地不灵”的项目里,那你最好省心吧。项目中沟通很重要,但总有些项目,领导的工作太忙,人就是找不到,发出去的邮件就是没人回,遇到问题就是 自己扛。在这样的项目里也有一些好处,比如锻炼自己的自学能力,以及磨练意志与根性。不过这些,也都是我的自嘲。低效的沟通将导致不必要的返工,这才是我 所痛恨之处。我最为恼火的一段经历是,甲方要进行变更,开了一周的会没人通知我,我的小组在这一周里完成了原计划的数个需求并进入到测试阶段, 但这些需求均被砍掉 。本来只有甲方告知是可以调整进度开发其它模块的,但最终演变为资源的浪费。可见,沟通是多么的重要。

  ● 没人关心质量。因 为软件构建属于专业领域,客户并不具备相应领域的知识,由于这种信息不对称,助长了软件的质量低下。我们开发的软件可以是“低等级高质量”的,但不能够是 “高等级低质量”的。但是,太多的项目不在注重编码质量,这与软件构建的复杂度有关,也与整个行业的风气有关。但不管何种原因,提高代码质量仍然应该作为 团队的努力方向。团队应该奖励那些,编写高质量代码的程序员。如果你的团队奖励的是那些,“BUG杀手”(每天修改上百个BUG),而冷落那些缺陷检出数 量很低的程序员,那么,你的PM是个不懂技术的,至少我本人认为,任何有技术背景的PM都应该奖励那些正在保持职业操守,认真对待需求,保证代码质量的程 序员。他们为项目付出了更多,更多的异常处理, 更多的测试调试,更多的检查,更多的重构,虽然他们的进度并不快,但他们引人的缺陷数量很少。每个做过开发的人都会在质量和进度上做出取舍,而我敬佩那些 选择质量程序员,因为他们才是真正拿开发当事业的人。在此,向所有努力提高代码质量的程序员致敬!

  ● 没人为缺陷买单,没人为自己的成果负责。需 求产出了低质量的文档,设计没有进行充分的迭代,开发可以怎么简单怎么写,测试可以随意测测,没人为自己的成果中的缺陷买单,除了项目经理,他为项目承担 唯一责任。当项目组所有人员都在混时,就是在给自己挖坑。这种缺陷的堆积,会像放射性元素在食物链中的堆积一样,早晚项目会因此而崩溃。

  ● 过高的离职率。这 个是最明显的“臭味”,这说明我们的同行已经在这里无法忍受了。它所带来的恶略影响不光体现在可用资源的减少,还体现在对成员士气的极大影响。如果不及时 改善,这将是一个非常恶性的循环,当往一个进度落后的项目中添加资源只会使进度进一步落后,而非正离职导致必须补充新的资源,资源从入职到培训都会对对团 队产生震荡,并降低现行团队的生产力。一个频繁处于形成阶段的团队,很难要求其有什么凝聚力,团队问题将会凸显,尤其是在沟通上,在项目忙的时候很少能照 顾到新人。花费在对新人进行培训,和与其沟通上的时间,很可能得不偿失。

  ● 团队中的不良情绪。不 同团队开始扎堆并相互敌视,例如开发组认为设计组是一帮搞业务的白痴,根本不懂编程;测试组认为开发组的人就是垃圾,BUG提交了多少便还是无法关 闭;PM开始抱怨,自己的成员不配合;成员开始抱怨,PM是个纯管理没资格指挥内行做事。等等,诸如此类的怨念会在团队中积累,并以某个导火索为契机爆 发。面对现实吧,至少,我远没有自己想象的那样高尚。我承认我曾经会和别的程序员说:“你看XX他们写的代码...什么呀...”,这样的话。在过去我也 吐槽过别人代码,这种做法是错误的,我为此表示歉意。现在,如果有必要,我会说代码有缺陷,但绝不会说他的代码不好。我希望,我们能彼此尊重。对于技术人 来说,不尊重他的成果就是不尊重他的人,所以我还是建议PM在管理工作中,多用“缺陷”,少用“不行”、“不对”。但是,项目中也总是有些人,靠鄙视别人 的成果来彰显自己的实力。这些人,有,但很少。至少我遇到的很少,遇到过几个,让他们的话语成为你学习的动力吧。我曾经被人讽刺UI做的太丑,之后我学会了SL和FLEX;被人鄙视基础太差,之后开始阅读《CLR Via C#》;我朋友被人嘲笑过数据库设计,现在人家也开始买书深造。团队中就是这样,我们无法管住别人的嘴,但我们可以管住自己的。少说多听,一鸣惊人,乃上上之策。不要受情绪的影响,保持一个平静的心。

  ● 没有项目或阶段的后评价。不 对项目的阶段进行后评价,也意味着没人在乎你到底干了些什么,所有人都只是进度是否完成,而没有对完成的好坏进行评价。这也意味了,仅靠做好你的工作,你 是无法得到领导的重视的。最终只有那些加班时间最长的程序员被领导认可。而能力强,口碑好的成员也只能在团队和客户中间留下传说。

  二、谁在造坑?

  软件项目涉众众多,造坑的多为项目实施团队内部,而究其原因也是多方面的,但是始终离不了项目的四个维度——时间、范围、成本、质量。很多时候 客户并不具备软件项目的实施经验,而实施团队为了迎合客户意愿,也会多多少少的在这四了维度上做文章。资源、时间不足,轻质量重功能,往往成为造坑的契 机。所以,不用怀疑,造坑的往往是我们自己。很难理解,真正挖出大坑的人,最后也是填坑的人。一个人很容易被外部事务所左右,就如“同假的多了,真的到成 假的了一样”,多数人不愿意在一个新环境中表现得特立独行。但也有老的程序员对我说过:“当别人做错了,你就不要跟着去做!”所以,我认为工作就是工作, 不需要我们在其中融合多少兴趣,也不要求我们有过多的付出,但对于工作的成果则要求我们认真的对待。俗话说:“拿多少钱,办多少事!”如果多少有些团队意 识,能够对自己的工作负责,那至少在意识上,我们能给自己少造些坑。

  三、如何免坑?

  (一)清除盲区

  以下观点,仅是我对软件项目中一些错误认识的归纳:

  ● 写出能用的程序就行啦!我们应该首先清楚我们做的是什么,一个成熟的团队产出的可交付成果应该包括软件 编程产品,相关文档,项目实施过程中的经验教训已经其它一些非形式的成果(培训)。这里,我们必须清楚的认识到,我们所开发是是编程产品,而不是我们个人 的技术实践或大学的毕设。对于编程产品,我们必须认识到,其是产品级别的,必须保证质量,必须提高用户体验,必须考虑系统的诸多特性或维度。这一过程远比 我们自己写个程序要复杂的多。设计需要不断地进行迭代;开发人员需要遵守严苛的规范,编写大量的注释和大量的异常处理;测试人员需要不断地进行各种重复测 试,但是正是这种全局的规范,全体团队的不懈努力,才保证了我们的编程产物可以称之为产品。所以,一定要明确,我们要完成的是一个产品,而不是一个毕业设 计,它不是一个人的技术实践,而是整个团队倾注精力去完成的最佳成果。我们可以轻松的实现客户的某些需求,但需求背后的某些东西,需要我们认真对待,比如 安全性和性能等。实现功能的程序谁都会写,而写出高质量的程序的才是真正的艺术。

  ● 尽快开始编码吧!软件构件是一个精心设计的过程,其前期准备十分重要。在后期修复缺陷的成本要远远高于前期。因此,在项目执行前,前期的规化十分必要。在前期每发现一个缺陷,都会为后期节省大量的成本。

  ● 需求怎么变了!没有不变的需求。

  ● 进度落后了就招人呗!这是种典型的错误认识,《人月神话》中已经说明的很清楚了——往一个进度落后的项 目中注入资源,只会使进度进一步落后。虽然,这本著作成为PM必读之作,其思想也被业界所广泛认可,但是,还是会有很多管理者单纯的认为,通过注入资源能 解决问题。对于这些人,只能让实践来检验真理了。

  ● 软件质量保证是测试的工作!这是一种逃避责任的说辞。如果把代码质量比喻为减肥,那么测试无疑是一个磅秤,减肥工作还是要有开发人员来完成。所以,不要将代码质量都寄希望于测试工作上。即使是大规模的用户测试,其错误检出率也不足五成。而真正挑起代码质量重担的是代码审查。

  ● 程序员你8小时就写了这么点代码?让开发人员将全部时间都花在编码上是不可能的。开发人员需要时间预读 文档,需要与相关干系人进行沟通,需要花时间来搜索资源。此外,可能还需要编写文档,参加会议,培训以及处理个人事务等等。这些时间都会无情的夺走编码的 时间。程序员大约有近似20%的时间甚至更多会用在与编码无关的事情上(不算上班或聊QQ),所以不要错误的以为每个程序员每天能写8小时的程序。

  ● 你今天写了这么多行代码真有效率!编码不是在扫地,比谁扫的面积大。不能单纯用行数来评价开发人员的工作量。评判的标准应该结合模块的复杂度,编码的缺陷检出量以及最终交付时可用代码的比例(实践表明,我们报废了大量的无用代码)。

  ● 他今天把自己100多个BUG都改了,我们得在组里表扬下他!在我看来这样的领导不跟也罢,这就是让人 相当无语的行为。好的开发者在提交测试前,觉得会对自己的代码进行走查和调试,甚至使用单元测试工具,因此其代码的缺陷检出量很小。这样的程序员,才值得 被表扬。而那个一天改了自己100多个BUG的人,作为管理者应该想想,流程哪里错了,需要进行改进。

  ● 设计我来定,开发你闭嘴!这样的例子也不少,这种做法有一种听起来非常合理的理由——保证项目架构的概 念完整性。其解释为,如果将设计人员从开发人员剥离,那么就可以将架构的概念完整性统一,因为设计人员的数量比开发人员是数量要少的多,更容易统一认识。 而这样做的项目组,也默认地认为设计组的技术实力要明显高于开发组。他们往往从开发组中选择优秀的设计人员到设计组,但也会有走眼的时候。其一,硬手没有 被提拔。这时候多半是硬手对设计不满,并对团队管理层产生质疑,并想法设法进行沟通。如果处理的好,可能硬手会被重视,如果沟通无门,那之后,可能会充斥 着抱怨和不满,以及人际关系的恶化。有些强硬些的可能会选择拒绝不合理的设计或更为极端的是离职。走眼的另一种情况是,挑的人干不了设计。这样往往就是让 他锻炼,而不是撤换(彼得原理——每个人都会被晋升到他不适合的岗位)。这就郁闷到极点了,设计者将会与相应的数名开发人员进行一场旷日持久的暗战。其 中,已经不只是个人的抱怨,甚至会演变成成员集体的士气低落,并最终促成小组的重组。我认为,有必要将开发人员纳入设计活动。应该参考开发人员的意见,其 原因有三:其一,开发人员对实现相当熟悉,往往发现设计中的不足;其二,通过授权开发者参与设计,能让其感受到认同感,提升其参与项目的欲望,和责任心; 其三,让开发参与设计,可以对设计人员进行储备,在需要时作为备选资源使用。

  ● 客户(领导)说必须完成,我也没办法!这就是“领导一句话,劳动人民跑断腿!”这是非常典型的加班借 口。软件构建过程如同耕种,你每次只处理它的一小部分,一点一点的加到整个系统,使系统一点一点的“生长”。这也暗示了,工作应该按部就班,正如春种秋收 一样,各个环节有强硬的逻辑存在。所以,我们必须学会对不合理的要求说“不”。这里并不是说要拒绝客户的需求,而是指应该向客户说明情况并提出相应的备选 方案以供参考。例如通过通过削减范围来达到按时完工的目的。PM需要向客户说明情况,并向其提供几套可行的解决方案,以促成项目向良性发展。

  ● 我是领导我来排进度!工作进度的安排不能是领导的单方决策,而应该参考做了解这项工作的人的意见。

  ● 系统上线了,项目就算结束了!只有当可交付成果成功移交,项目进行的相应的收尾工作,项目的经验教训文档被总结和归纳,一个项目才算真正意义上的完成。

  (二)参考建议

  ● 做好前期准备。前期准备很重要,如果在开始构建之前认真的地进行适当的准备活动,那么项目会运作的良 好。充足的准备防止我们制造一个错误的产品。前期工作的好坏,多少会为这个项目的成功和失败打下基础。即使进入构建阶段,如果我们发现前期工作做的不好, 也完全有理由退回去。前期准备工作和核心目标就是降低风险——一个好的项目规划者能够尽可能早地将主要的风险清除掉,以使项目的大部分工作能够尽可平稳地 进行。目前,对后期影响最严重的风险是糟糕的需求分析和项目规划,因此准备工作就倾向于集中改进需求分析和项目规划。

  ● 预先行其事,必先利其器。用软件武装团队提高生产效率,例如:版本控制,错误跟踪,信息发布,自动发布,CASE工具,调试工具,测试工具,文档管理,代码生成工具等等。

  ● 分析项目类型,在管理和构建之间找寻平衡。商业系统、使命攸关的系统、性命攸关的系统在整个项目阶段具备不同的控制粒度。需要根据项目的具体类型来确定管理的严谨程度,避免“过度控制”或“控制不足”。

  ● 需求必须被冻结。需求必须被冻结,如果需求不能冻结,那么谁来了都没有用。再强的团队也无法完成一个无尽的任务。

  ● 变更必须走流程。正确应对变更,变更并不可怕,可怕的是失控的变更。以下建议希望对读者有所帮助:

  在构建期间处理需求变更

  1、核对需求,评估质量:如果需求不够好,停下来,把它做好再开始。

  2、确保每一个人都知道需求变更的代价:让客户知道需求办更并不像在Excel上进行几个修改那样容易,“进度”和“成本”是你最有力的武器。

  3、建立一套变更控制程序:固定的变更控制程序让你知道在什么时候处理变更,让客户知道你会处理他们的提议。

  4、使用能适应变更的开发方法:迭代与增量。

  5、放弃这个项目:如果以上提议没有一条奏效,需求变更极其频繁,那么,评估你的项目,考虑放弃它吧,继续下去你只会越陷越深。

  6、注意项目的商业案例:性价比,没必要满足超出项目成本的需求。

  ● 关于加班。做IT的加班是很正常的,但加班要加的有意义,而且不应该长期加班。必须针对关键路径上的工 作进行赶工,而不是做些无法加快整体进度的工作。而且,应当安排调休,而不是支付加班费。其主要原因也是我不赞成加班的原因——疲劳更容易引人缺陷。加班 无疑会使人疲劳,每个人都想尽快结束手上的工作后回家休息。在长期疲惫的情况下,人员的工作效率会下降,士气会低落,非正常离职率增加,最重要的是疲惫的 团队很难保证软件的质量,缺陷在不知不觉中引人,在后期无疑会为此付出代价。项目的总成本和周期,都会随着引人缺陷的数量的增加而倍增,而且发现的越晚越 严重。

  ● 做好版本控制和配置管理。版本控制和配置管理是必须有的,即便是再小的项目也不能忽视,必须加以重视,一旦版本混乱,多多少少会对构活动造成影响。所以,平时不要偷懒,管理好每个基线。

posted @ 2012-04-26 09:22 顺其自然EVO 阅读(190) | 评论 (0)编辑 收藏

如何完成系统测试?

     摘要: 软件系统测试意味着将软件系统或者应用程序做为一个整体进行测试。应用程序的系统测试从整体上检测软件大致的业务,操作以及最终用户需求的一致性。系统测试被归类为黑盒测试。  这就是为什么内部设计,架构或者代码对于这种测试来说完全不重要。  当执行一个软件测试时,专业软件测试员倾向于区分是接口里面的,还是整个软件里面的错误或者缺陷。然而,当执行软件或者应用程序的内建(build-in)测试的时候,专业的软...  阅读全文

posted @ 2012-04-25 14:59 顺其自然EVO 阅读(185) | 评论 (0)编辑 收藏

Java中类与类之间的关系

Java中类与类之间的关系存在以下关系:

  1、泛化(Generalization)

  很简单,就是我们常说的继承。是说子类获得父类的功能的同时,还可以扩展自己的功能。

  如图:

  Java代码中表现为:extends和implements

  2、依赖(Dependency)

  两个相对独立的咚咚(A和B),当A负责构造B时,A与B形成依赖关系,即A使用B。

  如图:

  Java代码中的表现为局部变量,方法的参数,以及对静态方法的调用

  3、关联(Association)

  两个相对独立的咚咚(A和B),当A对象持有B对象的时候,形成关联关系。

  关于分为有两种特殊的形式,聚合(Aggregation)和组合(Composition),聚合和组合只有概念上的区别,在Java中的代码实现上没有区别。

  聚合:指的是整体与部分的关系,如图:

  组合:表示类之间整体和部分的关系,但是组合关系中部分和整体具有统一的生存期,即整体对象不存在,部分对象也将不存在,如图:

  Java代码中,表现为成员变量。

  4、总结

  在Java中,应该尽量优先使用组合,而不是继承,因为继承会使得类关系过于复杂化,破坏了封装性,使用组合一样可以获得已有类的功能,而且会使新类更加稳固。

   实际上,从依赖 -----〉聚合--------〉组合,类与类之间的关系更加紧密,互相之间的影响越来越大,其实我们平常比较少去区分这些关系,而且事实上这东西的定 义不太好理解,所以肯定会导致认识上的偏差,所以我们使用这些东西的时候,尽量靠近大家都认同的做法,这样容易让别人理解。

posted @ 2012-04-25 13:52 顺其自然EVO 阅读(164) | 评论 (0)编辑 收藏

Oracle数据库游标在存储过程中的使用

作为关系型数据库市场的老大,Oracla占有举足轻重的地位。虽然在操作上不如SQLSERVER那样方便,但是他的强大的功能还是吸引来大批大批的追随着。本人作为ORACLE菜鸟,在工作当中也偶尔使用Oracle。以下记录的上由于工作需要写的Oracle的<br>使用游标的储存过程,个人觉得比较有代表性。希望给初学者一定的帮助,也给自己加深一下印象。

  在ORACLE中,他以一个语句块为一个默认的事务。也就是说,如果你就单单只执行一段ORACLE的语句块,他默认是以事务的形式执行的。

CREATE OR REPLACE PROCEDURE sp_EditInlayOut(
                 FID     NUMBER,                    --修改记录的ID T_INLAYOUT表的主键
                 InlayBoxIDs varchar2,          --修改的记录
                 BoxCount number,              --装箱数量
                 ApplyUserID varchar2,        --申请人编号
                 StoreUserID varchar2,         --库管编号
                 ConfirmStatechar,              --确认状态
                 ExistStatechar,                    --存在状态
                 strErr OUT varchar2             --存储过程执行结果。成功返回空,失败返回错误原因
)
AS
   --定义变量
   v_Now DATE;                                     
   v_Now2 date;                                        
   v_LogID number;
   v_ChipID number;
   v_sql varchar2(2000);
BEGIN
  
      --记录日志
      INSERT INTO T_InlayOut_Log(F_InlayBoxIDs,f_Boxcount,f_Applyuserid,f_Storeuserid,f_Addtime,f_Confirmstate
         ,f_Existstate, f_modifyid, f_modifytime, f_modifyuserid )
                        ((SELECT F_InlayBoxIDs,f_Boxcount,f_Applyuserid,f_Storeuserid,f_Addtime,f_Confirmstate,f_Existstate
                         ,FID,SYSDATE,StoreUserID FROM T_InlayOut WHERE F_ID=FID));
      --取刚插入记录的ID
      select seq_t_inlayout_log.currval into v_LogID from dual;
      --定义游标
       DECLARE CURSOR myCusor IS SELECT F_ID FROM T_CHIP WHERE F_InlayBoxID IN (SELECT f_ID FROM 
       T_InlayBox where F_InlayOutID = FID);
      --开始使用游标取数据
       BEGIN
            OPEN myCusor;
  
            LOOP
                FETCH myCusor INTO v_ChipID;
                --游标取不到数据则退出
                EXIT WHEN myCusor%NOTFOUND;    
  
                      SELECT MIN(F_CurrentTime) INTO v_Now FROM t_Chipstatehistory WHERE
       (F_HistoryState ='Confirm_InlayIn') AND F_ChipID = v_ChipID;
                      --改变芯片表的状态
                      UPDATEt_chip SET f_State ='Confirm_InlayIn',F_CompareTime = v_Now  WHERE F_ID = v_ChipID;
                      --保存芯片状态历史记录
                      INSERT INTO T_CHIPSTATEHISTORY(f_chipid, f_Historystate,F_TABLEID,f_Currenttime,F_TABLENAME) 
                     VALUES
                      (v_ChipID,'Confirm_InlayIn',v_LogID,SYSDATE,'T_InlayOut_Log');
  
            END LOOP;
            CLOSE myCusor;
       END;
  
      --选择最近芯片状态变更时间
      --SELECT MIN(F_CURRENTTIME) INTO v_NOW  FROM T_CHIPSTATEHISTORY WHERE F_HISTORYSTATE = 20 
      AND F_CHIPID IN (SELECT F_ID FROM T_CHIP WHERE F_InlayBoxID=(SELECT F_ID FROM T_InlayBox 
        WHERE F_InlayOutID=FID));
  
      --将芯片表中芯片状态更新到以前状态
      --UPDATE T_CHIP SET F_State=20,F_CompareTime=v_NOW WHERE F_InlayBoxID IN (SELECT F_ID FROM 
       T_InlayBox WHERE F_InlayOutID =FID);
      --记录芯片状态变更日志
      --INSERT INTO  T_ChipStateHistory (F_ChipID,f_Historystate,f_Tableid,f_Currenttime,f_Tablename)VALUES
      --((SELECT F_ID FROM T_CHIP WHERE F_InlayBoxID=(SELECT F_ID FROM T_InlayBox WHERE F_InlayOutID=FID)),
          20,v_LogID,SYSDATE,'T_InlayOut_Log');
  
  
      --将Inlay出库箱表中以前的数据更新到以前状态
      UPDATE T_InlayBox SET F_State=2,F_InlayOutID=nullWHERE F_InlayOutID =FID;
  
      --编辑时将新的INLAY出库信息更新
      UPDATE T_InlayOut SET F_InlayBoxIDs=InlayBoxIDs,f_Boxcount=BoxCount,f_Applyuserid=ApplyUserID,
      f_Storeuserid=StoreUserID,f_Confirmstate=ConfirmState,F_ExistState=ExistState,F_ConfirmTime=null 
      WHERE F_ID=FID;
  
      --更新T_InlayBox 新的状态
      --UPDATE T_InlayBox SET F_State=3,F_InlayOutID=FID WHERE F_IDin(InlayBoxIDs);
      v_sql :='UPDATE T_InlayBox SET F_State=3,F_InlayOutID='||FID||' WHERE F_ID in ('||InlayBoxIDs||')';
       --立即执行v_sql
      EXECUTE IMMEDIATE  v_sql;
  
      SELECT SYSDATE INTO  v_Now2 FROM DUAL;
      --更新芯片表状态
      UPDATE T_Chip SET F_State='No_Confirm_InlayOut',F_CompareTime=v_Now2  WHERE F_InlayBoxID IN
       (SELECT F_ID FROM T_InlayBox WHERE F_InlayOutID=FID);
      --记录当前操作日志
      INSERT INTO  T_ChipStateHistory (F_ChipID,f_Historystate,f_Tableid,f_Currenttime,f_Tablename) 
     SELECT F_ID,'No_Confirm_InlayOut',v_LogID,v_Now2,'T_InlayOut_Log'FROM T_CHIP WHERE F_InlayBoxID IN
     (SELECT F_ID FROM T_InlayBox WHERE F_InlayOutID=FID);
       --提交
       COMMIT;
     --发生异常时返回错误码
     EXCEPTION
        WHEN OTHERS THEN
        strErr := substr(sqlerrm,1,100);
        ROLLBACK;
END sp_EditInlayOut;

  但是在SQLSERVER中,除非你将所有的T-SQL语句块以显示的方式【BEGIN TRANSACTION ....END TRANSACTION】申明在事务中,否则SQLSERVER会将语句块中的每一句作为一个单独的默认事务执行。

  此外,游标是一种比较占I/O资源的操作,使用完后应该及时关闭,以释放系统资源。

posted @ 2012-04-25 13:49 顺其自然EVO 阅读(1375) | 评论 (0)编辑 收藏

SQL Server DBA工作内容详解

 在Microsoft SQL Server 2008系统中,数据库管理员(Database Administration,简称为DBA)是最重要的角色。DBA的工作目标就是确保Microsoft SQL Server 2008系统正常高效地运行。DBA的工作也是最繁忙的工作,无论是性能调整,还是灾难恢复,都离不开DBA的支持。

  一般地,作为一个DBA,至少应该做好以下12项任务:

  ● 任务一:安装和配置;

  ● 任务二:容量规划;

  ● 任务三:应用架构设计;

  ● 任务四:管理数据库对象;

  ● 任务五:存储空间管理;

  ● 任务六:安全管理;

  ● 任务七:备份和恢复;

  ● 任务八:性能监视和调优;

  ● 任务九:调度作业;

  ● 任务十:网络管理;

  ● 任务十一:高可用性和高可伸缩性管理;

  ● 任务十二:故障解决;

  下面简单描述这些DBA的任务

  任务一:安装和配置。

   DBA的第一项任务是安装和配置Microsoft SQL Server 2008软件系统,为顺利使用Microsoft SQL Server 2008软件创建良好的环境。无论是安装还是配置,都应该根据实际需要来进行,使得系统满足用户的实际需求。需要注意的是,系统配置不是一劳永逸的,应该 随时根据需求的变化和环境的需要,进行监视和适当地调整。

  任务二:容量规划。

  容量规划是对整个Microsoft SQL Server 2008系统进行一个总体的规划。规划的重点应该放在解决瓶颈问题上。可以从内容和期限两个方面考虑系统的容量规划。

  从内容上来看,应该考虑的主要内容包括:硬件容量规划、软件规划、网络规划。硬件容量规划包括磁盘空间、CPU、I/O等规划。软件规划包括操作系统的安装和配置规划、数据库规划、数据库对象内容和数量规划等。网络规划包括网络硬件、网络软件和协议、网络客户数量流量和分布、网络拓扑结构等规划。

   从期限上来看,应该考虑短期、中期和长期规划。短期规划的目的是满足当前日常业务的需要。中期规划主要是满足业务发展和扩大的需要。长期规划主要是满足 业务极限需要等。例如,如果预测某个系统的当前并发用户数量是1000,3年后的用户可能达到1000万,那么这时既不能按照1000用户的需求来设计, 也不能一下子按照1000万用户的需求来设计,一定要采取一个折中的形式。

  任务三:应用架构设计。

  应用架构设计包括数据库设计、应用程序设计和相应的技术架构设计。

  数据库设计应该考虑数据库的逻辑需求、数据库的创建方式和数量、数据库数据文件和日志文件的物理位置等。一般情况下,可以在Microsoft SQL Server 2008系统成功安装之后,根据规划的目标,手工创建数据库。

  应用设计应该考虑开发工具的选择、API技术、内部资源和外部资源的结合、应用架构的分布等。需要强调是在应用设计时,DBA应该与开发人员共同工作,确保他们编写出优化的代码,尽可能地使用服务器的资源。

  技术架构设计主要包括表示层、逻辑层和数据层的分布。这些分布不应该考虑到硬件资源和用户需求。既不能片面地追求过高的硬件资源,也不能仅仅局限于当前的环境,一定要按照可扩展的观点来综合考虑。

任务四:管理数据库对象。

  管理数据库对象是使用数据库的最基本、最重要的工作。这些对象包括表、索引、视图、存储过程、函数、触发器、同义词等。为了完成管理数据库对象的工作,DBA应该能够很好地回答诸如下面的这些问题。

  ● 系统应该包括哪些数据?

  ● 应该怎样存储这些数据?

  ● 应该在系统中创建哪些表?

  ● 应该在这些表中创建哪些索引,以便加速检索?

  ● 是否应该创建视图?为什么要创建这些视图?

  ● 应该创建哪些存储过程、函数、CLR对象?

  ● 应该在哪些表上创建触发器?应该针对哪些操作创建触发器?

  ● 是否应该创建同义词?

  任务五:存储空间管理。

  存储空间管理任务就是怎样为数据分配空间、怎样保持空间可以满足数据的不断增长。随着业务量的继续和扩大,数据库中的数据也会逐渐地增加,事务日志也不断地增加。存储空间管理任务主要围绕下面几个问题。

  ● 当前的数据库由那些数据文件组成?

  ● 事务日志的大小应该如何设置?

  ● 数据的增长速度是多大?

  ● 如何配置数据文件和日志文件的增长方式?

  ● 数据库中的数据何时可以清除或转移到其他地方?

  任务六:安全管理。

  安全性是DBA重要的日常工作之一。安全管理的主要内容包括账户管理和权限管理。账户管理就是在数据库中应该增加哪些账户、这些账户应该组合成哪些角色等等。权限管理是对象权限和语句权限的管理,应该回答下面这些问题:

  ● 这些账户或角色应该使用哪些对象?

  ● 这些账户或角色应该对这些对象执行哪些操作?

  ● 这些账户或角色应该在数据库中执行哪些操作?

  ● 如何设置架构?如何建立架构和对象、架构和用户的关系?

  任务七:备份和恢复。

  无论系统运行如何,系统的灾难性管理是不可缺少的。天灾、人祸、系统缺陷都有可能造成系统的瘫痪、失败。怎样解决这些灾难性问题呢?办法就是制 订和实行备份和恢复策略。备份就是制作数据的副本,恢复就是将数据的副本复原到系统中。备份和恢复工作是DBA的一项持续性的重要工作,其执行频率根据数 据的重要程度和系统的稳定程度来确定。

 任务八:性能监视和调优。

  根据企业的经营效益评价企业的管理水平,根据学生的考试成绩评价学生的学习好坏。作为一个大型软件系统,Microsoft SQL Server 2008系统的运行好坏必须得到正确地监视、评价和相应的调整。这是DBA的一项高级工作。借助一些工具和运行性能指标,DBA应该能够监视系统的运行。 如果某些运行指标出现了问题,DBA应该及时地采取补救措施,使得系统始终保持高效运行状态。

  任务九:调度作业。

  DBA不可能一天24小时不停地盯住系统的运行,及时地执行某些指定的操作。Microsoft SQL Server 2008系统提供了许多工具,DBA应该充分利用这些工具和机制,解决下面一些问题。

  ● 调度哪些作业应该由系统执行?

  ● 这些作业应该在何时执行?

  ● 如何确保这些作业可以正确地执行?

  ● 如果自动执行的作业执行失败时,应该如何处理?

  ● 如何使得系统可以均衡地执行相应的操作?

  任务十:网络管理。

  作为一种分布式的网络数据库,网络管理的任务更加的重要。Microsoft SQL Server 2008系统提供了网络管理工具和服务,DBA应该借助这些工具进行服务规划和管理网络操作。

  任务十一:高可用性和高可伸缩性管理。

  作为一个DBA,必须保持系统具有高可用性和高可伸缩性。可用性是一项度量计算机系统正常运行时间的指标。可伸缩性描述应用程序可以接受的并发 用户访问的数量问题。影响系统可用性的主要因素包括:网络可靠性、硬件故障、应用程序失败、操作系统崩溃、自然灾害等。无论是数据库系统管理员,还是应用 程序设计人员,都应该最小化系统破坏的几率,最大化系统的可用性。在设计系统的可用性时,应该确定采取什么样的可用性策略来满足可用性的需求。

  可用性的需求可以通过3个方面描述,即运行的时间、连接性需求和数据的紧密和松散要求。在确定可用性的需求时,首先考虑系统的运行时间。一般 地,数据库应用程序有两种运行时间,即在工作时间是可用的和在任何时间都是可用的。如果只是要求在工作时间是可用的,那么可以把系统的维护等工作安排在周 末进行。但是,有许多应用程序要求每天运行24小时、每周运行7天,例如,在线超市等,这时必须采取措施保证系统总是运行的。不同的应用程序有不同的连接 性要求。大多数的应用程序和电子商务解决方案要求采用可靠的网络连接。这时,要求永久性的在线连接,必须最小化各种异常现象的发生。有些应用程序允许用户 离线使用。这时,系统的可用性要求降低了。大多数应用程序要求数据是同步使用的。用户对数据的请求,系统必须立即做出回应。这是紧密型的数据要求,这种情 况必须保证系统的高可用性。有些应用程序不需要数据是同步的,对用户的请求可以延迟回应。这种要求是数据松散型的要求,这时系统的可用性需求比较低。

  任务十二:故障解决。

  虽然不希望Microsoft SQL Server 2008系统出现故障,但是故障可能是无法避免的。这些故障可能每天都会发生。有些故障是人为不小心造成的,有些故障可能是系统中的缺陷形成的,有些故障 可能是莫名其妙的。作为一个DBA,在系统中的其他用户心目中是Microsoft SQL Server系统的权威。无论是大事还是小事,DBA都应该做到迅速诊断、准确判断、快速修复。从这个意义上来说,DBA是一个数据库系统的专业医生。

posted @ 2012-04-24 16:47 顺其自然EVO 阅读(164) | 评论 (0)编辑 收藏

【工具】ANT的安装和配置(windows)

1、下载:到ANT官方网站http://ant.apache.org/下载最新版本,解压后即可。
2、配置环境变量:我的电脑----属性-----高级----环境变量
      如:ANT_HOME:C:\apache-ant-1.7.1
      PATH:%ANT_HOME%\bin (为了方便在dos环境下操作)
3、查看是否安装成功:在dos窗口中输入命令ant,若出现结果
   Buildfile:build.xml does not exist! 
   Build failed
   说明ant安装成功!因为ant默认运行build.xml文件,这个文件需要我们建立。 
4、使用:
(1)在D盘根目录下建立build.xml
1<?xml version="1.0" encoding="GBK"?>
2<project name="测试脚本" default="copyfile" basedir="." >
3   <target name="copyfile">
4      <copy file="d:/a.txt" todir="e:/Temp" overwrite="true" />
5   </target>
6</project>

(2)在D盘根目录下建立文件a.txt。
(3)进入dos,
         d:
         ant
         
         此时可在E:/Temp目录下见到文件aa.txt,内容与a.txt一样,即拷贝成功! 

好了现在我们测试下安装:点击 开始——运行——(输入cmd)——确定,在DOS窗口下输入 ant -version 命令,如果出现图1所示的画面,那么恭喜你ANT安装成功!

posted @ 2012-04-24 11:59 顺其自然EVO 阅读(2067) | 评论 (1)编辑 收藏

Windows下SVN的安装与配置

STEP 1:下载和安装

首先在Subversion的官方网站http://sourceforge.net/projects/win32svn/files/ 
去下载windows安装包,最新版。
下载后安装在本地机器上,这里注意的是最好将安装目录指定为纯英文名目录,安装在中文目录下天知道哪天会冒出一个让你想破头也想不出的错误来。
下载TortoiseSVN进行本地安装,http://sourceforge.net/projects/tortoisesvn/files/ 
这是一个将SVN集成到windows shell中的GUI管理工具,推荐使用。

STEP 2:创建储存库

安装完TortoiseSVN后提示要重启机器,其实启不启都可以正常使用了,首先创建SVN储存库(repository),可以选择命令行方式或者通过TortoiseSVN插件进行GUI操作,命令行运行如下:

svnadmin create E:\svn

e:\svn就是我指定的储存库目录,如果用GUI方式,可以在这个目录下点击右键选择[TotoiseSVN]->[Create Repository href...]进行创建,版本库模式指定为默认的即可。
repository创建完毕后会在目录下生成若干个文件和文件夹,dav目录是提供给Apache与mod_dav_svn使用的目录,让它们存储内部 数据;db目录就是所有版本控制的数据文件;hooks目录放置hook脚本文件的目录;locks用来放置Subversion文件库锁定数据的目录, 用来追踪存取文件库的客户端;format文件是一个文本文件,里面只放了一个整数,表示当前文件库配置的版本号;

STEP 3:配置

打开/conf/目录,打开svnserve.conf找到一下两句:

# [general]
# password-db = passwd
去之每行开头的#,其中第二行是指定身份验证的文件名,即passwd文件
同样打开passwd文件,将
# [users]
# harry = harryssecret
# sally = sallyssecret
这几行的开头#字符去掉,这是设置用户,一行一个,存储格式为“用户名 = 密码”,如可插入一行:admin = admin888,即为系统添加一个用户名为admin,密码为admin888的用户

STEP 4:运行SVN服务

在命令行执行

svnserve --daemon --root E:\svn
服务启动,--daemon可简写为-d,--root可简写为-r,可以建立一个批处理文件并放在windows启动组中便于开机就运行SVN服务,或者在这个地址http://clanlib.org/~mbn/svnservice/下载那个svnservice.exe文件,拷贝到E:\svn\bin目录下,再从命令行下执行:
svnservice -install --daemon --root "E:\svn\Repository"
sc config svnservice start= auto
net start svnservice
此文件会将SVN变成windows系统的一个服务,并默认为自启动,注意:执行第三句时确保前面以命令行方式运行的SVN服务已经停止,如果没停止可在其窗口中按Ctrl+C中止运行。

STEP 5:创建项目版本树

确定SVN服务(命令行或windows服务)运行后,在你需要导入储存库的目录下单击右键选择[TortoiseSVN]-> [Import...],在弹开的窗口的URL框中输入 "svn://localhost/myproject" 点击 "OK" 执行导入,如果没有报错,数 据就全部加入SVN储存库目录树上了。用命令行也可以完成这些操作,这需要你在系统变量中新建一个“SVN_EDITOR”的系统变量,变量值为本地的一 个文本编辑器执行文件路径,一般指到windows的记事本上就行了 "c:\windows\notepad.exe" ,然后新开一个CMD窗口,执行

svn mkdir svn://localhost/myproject

随即关闭记事本打开的log文件窗口后按"c"键继续后生成项目树。一般情况,我们在创建文件根路径后应该在创建三个目录:branches、tags、trunk,这三个目录是Subversion需要的三个目录。对于check out、commit、update等操作可以通过svn命令行方式执行,也可以用TortoiseSVN的windows菜单完成,非常简单咯。

posted @ 2012-04-24 11:24 顺其自然EVO 阅读(829) | 评论 (0)编辑 收藏

Ubuntu 安装subversion(svn)权限配置

1.安装
2.创建项目目录

$ sudo mkdir /home/jack/svn
$ cd /home/jack/svn
$ sudo mkdir myproject
$ sudo chmod -R ugo+rws myproject (让你的文件夹都在不同的用户下均有权限,这里你自己可以配置,就不多说了)

3.创建SVN文件仓库
$ sudo svnadmin create /home/jack/svn/myproject (创建一个库,到时apache修改虚拟路径指向此/home/jack/svn/myproject)

4.下面的命令用于将项目导入到SVN 文件仓库:

svn import -m "New import" /var/www/ file:///home/jack/svn/myproject/(可以将虚拟路径的web放入导入myproject, 这里的/var/www

是不带svn的纯程序)

5.访问方式及项目导入:
$ svn co file:///home/jack/svn/myproject
或者
$ svn co file://localhost/home/jack/svn/myproject (apache虚拟如果指向本地即可用此句)
* 注意:
如果您并不确定主机的名称,您必须使用三个斜杠(///),而如果您指定了主机的名称,则您必须使用两个斜杠(//).


6.修改配置文件
在cd /home/jack/svn/myproject/conf/目录下有三个文件:
svnserve.conf 是svn的配置文件
authz 是设置用户权限的配置文件(可自定义文件名,在svnserve.conf的authz-db = authz中指定)
passwd 是设置用户名和密码的配置文件(可自定义文件名,在svnserve.conf的password-db = passwd中指定)

    vi svnserve.conf
    修改如下:
    [general]
    anon-access = none
    auth-access = write
    password-db = passwd
    authz-db = authz

    vi authz
    修改如下:
    [/]
    jackgroup = jack
    #给myproject仓库添加一个名称为jack的用户,权限为可写。
    vi passwd
    jack = 123456

7.启动svn
   ps ax | grep svn 或 ps -ef | grep svn (查看svn进程)
   kill 2003(先终止进程)
   启动:
   svnserve -d -r /home/jack/svn/myproject/

8.在客户机安装svn客户端

1、下载地址:
 http://code.google.com/p/rails4scm/downloads/detail?name=tortoisewin32svn.msi
2. 右击svn checkout
svn://xxx.xxx.200.22/
就可以了.

posted @ 2012-04-23 17:03 顺其自然EVO 阅读(1358) | 评论 (0)编辑 收藏

仅列出标题
共394页: First 上一页 334 335 336 337 338 339 340 341 342 下一页 Last 
<2024年11月>
272829303112
3456789
10111213141516
17181920212223
24252627282930
1234567

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜