软件开发生命周期

1需求及设计阶段
1.1需求分析
工作目的：站在技术角度分析产品需求的可行性方案
沟通对象：产品经理
使用工具：Xmind、Excel、Word、Visio、电话、CPC、腾讯会议
操作步骤：（系统操作须有图片）
1、需求必须是可核实、可以落地、可以执行：必须有一个可观察的结果
2、站在技术角度分析需求的可行性，是否可以提供更优的解决方案
1.2需求评审
工作目的：评估需求的合理性、完整性，产研测三方达成一致
沟通对象：产品经理、测试工程师、UI设计工程师
使用工具：会议、电话、CPC、腾讯会议
操作步骤：
1、评审前
1）产品经理下发迭代需求，研发组长进行组内安排，需求分析；
2）理解需求内容，调研可行性方案；
3）总结并记录需求疑问点，在需求评审会中进行提问；

2、评审中
开发人员参加需求评审会议（现场会议或远程视频会议）
有需求不明确的地方开发人员当场提出疑问：
1)解决了什么问题？
2)提升了什么指标？
3)有什么商业价值？
4)需求的疑问点？
如评审过程中发现需求有遗漏，需要进行补充，若涉及需求变动较大，则进行二次需求评审会议；
开发人员也需要思考产品需求是否合理，可适当提出自己的产品意见；

3、评审后
需求评审后，如有需要更新需求文档的，产品经理需及时进行文档更新，更新后同步给相关研发人员、测试人员、UI设计师。

1.3项目详细计划制定
1、正常排期：需求评审完成后，研发人员将评审会议内容反馈组长，经商讨后研发组长交付排期给产品经理；
2、确定交付日期的情况：产品经理下发上线日期，经研发组长评估调取相关资源后给出排期，；
1.4技术方案设计
工作目的：提供可行性的技术方案并输出技术设计文档
沟通对象：相关开发人员
使用工具：电话、CPC、腾讯会议、语言表达
操作步骤：（系统操作须有图片）
参会需求评审后，给出需求的技术方案：
1、方案设计
1)技术选型（前端/后端框架、日志中间件、消息中间件、数据库等）
2)技术架构（组件与组件之间如何协同工作，如何部署）
3)技术难点预知（明确存在的技术难点，并确定解决方案）
4)性能瓶颈预知（明确可能存在性能瓶颈的地方，并确定应对措施）
5)上下游系统交互（明确在流程中的哪个位置，约定接口文档提供时间、接口联调时间）
6)功能模块划分（任务拆分和分配）

2、输出设计文档
技术方案确定后，输出技术设计文档，包括：总体设计、概要设计、详细设计等

1.5UI设计方案评审
工作目的：确保设计稿与需求一致性
沟通对象：产品经理、测试工程师
使用工具：会议、电话、CPC、腾讯会议
操作步骤：（系统操作须有图片）
1、参加UI部门组织的设计方案评审会，确保界面与需求一致
1.6测试方案评审
工作目的：校验三方（产研测）对需求的理解一致性
沟通对象：产品经理、测试工程师
使用工具：电话、CPC、腾讯会议、语言表达
操作步骤：
1．参加测试人员组织的测试用例评审会议，会议可通过会议室或远程会议（例：腾讯会议）方式进行；
2．对测试人员在测试用例评审时的“冒烟测试用例”，要认真倾听，并提出自己的疑问；
3．在会议中记录存在的问题，会后及时与测试人员讨论、追踪；
4．接收测试人员发送的测试用例文档；
1.7技术方案评审
工作目的：充分了解产品需求，设计出满足需求的技术方案
沟通对象：产品经理、UI、相关开发人员
使用工具：电话、CPC、腾讯会议、wiki
操作步骤：（系统操作须有图片）
技术方案确定后，需要输出技术设计文档，包括：总体设计、概要设计、详细设计、接口设计等

1、邀请相关三方系统开发、前后端开发、移动端开发、产品经理、测试人员参与技术方案的评审
2、评审过程中有不明确或疑问的地方应当场提出并解决，如遇到无法会上及时解决的问题，记录下来，会后可再进行沟通，修改或补充
3、从多个方案中选择出适合目前的最优方案
4、确定技术方案后，考虑团队现有的资源及项目的优先级，然后根据技术设计文档进行评估排期。
排期模板如下：

2开发阶段
2.1开发编码
工作目的：
编码的目的是写出高质量的代码以更好的满足业务的需求。需求评估后再进行开发内部技术评审，涉及到 数据库设计、接口设计、第三方接口交互等，同时还要考虑代码的封装性、可维护性、可扩展性等。
开发人员也尽量提供一份功能改动点的文档出来，说清楚改动了哪些点，哪些重要的点被改动了，让测试人员做好评估。

