软件研发管理要求

1 总则

• 研发环境必须做好隔离

• 代码库必须使用公司统一的版本控制系统

• 代码提交记录应该遵守团队统一的规范

• 代码风格应该遵守团队统一的规范

• 代码必须通过单元测试，正式提测前必须通过自测，提高软件质量

• 新功能研发和解bug必须在本地切出分支处理，处理完成后，代码合并到主干之前应该经过code review

2 环境管理

2.1 开发环境

开发环境适用于编程人员调试程序。

• 本地调试环境依赖于共有的开发库、数据库、中间件等，环境配置由研发部门自行定义。

• 服务器开发环境需要申请独立虚拟机，虚拟机的使用和权限管理应制定主机使用规范。

  • 如对权限管理有疑问或者无法适应使用非root权限实施环境配置的，设置运维管理员处理

开发环境的代码分支，应为feature分支。

2.2 测试环境

测试环境适用于测试人员执行测试用例，包括功能测试和性能测试环境。

测试环境的理想状态是克隆一份生产环境的配置，在此环境下基于功能需求和性能指标对被测对象进行测试，暴露缺陷。

功能测试环境可利用好容器技术，以解决环境依赖问题和程序隔离问题。

性能测试环境应尽可能与生产环境相似，尤其是程序所依赖的运行环境配置，应做到完全一致。

测试环境的代码分支，应为test分支。

2.3 演示环境

演示环境适用于内部预览。

演示环境应由技术部门统一管理，技术部门应对演示环境的版本/数据控制、更新维护和状态处理负责。

• 演示环境如果有新老多个版本，应确定哪些版本需要部署，哪些可以删除；存在敏感数据的，应进行脱敏处理后部署

• 如果演示环境存在逐代更新的现象，应及时提交更新信息

2.4 生产环境

生产环境适用于正式对外提供服务的场景需求，是交付给用户的环境，发布在该环境上的程序应通过公司测试。

生产环境一旦交付并运行，应尽可能保持其稳定，减少错误的发生。任何在生产环境上进行的操作应由专业人员执行，做好备份工作，保留操作记录。

生产环境的代码，应为delivery分支，如涉及到产品实施的，应通过产品发布流程形成部署包，再交付到现场。

3 过程管理

3.1 java相关

3.1.1 命名规则

• 命名工具CODELF

• 尽量采用已有命名，保证名字可读性，减少生造词汇

• 尽量少用缩写，如有大量缩写名字，应在开发团队内形成公共约定

• 严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式

• 国际通用的拼音，如beijing、huawei等，可视同英文

• 类名应使用UpperCamelCase 风格，必须遵从驼峰形式（领域模型相关命名除外、被广泛使用的除外）

• 方法名、参数名、变量名都统一使用 lowerCamelCase 风格，必须遵从驼峰形式

  • 方法命

    • 取值类可使用get前缀，设值类可使用set前缀，判断类可使用is(has)前缀

  • 变量名

    • 禁止以下划线或美元符号开头

    • 尽量避免单个字符的变量名，除非是一次性的临时变量

• 包命名一律小写，点分隔符之间有且仅有一个自然语义的英文单词

  • [基本包].[项目名].[模块名].[子模块名]

  • 注：项目中的类、接口等都应定义在各自的项目和模块中

• 常量名采用大写，单词间用下划线隔开，语义表达完整

3.1.2 基本规范

• 代码注释应简洁明了，减少歧义

• 页面数据输入应参考各研发团队内部前端验证标准规则

• 用户请求传入的参数应做有效性校验

• 用户输入的 SQL 参数严格使用参数绑定或者 METADATA 字段值限定，防止 SQL 注入，禁止字符串拼接 SQL 访问数据库

• 生产环境输出debug日志，有选择输出info日志

• 业务日志和错误日志尽量分开存放，便于查看

3.2 python相关

3.2.1 命名规则

• 命名规则遵循如下表（引用python之父给定的命名规则）

3.2.2 基本规范

• 避免使用字母“l”（小写的L），“O”（大写的o），或者“I”（大写的i）作为单字符变量名

• 模块名、包名遵循“简短全”的原则

• 类名首字母应大写，异常名同理，并且在异常名后面加“Error”后缀

• 方法名应小写，可使用下划线分隔提高可读性

• 常量通常定义在模块级，通过下划线分隔的全大写字母命名

3.3 数据库相关

• 如果在同一物理节点上创建多个数据库，应做好权限控制，严禁在项目中直接使用管理员用户访问所有数据库

• 数据库名应与项目名意义相关

• 表名宜使用“t_”开头，表名和字段名必须使用小写字母

• 表名应采用“业务名称“+”表的作用“方式命名

• 字段名应谨慎命名，及时更新备注，尽量使用英文命名方式，不建议完全使用拼音首字母缩写的方式

4 开发管理

4.1 文档管理

• 项目/产品相关的文档编写必须遵循《软件版本管理办法》，尤其是命名规则

• 文档应通过公司质量审计过程中的资料审查流程

• 开发人员应严格以文档描述内容开展研发活动，避免口口相传，没有保留记录

4.2 需求管理

• 需求必须经过需求评审，并按公司规定做好需求管理工作

• 当需求范围发生变化时，应及时同PM讨论执行变更流程，防止需求蔓延或无故缩减

• 变更后的需求，必须第一时间同步给各方干系人，以确保工作顺畅

• （推荐）使用项目管理信息系统对研发项目进行管理

4.3 技术评审

• 开发必须经过技术方案评审，与需求挂钩，明确回答“怎么做”

• 谨慎对待技术选型，确保技术方案能够满足功能实现

5 测试管理

5.1 测试准入

• 开发人员应在整体功能自测通过后，由PM发起提测申请，多项目并行时测试部门合理安排测试资源和排期

• 提测版本的相关文档，同样应通过公司质量审计

• 提测申请应使用邮件或流程形式，有规定格式

• 测试人员获取测试版本和环境后进行冒烟测试，通过后开始执行测试

• 如果未通过冒烟测试，将退回给PM，待保证基本功能实现后，继续提测申请流程

5.2.1 文档审批要求

• 软件产品的源代码程序是经过审核的

• 提交的程序是可以正常运行或安装的

• 必要的数据库文件，比如表设计文档（表的详细字段及含义、表之间的关系图）

• 软件产品的需求说明书、研发设计说明书、原型图、相关的帮助文件，和其他必要的文件

• 需求规格说明书，需要按照给定的模板描述功能、接口、数据表、性能、安全等需求相关的例子

• 接口文档，需要区分内部、外部接口，内部接口只做正常测试，外部接口将严格按照接口测试规范进行测试

• 性能需求，基于场景的性能需求需要在需求规格说明书中详细描述

5.2.2 冒烟测试要求

• 需求规格说明书中规定的功能均已实现，且各功能模块基本流程可基本走通

• 界面上的功能均实现，比如界面上的按钮功能都要实现，符合设计文档规定

• 正确的按键响应功能

• 提示信息一目了然，通俗易懂（研发团队内部应统一前端的规范）

• 错误说明等信息提示信息清楚、明了、恰当

• 非法输入或操作应有足够的提示信息说明

• 由于误操作得到的反馈信息，应该能够知道用户便于下一步的操作

• 数据库的增、删、改、查功能均已实现，且响应速度不应过慢，最慢不应超过15 秒

5.3 测试通过标准

• 提交回归测试版本时，至少需将严重级别为一般及以上的BUG觖决掉70%以上， 且保证已解决的bug 是可回测的

• 缺陷严重级别为一般及以上的缺陷响应时间不超过3个工作日，一般以下的不得超过7个工作日