龙华网站建设推广平台,程序员必备软件,社交网站,学校建立网站#xff08;注#xff1a;这个东西是2007年写的#xff0c;算是个缅怀#xff0c;或是个吐槽。所有注都是本次发布新加的。#xff09;
简介 本文讲述完全没有软件工程经验的软件小组如何借助VS VSS等工具为UNIX开发C程序#xff0c;实现在小组规模的初级开发过程。这不… 注这个东西是2007年写的算是个缅怀或是个吐槽。所有注都是本次发布新加的。
简介 本文讲述完全没有软件工程经验的软件小组如何借助VS VSS等工具为UNIX开发C程序实现在小组规模的初级开发过程。这不是TSPi或者CMM这比CMM1级初始级还要低可称之为CMM0。
目录
1 概述
2 责任和责任感
3 概念
3.1 配置和配置项
3.2 软件配置管理
3.3 基线
4 开发过程
5 松散开发的问题
6 测试和发布
7 基本开发结构
7.1 结构图
7.2 服务器
7.3 开发者环境
8 技术细节
8.1 版本控制VSS
8.2 开发工具VSvisual studio
8.3 数据库工具TOAD
8.4 数据库结构检查
8.5 UNIX SHELL 脚本
8.6 维持单一版本
8.7 避免绝对依赖关系
8.8 记录变更历史
8.9 自动版本升级
8.10 版本标识和检测 1 概述 CMM对于内地大多数软件公司来说仅仅是老板用红包当然少不了吃饭和旅游兑换的一块牌子而项目负责人和程序员仍然在无序开发的泥沼中挣扎、应付永远做不完的需求和BUG。 我听过很多的言论表达“软件文档是毫无意义的”这样的观点。我相信大多数程序员都对此心有戚戚焉我个人的经验也同样在部分层面支持这个观点。 软件工程错了吗 是的软件工程错了如果你只是想得到软件的好处。 软件工程是一套标准和方法标准和方法本身并不能带来任何利益每个标准和方法都有适用的基础条件和成本付出只有正确地实施才会获得好处。 很多程序员都喜欢玩CS有两款典型自动步枪不能区分冲锋枪和自动步枪的请保持沉默AK47AK74和M4M16这两种步枪孰优孰劣简单地说M4(M16)是高精尖武器仅其塑料材质就可以吓退大多数仿制者低后坐力、高精度昂贵、复杂、精密、易损坏只能由受过专业训练的士兵使用并且需要后勤支持看到美军在伊拉克把安全套套在枪口上以避免沙子进入导致卡壳吗AK47(AK74)则是简单武器精度很差廉价、耐用、无需维护风沙海水都不怕最适合沙漠、山区的恐怖分子使用。对恐怖分子而言M16是毫无用处的塑料垃圾。 好了恐怖分子们拿起AK准备战斗。
2 责任和责任感 每个人都有责任就是每个人都没有责任。 管理者是承担管理责任的人小组负责人是管理者带徒弟的师傅也是管理者。 甚至于每个人都要管理自己的程序、文档、mp3和游戏每个人都是管理者。当然我们不会把希望寄托在每个人身上因为——每个人都有责任就是每个人都没有责任。 任何把希望寄托在人的自觉性上的人都不能成为合格的管理者。 作为小组负责人必须对全组负责。作为从零起步的开发小组项目能否顺利进行完全取决于小组负责人的能力。 下面列出对小组负责人的要求其中有些要求对个人能力是一个巨大的考验。 要掌握每个成员的技术能力正确地分配任务。要能够估计成员完成任务的所需的时间。 要了解完成任务所需的技术知道从何处取得相关技术的资料。高级管理者并不需要成为每项技术的专家越是低级管理者则越是要精通技术。 要在心里正确估计进度正确地估计代码质量。要估计测试和返工所需的时间。 要把握总体设计检查任何影响其它模块、其他人的设计和变更。 要查看所有人的代码要求代码风格尽量符合小组负责人的习惯。 要有安全意识主动发现并预防可能发生的意外事件。 要了解下面章节所提到的概念和技术。
3 概念
3.1 配置和配置项 “配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此“配置”包括了即将受控的所有产品特性其内容及相关文档软件版本变更文档软件运行的支持数据以及其他一切保证软件一致性的组成要素相对与硬件类配置软件产品的“配置”包括更多的内容并具有易变性。 受控软件经常被划分为各类配置项Configuraion items, CIs这类划分是进行软件配置管理的基础和前提CIs是逻辑上组成软件系统的各组成部分。比如一个软件产品包括几个程序模块每个程序模块及其相关文档和支撑数据可能被命名为一个CI。一个系统包括的CIs的数目是一个与设计密切相关的问题。一个纯软件的CI通常也称之为软件配置项CSCI。 现在所有的配置管理工具均提供对配置项的管理工具包括(Check in和Check out机制的 )版本管理和版本标号功能。由于版本和标号管理比较繁琐一般推荐使用配置管理工具减少事务性工作。
3.2 软件配置管理 软件配置管理是贯穿于整个软件过程中的保护性活动它被设计来1标识变化2控制变化3保证变化被适当的发现以及4向其他可能有兴趣的人员报告变化。
3.3 基线 基线baseline是配置项的稳定版本是进一步开发的基础。一般一条基线包含一组配置项在所有包含的配置项确认通过后测试或评审通过基线形成基线一般采用更高级别的变更保护。 基线概念反过来解释就是一项工作所依赖的所有配置项。比如一个新模块的开发依赖公共组件并需要与特定模块交互那么新模块所依赖的基线至少要包括公共组件的特定版本、与特定模块交互的接口协议的特定版本或者特定模块的特定版本。 一般开发过程中我们通过打标签的方式标识基线并尽量避免复杂的的基线划分。
4 开发过程 基本的开发过程分为设计、开发、测试、发布。发布是把软件和文档打包提供给客户的过程该过程较简单技术性不强不多讨论。设计是难度最高的过程通常只是在头脑里模拟完成不会有成文的输出我们偷懒省去了设计过程至于更无法掌握的需求根本不必提及。剩下的开发和测试是实际看得到的环节通常我们制定项目计划只考虑开发和测试。 更现实一点说多数的项目开发过程的开发和测试是混在一起的开发人员在开发时自行测试自己的程序没有独立的测试过程。 作为项目开发过程化的第一步要形成版本概念与基线概念相关。版本是妥善保存的成为追溯的依据。经常发生这样的情况新版本测试发现问题需要用旧版本检查以确定问题是新版产生还是旧版原有的然后需要对比版本以寻找问题所在。 项目过程化的第二步是要有独立的测试过程。独立的测试过程不一定要求专职的测试人员开发人员可以互相测试。一定要在版本上测试不能边改边测。发布的版本必须是测试通过的完整版本不能是发现错误修改后只测试了出错点的版本BUG修改经常在其他地方产生意想不到的错误。 以上两步是最基本的是小组范围内能够自行掌握的。形成版本使过程控制成为可能独立测试则显著提高产品质量。 版本化原则上并不需要任何额外工具在有版本控制工具以前可以做手工的存档。版本控制工具可以提供较好的版本管理但不能偷懒把发布版本放在开发库里尽管发布版本总是对应一个开发版但管理上要求发布版本与开发版本脱离。版本控制工具可以提供较好的过程管理能够明确产品包含的有效源代码、文档能够控制同一个文件的修改冲突能够检查项目、文件所发生的变化给小组负责人控制项目提供有力的支持。 独立的测试过程给软件质量提供一个可信赖的过程保障开发者自测的局限性非常大这是心理学原因不是靠工作态度可以解决通常交换测试就可以发现大量简单错误。在有独立测试部门的情况下一般开发组提交给测试组的代码已经是经过开发组内部测试的版本否则BUG太多面子上不好受并且会影响奖金。
5 松散开发的问题 松散系统是由大量非紧密相关的部分组成的系统各模块在大多数时候可以互不干扰地独立开发但少数情况下需要修改公共部分。 由于多数情况下各自开发不需要交互长时间以后导致每个人对公共基础一般主要是数据库的掌握不足。每个开发者都可能根据自己的需要增加了一些表不同的开发者可能重复开发了相似的功能不同的开发者可能对同一个数据做出了不同的假定。 在维护期对生产系统的BUG修复或特殊需求经常直接在生产系统上进行因为问题经常与特定的环境和数据有关很显然在生产系统上直接修改、测试是最快速的、最方便的方式。这种现象导致不兼容的特殊版本对后续维护造成致命的障碍。管理者应该意识到这个问题。 松散开发和维护方式实际上不是一种开发模式而是一种混乱。 在Windows环境下开发时很少所有人共享同一个数据库和同一套代码然而在UNIX上却相当普遍。究其原因可能是因为UNIX上多数都是大系统为每个人构建一套开发环境可能资源不允许开发时经常麻烦管理员也不是很方便。 短期内解决这个问题所投入的成本与带来的长远好处相比是否值得从现实看多数人的答案是“否”。 解决的办法有没有当然有。但的确不是很省力的一方面需要掌握多方面的技术另一方面要投入人力资源进行控制。技术面和技术深度对内地从业者来说都是薄弱环节。若要加强控制就必须存在一个人对所有变更进行审查确保所有变更都被统一记录以便其他人能够知晓。小组负责人应该亲自进行控制小组负责人是唯一可能同时具有足够技术、权力、职责和责任心的人。 本文所提及的技术细节都是在数年里逐渐解决的解决之前觉得很麻烦解决之后觉得不过如此技术问题从来如此。多数技术要求对管理都有很大的作用是因为有管理需要才引入这些技术。 应付同一个模块每天三次的紧急修改需求是不可能的如果这样的事情发生我们只能说质量已经失控。 对于突发的故障的维护可以采用紧急处理策略直接生成一个特殊版本解决问题毕竟生产系统的故障必须尽快解决然后再将特殊版本的修改并入正式版本。在生产系统直接修改不并入正式版本会导致最后产品不可维护这是要通过制度才能解决的问题。
6 测试和发布 软件发布的版本必须是测试过的版本中间不能有开发人员介入。作为管理者不能信赖过程上不可靠的东西。 软件发布应尽量完整发布不得不频繁发布小模块的时候必须谨慎小心避免差错。 必须严格按照测试通过的顺序发布必须严格按照发布顺序实施更新。 小模块发布时小组负责人必须仔细检查变更细节以确保不会产生模块冲突。 若与其他小组有关联则必须联合发布并且在代码中检查其它小组的模块的版本。 每个小模块的开发者无权发布模块。发布必须经过小组负责人的认可。 公共模块的修改必须在小组主要开发人员认可后进行不可随意修改。
7 基本开发结构
注由于年代关系后续提及的软件可能已经过时用同等功能的替代即可
7.1 结构图 7.2 服务器 服务器是核心。这个服务器不是开发用的主机是用来共享资源和版本管理的服务器。 共享资源包括开发用的各种软件的副本、各种技术资料以及其他对团队有意义的东西。 版本管理一般都采用VSS需要把VSS数据库目录放在服务器上共享。使用CVS可能无法顺利完成所有需要的工作。 需要一再强调的就是只有入库的东西才被承认。声称代码写完了但是忘了入库的人一律扣发当月奖金并全组通报批评。
7.3 开发者环境 每个开发者拥有自己的开发环境以避免开发干扰因此需要在UNIX主机和数据库建立独立的用户。如果不能做到至少保证两个用户一个用来开发一个用来测试。 推荐开发者使用VS或其他集成开发环境。集成开发环境提供的辅助功能会极大地提高开发速度和代码质量。 可以统一使用VS作为开发环境配合FTP工具上传。如果全部统一用VS则还可以使用VS直接访问VSS。用VS直接访问VSS与手工访问VSS相比较少犯VSS操作错误。 每个开发者使用独立的开发环境有助于使开发者明确认识到完成的代码必须入库。独立的测试环境也有助于开发者养成详细记录数据库变更的习惯。
8 技术细节
8.1 版本控制VSS 版本控制通常使用VSS或者CVS。使用版本控制的目的在于限制代码的随意修改、追溯代码的修改过程。就概念而言VSS更符合版本控制概念使用者能够形成正确的版本控制观念。 版本控制软件维护一个库存放代码每个开发者将代码取回作本地开发然后将代码放回代码放回后其他开发者才能看到。 每个人都必须正确掌握VSS的使用培训是必要的。 VSS默认配置为不允许多人签出这正是我们需要的。每个人都需要设置对项目操作的递归选项这样可以连同子目录一起操作。签入文件后应查看历史或比较文件以确认签入正确。 熟练掌握目录比较和查看历史对每个人都很重要。
8.2 开发工具VSvisual studio 建立C Win32控制台项目空项目。 将项目文件添加到项目中建立与实际目录结构一致的VS文件组织结构。 如果有头文件需要配置搜索路径才能访问则设置项目的“附加包含目录”。否则无法解析头文件不能提供类型帮助。 如果不使用VS整合的VSS访问则每个开发者都要重复这些工作。如果把项目文件放在VS的项目文件之下的子目录此时VS项目文件存储代码文件的相对路径则可以直接复制VS项目文件给别人用。 如果使用VS整合的VSS访问则使用VS的添加到版本控制的功能将项目添加到VSS其他人用VS的从版本控制打开项目即可。 VS不提供FTP功能需要同时打开一个FTP软件来上传源代码。如果愿意可以对VS做二次开发来简化操作。 VS提供的最大帮助是即时解析源代码提供变量、函数说明、类成员的信息等。VS提供的查找、替换、格式化功能也是很强大的。有经验的使用者可以写出一次编译通过的代码呵呵绝不是无BUG。
8.3 数据库工具TOAD TOAD能提供数据库的脚本、数据脚本、数据库变更脚本能做全用户的导入导出。 导出的数据库结构脚本可以入库进行版本控制。可以用数据库脚本或数据库备份重建开发者环境。 对数据库的变化应该提供变更脚本。 所有用户共享一个库的风险是很大的一个人的误操作就可能毁了一切。
8.4 数据库结构检查 标准的数据库结构检查是查询数据库数据字典。数据库数据字典是一组视图可以查询所有的表、列、约束、同名词、序列、过程等的详细信息。 复杂的程序可能需要查询数据库结构来确定操作如何进行这是完成一些自动维护任务所需要的。
8.5 UNIX SHELL 脚本 编写复杂的脚本可以执行很多复杂任务。比如自动检测机型、判断主机资源状况、执行数据库脚本可以配合复杂的sqlplus脚本检查数据库结构、根据实际情况执行不同的编译过程或其它程序等等。 整个项目保持为同一个软件包用单一方式编译执行是很有价值的。脚本至少可以做到根据机型使用不同的配置文件、根据参数自动选择合适的优化开关、自动处理特殊的预编译宏、自动执行数据库检查脚本。 Shell编程的关键是掌握返回码的处理和条件逻辑这样就可以有机地把命令组织起来像个像样的程序。
8.6 维持单一版本 不同厂商的UNIX环境有很多差异尽可能选择通用的语法避免编译问题。无法避免的可以用宏开关来处理。对宏开关要能用编译脚本自动处理手工处理容易出错。 有时不同用户会提出冲突的需求优先选择通过配置实现实在不方便的可以用开关实现但最好不要用宏开关用全局变量开关比较好。 可以建立一个系统表记录用户信息程序启动时初始化全局变量程序根据全局变量决定特殊处理。
8.7 避免绝对依赖关系 任何一个系统都应该避免对环境做过多的假定不依赖特定的用户、目录、端口、系统Key之类的东西。当系统发生问题需要调试的时候很可能需要在正在运行的系统的“旁边”建立测试系统比如在另一个目录用不同版本的代码编译执行或者希望程序将输出输出到一个临时位置。设计时考虑调试需要可以方便后期的工作。
8.8 记录变更历史 项目必须有一个文件记录变更历史由每个变更实施者填写。该文件可放置在项目根目录下。记录每个变更的时间、人员、原因、方案、变更的项目、相关影响等特别是数据库的结构变化。每个变更顺序编号。 小组负责人将随时检查变更历史。
8.9 自动版本升级 软件升级应当简单执行一个程序或脚本即可不要让用户去执行琐碎的修改。 对开发而言同步不同的开发环境也需要这样做。
8.10 版本标识和检测 软件应标识自身程序执行首先应显示版本信息。每个模块都有自己的标识。 应检查数据库结构和软件的预期是否一致。不一致时程序必须拒绝执行。 对相关模块版本也应同样检查。 这里是结束