沟通对象：产品经理、UI设计、测试工程师、相关开发人员
使用工具：PHPStorm、Vscode、Navicat、电话、CPC、邮件、腾讯会议
操作步骤：（系统操作须有图片）

1、 编码
开发人员编码过程中，需要遵守团队的编码规范，同时严格按照设计文档中的技术方案执行，除了保证代码逻辑的正确性外，还需要考虑代码封装性、可维护性、可扩展性，当编码阶段发现技术方案需要调整时，需要及时通知开发经理，经过同意后才能实施，涉及到引入新框架和新技术，也需要提前跟开发经理沟通。

1）PHP编码规范
URL 请求地址采用”-“分割。
方法名采用驼峰法。
参数必须小写和下划线分割，严禁使用驼峰或者其它格式，且提交参数与返回字段名一致。
获取数据采用 GET, 添加，修改必须 POST 。
API 返回格式必须调用 jsonResult 基础方法。
错误码必须调用 ErrCode，不能直接写错误码数字。
分页采用框架自带的， 自建二维数组必须 [‘data’ => $arr], 分页条目必须使用 limit 参数。
接口返回备注信息（msg）, 必须写在 config.msg 文件。
redis 的 key 必须写在 config.redis_key 文件。
composer 安装新依赖必须写 doc/composer.txt 文件中，并说明用途。
新增定时任务，进程必须写 crontab 文件中，并说明用途。
redis 必须有设置过期时间。否则存 mysql，再缓存
model 名字与表名一致（如：表 q_user MODEL：QUser ）
请求外网地址，必须设置请求时长 2s
redis 不存储长期数据， 只用于缓存和临时数据存储

2）Mysql 注意事项
字符集 utf8mb4 排序规范 utf8mb4_unicode_ci
数据库字段必须小写 + 下划线
新表字段必须有 status,created_at,updated_at
status 状态必须 1 启用， 0 禁用
尽量不使用 NULL
查询 sql 字段必须加上表名
严禁使用 * 号查询
sql 语句必须写 model，不能写在控制器
更新、插入、删除多条数据，非日志类型必须 “采用事务”（保证一致性）

3）YAPI 文档注意事项
字段说明必须与产品文档保持一致（前端反馈核对字段不清晰）
迭代版本接口需新增版本目录 （防止混乱）
接口有变更，必须同步更新接口文档

4）合并分支事项
必须以 master 创建分支开发，且带上自己的名字和日期（feature-function-username-20221012）
发布至 master，必须先合 master 到开发分支
“测试分支” 禁止合并到 “开发分支”
“预发布分支” 禁止合并到 “开发分支”

2、代码审查
开发人员需要控制代码提交的频次和粒度，每次代码提交之后 24 小时内，需要主动联系代码审查人完成检查，组长负责检查是否执行到位。
代码审查主要审查的内容：
规范性检查（是否符合代码规范、提交备注规范等）
健壮性检查（是否陷入死循环、资源未释放等）
安全性检查（是否存在SQL注入、XSS、SSRF、CSRF、越权、文件上传等）
性能检查（是否存在未加缓存频繁连接DB，是否需要连接池）
2.2环境搭建
工作目的：工欲善其事必先利其器，通过各种环境的搭建、保证项目的顺利开发、测试、上线
沟通对象：运维
使用工具：gitlab、jenkins、阿里云
操作步骤：（系统操作须有图片）
1、开发环境（dev）
开发环境是：开发人员自己使用的测试环境，来进行开发逻辑的测试及前后端代码联调；
2、测试环境（stg）
测试环境是：开发人员前后端联调没问题后，提测后发布的供测试人员使用的环境，来进行所有业务方项目需求迭代版本进行测试；
3、预发布环境（light）
预发布环境也叫UAT环境，是一套跟生产环境非常近似的环境，项目配置、数据库连接与正式环境一致，可高度还原正式环境，可模拟线上环境对项目进行测试，更好的发现在测试环境中，因为一些限制因素而不容易发现的问题
4、生产环境（prod）
生产环境：线上代码运行的环境，真实用户直接访问，必须保证服务器的高可用和稳定
2.3开发联调及自测
工作目的：保证代码达到提测标准，为测试交付高质量代码
沟通对象：相关开发人员、测试人员
使用工具：postman、微信开发者工具、Navicat、Wiki、电话、CPC、腾讯会议、邮件
操作步骤：（系统操作须有图片）
1、根据代码规范进行开发
开发人员需要根据开发排期表中的任务清单进行相关功能的开发，如果涉及到三方接口，需要跟三方部门人员约定好三方接口文档，并按照接口文档进行开发；如果涉及到前后端接口，后端先给前端提供相关的接口文档。
开发完成后，开发人员积极主动地推动联调工作，如果遇到阻碍及时通知组长进行协调。
联调完毕后，开发人员通过Jenkins工具来部署合并代码，再进行自测，并将标准化的自测报告发给测试团队
对于有性能要求的项目，需要开发人员进行性能测试，并出具标准化的性能测试报告
自测完毕后，通过邮件方式进行提测申请，使用标准化的申请提测邮件模板

