个人认为软件开发工程师应该注意的几个问题

【原创】个人认为软件开发工程师应该注意的几个问题

2007年06月09日 星期六 下午 07:22

我到了现在的这个公司，发现他们开发并不那么规范，很多还是手工作坊，我认为软件开发应该注意这么几点： 1。应当遵守编程规范，这里推荐华为的C++编程规范 2。对于公共的定义，如配置文件，全局变量，应当写入一个文件，如Datadefine.h 3。命名要规范，全局变量应该以g_开头，类成员变量应该以m_开头 4。公共的常用函数方法应该分类别提升到一个目录级别，并且让其有自解释性 5。版本归档后代码应该严格受控，若要修改代码，应该提出缺陷单，并在代码修改的前面加入开始标记，结束出应该加入结束标记，推荐如下： // *** BEGIN *** date(1900-01-01格式) 缺陷编号 修改人 修改动作（added, modified, deleted) // *** END*** date(1900-01-01格式) 缺陷编号 修改人 修改动作（added, modified, deleted) 有必要在文件头也增加修改记录 6。每次向配置库添加、修改和删除文件或版本都要添加注释，注释建议如下： 修改人： 修改时间： 缺陷单号： 修改描述： 7。每次向配置库更新、添加文件必须要求是正确的代码 8。缺陷单应该按照如下流程：问题提出－》测试经理（项目经理）确认－》开发人员原因分析－》配置管理员CMO授权修改－》开发人员修改－》审核人员审核－》CMO收回修改权限并提交给测试经理－》测试经理指定问题回归人－》回归人进行回归－》问题提交人进行问题确认 其中任何一个环境只要通不过，就必须返回。这样确保问题的解决的同时减少新问题的引入 9。修改问题的时候除了要走问题单之外还要有详细的问题修改word文档，这个文档应该至少包含以下部分： 问题单号 修改人 修改时间 缺陷版本 问题程序在配置库的路径 原因分析详细描述 修改实施详细描述 单元测试情况，包含测试用例、测试桩（如果有），测试条件和结果 系统集成测试情况，包含测试用例、测试桩（如果有），测试条件和结果 系统测试情况，包含测试用例、测试桩（如果有），测试条件和结果 文件新增修改删除列表，包括在配置库的相对前面的路径、配置库中前后变化的版本号 测试结果 测试建议 代码、文档修改规范是否符合的选项 10。漏了一点，对于基础类型，入int   char   dobule   long 等类型，建议重新定义，以便于移植，new 和delete也应该重新定义为NEW    DELETE，一是可以预防new 和delete失败引发的异常，还便于定位内存泄漏 当然，这只是一个规范，效果如何要看大家的执行力度了，执行得好可以大大减少问题的引入，使得软件向一个无缺陷发展