技术部项目实施流程规范：

一、需求评审

参与角色：各组 Leader 或研发工程师

规范要求：

• 每个项目（不管多小的迭代，包括技术人员发起的优化需求也要产品人员参与）都要有个产品经理或运营人员来牵头

• 需求评审时，对模糊不清的产品需求，评审 Leader 应拒绝此需求进入后续迭代流程

• 需求评审后，参与评审的技术人员要和产品方对需求达成一致，知道需求最终交付目标

• 需求评审后，各组 Leader 应规划好需要哪些研发人员进入项目

二、需求讲解

参与人员：研发工程师和测试工程师（评审完成的需求研发 Leader 可以不参与讲解过程）、UI 设计师

规范要求：

• 参与评审的研发 Leader，应提前预约产品经理讲解需求时间，并要求至少产品经理至少提前 30 分钟发出原型给参与讲解的研发工程师

• 需求讲解时，（期望产品经理能讲解本次需求的背景、目标以及未来的收益）工程师对模糊不清的产品需求，可以事后反馈 Leader，如确实不清楚应拒绝此需求进入后续迭代流程（这种情况应追究评审 Leader 的责任）

• 需求讲解后，工程师要理解需求，并知道需求最终交付目标

三、技术方案评审

参与人员：研发工程师

规范要求：

• 研发 Leader 要确定出参与技术方案评审和 CodeReview 的人员

• 参与开发工程师需要将技术方案写在 WIKI 上，不要求画精美方案图，但方案描述要清晰明白

• 参与开发工程师需要至少提前半天将需求相关原型以及技术方案发给参与评审工程师

• 参与评审工程师要在评审开始之前，提前了解需求内容和技术方案，对需求理解不清的部分或技术方案里描述不清的部分，应提前找工程师沟通

• 整个技术评审过程中，不用再复述需求功能而应该直接开始方案评审，并且控制评审时长在 1 小时之内，最好是半小时

• 技术方案评审完成后，相关人员应一起制定出本期需求对应的 Task 拆分和 Demo 时间预估

四、编码开发

参与人员：研发工程师

规范要求：

• 按 Task 拆分进入开发过程

• 代码要求要自解释性，做什么功能、怎么做、为什么这样实现

• 每日或每几日参与晨会，汇报开发进度

• 有实际开发延期的情况，一定要在晨会中做出预警

• 研发工程师在项目编码进行中，应做好自测（例如写好常规单元测试）

• 项目进行中，应尽快能看到产出页面，让产品经理提前使用，确认真实数据以及使用情况是否满足需求，将那些可能发生的需求变更尽早提出来

五、CodeReview

参与人员：研发工程师

规范要求：

• 使用 gitlab 来管理项目（除非和 Leader 评估后旧项目从 SVN 迁移到 gitlab 成本过大的，暂时可以使用 SVN），代码提交认真写提交信息（避免 update，fix bug 等不知道做了什么的说明）

• 参与开发工程师需要至少提前半天将 gitlab 相关信息(含需求文档地址、技术方案地址、性能测试报告)发给参与 CodeReview 工程师

• 参与 CodeReview 评审工程师要在 CodeReview 开始之前，提前了解需求内容、技术方案以及重点步骤代码段

• CodeReview 完成后，应发出 review 邮件

• CodeReview 完成后，参与人员一起确定出需求 Demo 时间，并发出 Demo 会议邀请相关人员

Review检查点：

• 完整性：代码是否完全实现了需求文档中提出的功能需求，是否有 bug

• 一致性：代码的实现逻辑是否与技术方案设计文档一致

• 正确性：所有的变量都被正确定义和使用，注释准确

• 可修改性：代码涉及到的常量是否易于修改

• 可预测性：代码是否无意中陷入了死循环或无穷递归

• 健壮性：异常处理和资源释放，是否采取措施避免运行时错误(捕获异常)

• 可理解性：注释是否足够清晰，是否使用到不明确或不必要的复杂代码

• 可重用性：DRY（Do not Repeat Yourself）同一代码不应该重复两次以上

• 可扩展性：轻松添加功能，对现有代码进行最小的更改

• 安全性：避免诸如 SQL 注入等安全威胁,敏感数据加密存储免打印日志

• 风险：是否存在没有提及的风险

• 性能：接口提供是否性能达标，etl 处理数据速度是否达标

对于注释的要求：

第一、能够准确反应设计思想和代码逻辑；

第二、能够描述业务含义，使别的程序员能够迅速了解到代码背后的信息。完全没有注释的大段代码对于阅读者形同天书，注释是给自己看的，即使隔很长时间，也能清晰理解当时的思路；

第三、注释也是给继任者看的，使其能够快速接替自己的工作。

六、Demo

参与人员：研发工程师、测试工程师

规范要求：

复杂项目应进行 mini demo，确保 demo 正常进行

Demo 是研发工程师向需求方（即咱们产品经理）做出需求交付的过程，因此 Demo 中不应该出现重大问题（工程师和相关产品应该提前使用，带明显问题的程序不应该进入 Demo 环节）

七、项目发布测试环境

参与人员：研发工程师、运维工程师、测试工程师

规范要求：

• Demo 之后，研发工程师应尽快将程序发布测试环境

• 项目上测试环境之后，研发工程师应参与自测，不应出现明显 BUG

• 测试工程师编写测试用例进行需求测试，测试完成后发出上线要求

八、项目发布线上环境

参与人员：研发工程师、运维工程师、测试工程师

规范要求：

• 项目上线之后，研发工程师应参与自测，不应出现明显 BUG

• 测试工程师对线上做回归测试，保证需求完成质量