我走过的一段路

Page 1

中国电子论坛 www.ecbbs.com 转载我　走　过　的　一　段　路 —谈华为软件工程化历程我在华为公司工作 4 年，先后在数字程控交换机、接入服务器、综合接入设备（IAD）三个产品部工作过，担任过软件开发人员、项目经理、软件经理和软件系统工程师。在这工作过程中，我从基层开发人员的角度体验了华为在软件工程化的过程。我进入公司就分配到信令部的 ISDN 项目组，该小组 5、6 个人负责全公司的交换机、多媒体、无线产品、数通产品等各领域产品的 ISDN 模块软件开发、维护工作。由于各产品的软件存在移植关系，这么多产品的 ISDN 模块代码（特别是协议核心处理部分）也基本上相同，而彼此之间差异性则主要来自于产品形态（如对外的维护接口之类的）。其他软件模块如七号信令、数据库、网管等情况也与 ISDN 相似，形成了产品线的软件模块资源共享，而开发人员也相应按照资源线和产品线交叉的矩阵式结构进行组织管理。因而我的经历也应该具有一定的普遍性。低级别的资源共享和小作坊的闭门造车 2000 年我接手数字程控交换机产品方面的 ISDN 模块时，交换机产品已经相当成熟，在市场上大量销售。我所做的是修改原来代码的 bug 和根据市场上突发的需求进行小规模特性的增量开发。由于对原来庞大的软件系统不熟悉，这种维护型的工作实际上比从头开发一个新模块还要困难。当时没有什么可借鉴的开发文档，一开始查 bug 基本上依靠不断的加打印代码—编译连接—加载运行—加打印代码……反复的调试过程来定位软件问题，非常原始。我在转正答辩时总结的一个“重要”经验就是：多读代码。后来逐渐对代码熟悉了，才增加了代码走读和模块分析等工作方法。修改完一个 bug，根据产品线之间的共性和差异，再决定同步到其他产品线上（所谓“同步”即：如果其他产品线的代码也有类似问题，就相互参照修改，这就是所谓“资源共享”）。而需要增加或移植一个新特性，往往也是参照原来的或者其他产品模块的代码进行拷贝和粘贴，再进行修改的方式来实现。可以说，当时的软件“共享”，就是代码级的调试、同步和增量开发的“共享”。上至项目经理下至开发人员，都总是说“文档很重要”，但是一到实际的开发中，还是代码先行。当时的开发观念比较落后，总以为非得先写写代码调试出功能来，心里有底了才能开始真正的设计，结果文档就变得可有可无了。由于产品的市场需求不同，光是交换机产品在最多的时候就同时有 4 个分支版本在并行开发、维护。当时为了同步修改一个 bug，或者新增一个小特性，就要负责同时合入 4 个分支版本。可想而知，遇到稍大一点的修改，源文件一多，不同版本的源文件中的每一处差异都要仔细辨别（往往“合版本”干到半夜——夜深人静的时候好像头脑也清醒一些），其紧张和痛苦程度，到现在还历历在目。当时感到与在大学中的个人“小作坊式”的开发差别在于，需要学习和遵守一些规范：查 bug 修改问题走的是问题缺陷电子流程，合入代码则必须遵守软件基线库操作规范等等。缺陷电子流程如下：由独立的测试部对产品软件进行测试，并且在电子流程库上提交软件缺陷问题单，问题单经过测试经理审核和软件开发项目经理分发，到达相关开发人员；开发人员定位问题之后提交项目经理审核，再提交配置管理员确定修改合入的版本计划，交还给开发人员合入指定的版本代码库中；在新的版本（肯定是同时合入了旧版本中各模块修改的若干个 bug，同时可能还有新增的特性）对测试部发布之后，转测试经理组织测试人员对自己

下一页

文档基本属性
文档格式：	PDF
文档标题：	我走过的一段路
文档作者：	a
关键词：
主题：
单位：
文档创建者：	Acrobat PDFMaker 5.0 for Word
创建时间：
上次保存时间：	D:20051223134143+08'00'
修订：	Acrobat Distiller 5.0 (Windows)
点击这里显示更多文档属性
文档语言：
经理：
备注：
分类：
上次保存者：
修订次数：
编辑时间：
加密标识：
幻灯片：
段落数：
字节数：
备注：
演示格式：