2、发布自测成功的代码合并到stg测试环境，供测试人员正式测试
开发人员通过Jenkins工具来部署合并代码，来进行提测、缺陷问题修复更新部署再测试；
测试用例评审：开发人员必须参加，避免出现测试与开发对需求理解不一致的情况。
Bug修复：开发人员及时关注 Bug 列表，快速修复迭代发布，如果测试进度存在延期风险，需要及时通知组长

2.4项目跟进
工作目的：把控项目开发进度，及时跟进
沟通对象：测试工程师、产品经理、各端开发人员
使用工具：电话、CPC、腾讯会议、邮箱
操作步骤：（系统操作须有图片）

1、与测试人员、产品经理过冒烟测试用例，保证新功能完整性，旧功能回归场景是否全，有无漏掉的场景等。
2、开发人员需积极主动地推动联调工作，同时对涉及到的主流程进行自测，保证主流程没问题，便于测试人员的工作顺利开展。
3、如果涉及到访问量比较大的接口，需要对接口进行压测，通过压测发现瓶颈所在，提早优化。
3测试阶段
3.1测试执行
工作目的：及时修复Bug和跟进
沟通对象：测试工程师、运维
使用工具：会议、电话、CPC、腾讯会议
操作步骤：（系统操作须有图片）
1、测试人员将Bug提交到jira缺陷管理平台上，研发人员收到后，第一时间进行Bug修复，并将缺陷问题状态变更；
2、如修复的Bug再次开启，研发人员再次修复缺陷问题并记录；总结经验,减少再次重启bug；
3、研发人员在接收到缺陷问题时，发现测试人员阐述的Bug描述，不在本次迭代需求内，将问题指派给产品经理；产品经理要求研发人员实现此功能，则需要评估时间，在可控范围内继续执行，若超出工期则需上报直属领导、产品经理以及相关人员进行讨论给出最终方案；
4验收及发布阶段
4.1产品或业务验收
工作目的：验收需求，为上线做准备
沟通对象：测试工程师、产品经理、UI交互设计师
使用工具：会议、电话、CPC、腾讯会议
操作步骤：（系统操作须有图片）
1、提前做好上线准备：
考虑代码合并是否有冲突，如果有冲突提前做好合并工作。
如果涉及到 SQL，提前整理出涉及到的 SQL 语句，不要临时上线出现漏掉 的情况，同时还要考虑历史数据是否需要修复。
如果涉及到后台管理系统，提前配置好 RBAC 的权限。
如果涉及到定时脚本，提前配置好 Job 的执行任务。
如果涉及到配置，提前做好准备。

2、提前做好回滚预案：
根据各自的发布系统，提前做好回滚方案，涉及到多端的提前沟通好。

4.2产品上线
工作目的：因环境不同会导致不同问题产生，保证线上功能的正常使用
沟通对象：测试工程师、产品经理、UI交互设计师
使用工具：会议、电话、CPC、腾讯会议
操作步骤：（系统操作须有图片）
1、开发人员首先确认 Bug 全部关闭，同时产品人员在测试环境验收通过，然后需要主动推动相关团队理清上线依赖和上线顺序，同时确定回滚预案，最后根据公司运维提供的发布方式，部署到线上环境
2、及时跟踪线上回归测试情况，如遇问题通过日志、线上数据等及时定位问题，并解决问题
日志监控：
容器性能监控，查看内存、CPU 曲线是否正常；
调用次数、响应时长及 HTTP 状态码监控；
异常业务状态码告警时，需要输出堆栈信息；
对外提供的接口，记录响应时间、入参、出参，需考虑敏感数据脱敏；
调用第三方服务，记录响应时间、入参、出参；
数据监控：
新增用户数监控；
发送短信数监控；
使用优惠券订单数监控；
退款订单数监控；
未支付订单数监控；
… 等等
上线后需要密切关注以上指标，查看有无超预期情况、接口超时情况、接口错误日志等
线上环境部署完成后，通过邮件方式通知产品人员和测试人员，使用标准化的上线完毕邮件模板，同时积极推动测试人员和产品人员完成线上验证，线上出现问题后第一时间通知组长及开发总监。
如果涉及到改动比较大，必须使用灰度发布，先用小部分流量测试，慢慢再开放全量
5运维阶段
5.1上线后复盘和总结
工作目的：吸取经验、提高效率、保质保量
沟通对象：测试工程师、产品经理、UI交互设计师
使用工具：会议、电话、CPC、腾讯会议
操作步骤：（系统操作须有图片）
如果需求在测试环境和正式环境，均未测试出 Bug，上线一段时候后出现 Bug，这种问题需定期复盘，复盘模板如下：