源代码管理办法的拟草说明
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
关于拟草源代码归档、保密、使用管理办法的说明
根据公司产品的开发情况,在开发过程中经常会存在一个项目会有多个开发人员共同开发,每个人在各自的机器上有整个软件的拷贝,并对之实施编码,分别完成各自任务之后,再通过文本比对工具将各自机器上的不同版本的软件整合到一台机器上。
在开发中会存在如下版本控制管理的问题:
1 软件代码的一致性
软件的开发、维护和升级,往往是多个人共同协作的过程。不同人对同一个软件的不同部分同时做着修改,这种行为有时会出现彼此交叉的情况。为了始终保证代码的一致性,一种解决办法是,要求修改者每次修改后都通过某种方式告知同组其他人员,或者随时对软件做整合。但是这样,一方面会增加开发人员的负担,另一方面也降低了软件的开发效率。
2 软件内容的冗余问题
软件在各自开发人员的机器上都有拷贝,并且同一个开发人员在不同时期也会在本机保留当时的软件版本,也就是说,一台机器上还可能不止一个版本。对于不同版本而言,其差别有时可能并不很大。随着时间的推移,开发人员可能对自己机器上的不同版本间具体差异的了解变得模糊不情,甚至忘记了当时为什么区分这些版本的原因,这会给整合带来麻烦。
3 软件过程的“事务性”
对于软件的某个版本,如果开发人员想要为其增添新的功能,或改善原有功能,而又担心会搅乱原来运行良好的软件。一种常用的办法,就是保留现有版本,另复制一个新的拷贝,并在新的副本上进行修改。这类似于一种事务处理,当将一系列操作做为一个事务时,如
果中间某个操作出现偏差,则希望恢复到执行事务之前的状况。而当完成修改之后,开发人员该如何处理这两个副本呢?
4 软件开发的“并发性”
由于是多人共同开发一个软件,期间出现多人修改软件的同一部分,尤其是同时修改,有时是不可避免的。对于前者,具有良好编程习惯的人员的一种通常做法是,对他人的源程序进行修改时添加必要的注释,写明修改人,修改原因,修改日期等。这种做法增加了开发人员的负担:他需要在考虑代码逻辑的同时,兼顾如何写注释,而且,不论是否是同时修改,都需要考虑提到的一致性问题,需要及时进行人工的差异比较和整合以便形成一个统一的新版本。
5 源代码的安全性
公司项目开发的成果即为源代码,如何记录编写源代码的全过程,如何保证源代码的正确性和安全性是关乎公司生存和发展的头等大事。
为了解决上述存在的问题,记录开发项目的全过程,使开发过程可追塑、可修改、可完善,确保公司研发的源代码和技术文档的正确性,经公司领导人员讨论一致认为必须将公司的研发过程和研发成果管理好,确保源代码的安全性,因此着手拟草源代码归档、保密、使用管理办法。
SVN版本控制的功能:跟踪记录整个软件的开发过程,包括软件本身和相关文档(所带来的结果是:可标识不同阶段的软件及相关文档,进行差别分析;对软件进行可撤消的修改;便于汇总不同人员所做的修改),辅助协调和管理软件开发团队。
主要特点包括如下:
1.1 空间上集中统一管理
由于采用服务器/客户端方式,尽管开发人员可以在自己的本地留有备份,但最终唯一有效的只有服务器端的那个原始拷贝。一定程度可以解决一致性问题、冗余问题。
1.2 时间上全程跟踪记录
工具将会自动记录每个更改细节,和不同时期的不同版本。一定程度可以解决冗余问题、事务性问题、并发性问题。
1.3 操作权限控制
对于不同开发人员,对软件的不同部分可以定义不同的访问权限。一定程度可以解决安全性问题。
1.4 自动或半自动
由于有工具辅助控制,可以减轻开发人员的负担,节省时间,同时降低人为错误。像软件整合这样的工作,其工作量可以相对减轻。
2 软件版本控制评价标准
对软件进行版本控制,衡量其效果的标准,归根结底有两点:效率和质量。如果版本控制最终使软件开发效率得到提高、使软件质量得到提升,那就是成功的,反之则是失败的。效率的提高比较容易理解,质量的提升则体现在:软件的一致性、冗余程度等。