首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 软件管理 > 软件开发 >

代码定做

2013-10-18 
代码定制谈代码定制,本质上就是谈如何进行主干版本设计和进化,使个性化版本定制更容易。如果主干版本定制完

代码定制

谈代码定制,本质上就是谈如何进行主干版本设计和进化,使个性化版本定制更容易。如果主干版本定制完毕,如何个性化定制就基本上确定了。

基本原则,就是在设计的时候,考虑哪些可能是个性化定制相关的,哪些是无关的。它跟产生式编程相关。需要讨论各种设计模式技术,甚至包括到函数式编程技巧、泛型编程。

保留所有可能进行的定制为一个模块。这里不论述这些占80%工作量的前期比较高深的东东,考虑如何真正实施定制。

 

1概述

从OA门户流程“待办事宜”收到定制任务消息,然后轮到你点击提交流程的那一天起,便开始了繁杂的定制之路。

本文档的目的是帮助定制开发者,如何迅速理解并在现有最新的代码的基础上,完成版本定制;以及定制者执行的部分项目管理工作。

基本步骤如下:

需求确认 基本版本选型 代码定制和同步 bug修复 商务、技术支持反馈和跟踪


2名词解释与具体业务相关


3成员角色

从本文档读者的角度,一旦项目组成立,就会收到很多基本信息。最重要的两个信息是项目组成员列表、项目结项时间点。之后有关特定项目的所有活动,原则上只发生在其项目组内部。

一个版本定制项目,基本都包含以下成员:商务(负责提出项目、确定总体时间点)、技术支持(负责需求确认、细节时间点)、开发者、测试者。

版本定制,最不情愿联系,却有可能被联系的,就是商务人员,他们可能会催促你的开发进度。不过通常这样的催促对项目进度没什么帮助。

在比较大的项目中,会确定技术接口人,本质上就是中间件开发者负责承担部分技术支持的工作。定制该类项目,该文档就已经没什么能帮上忙的了,暂且就略过这一部分的讨论。

 

4需求确认和时间点估算4.1 需求确认

需求确认,很多都是需要综合考虑的。有可能人手不够,有可能因为标前、量产的阶段不同而测试标准有所不同。特别是时间点,其实是可以跟商务和技术支持协商的。关于如何预估整个项目完成所需的时间,这个点很重要,下面用有更详尽的讨论。

根据目前的需求模板,应用比较成熟的平台有WindowsPC平台、Android、IOS、MacOS、Winphone,比较新的平台有Win8/RT。

4.2 时间点估算

时间点估算本属于需求分析的一部分,所以和需求确认放在同一个章节。因为比较重要,单独列出来。时间点估算只对目前应用比较成熟的平台进行。每个需求从确认到开发再到可能包含的测试开发,最后测试,都要经过这三步。根据需求文档内非模板默认需求的需求总量,累计到总预估时间。

根据需求类型,可以分为界面定制需求、接口定制需求、业务流程定制需求。界面和业务需求又可以分为高级、中级、初级三种难度水平。

除满足需求文档规定的内容之外,目前不得不考虑的实际情况,就是代码管理,包括频繁更新、合并、调测。这部分没处理好也可能引入bug,甚至是编译问题,花费大量的时间。这部分所花费的时间,只能根据更新内容涉及的文件数多少、文件类型(例如安装包内配置文件、工程配置文件、代码文件)、代码层次深浅粗略估算。

然后是沟通成本。包括和测试沟通,确认bug情况;和技术支持沟通,确认需求;联调。这部分的消耗也是跟以上所属三种需求类型的时间消耗基本成比例的。

可以根据以上因素设计一个表格,总结一个经验公式。下面给出个人理解的范例如下:

等级      类型

UI

接口

业务

初级

0(基本忽略不计)

0.1

0.5

中级

0.5

0.5

1

高级

不定

不定

不定

注:

1、  单位:天/个   

2、  定制时间=(UI+接口+业务)确认和开发+打包+测试+沟通+零余+预留

3、  沟通时间=((UI+接口+业务)确认和开发+打包+测试 )* 系数

4、  不定的部分需要专家评定预估

 

5基础版本选型

这一块可讲的内容不多,具体是实际应用。有一个适合的基础版本,可以省去很多开发、测试工作。因为很重要,所以单独列为一节。

根据最新项目情况找一个比较完备、成熟的基础版本。

 

6其他策略细节

6.1任务协同

做计划,列关键路径。如果人力、设备与其他项目有冲突,需要协调。举例说明,最常见的计划就是边确认需求边进行开发;越到要上线,越需要频繁发布安装包进行回归测试。

6.2Bugfree维护

1、  建项目、添加项目相关成员(技术支持、测试、开发人员都应该有权限,管理层人员也有查阅权限)

2、  Test Case分为几类:需求文档、安装包、测试工具、测试报告

3、  Bug发布,需要包含测试机编号、平台版本、安装包版本、可以重现的要简要说明重现步骤

4、  Bug修复,需要说明原因,Fix/Postponed/By Design等

5、  Bug关闭,只能由测试人员决定

6.3代码同步

如果变化较大,不要轻易更新。先完成功能,然后备份,再更新。每改动一处代码,需要注明是新增需求还是修复bug。如果是新增需求,需要说明项目缩写、需求文档版本号和需求编号。因为需求编号可能因为需求文档的变动而改变,需要作简要注释说明。如果是修复bug,需要标明项目编号和bug ID号。

6.4技术支持反馈和跟踪

根据项目周期,分为标前测试、量产上线两种。每周定时需要跟技术支持联系,确认项目反馈,直到技术支持宣布项目结束为止。不过这种现象基本不会出现,硬软件基础设施总在更新,客户的需求也会更新。

 

7代码结构

7.1基本代码结构

7.2Windows平台特性代码结构

暂略

7.3Android平台特性代码结构

暂略

7.4IOS平台特性代码结构

暂略


8配置说明

定制的主要工作是修改配置。

8.1总体配置步骤

按配置模块,分几步,据实际应用而定。

按配置层次,分三步:资源文件配置、配置文件配置、代码配置。

真正实施时,大步骤按照配置模块、小步骤按照配置层次,依次配置。其中资源文件的配置就是直接覆盖掉参考基础版本中对应位置的图片和图标资源即可。所以下面讲到配置模块时,忽略对资源文件配置的讨论。

对于代码配置,高级业务需求由于不具有普遍性,也不在此文档的讨论范围内。

8.2模块配置8.2.1配置文件配置:8.2.2代码配置:

热点排行