一、一般开发流程#

注意：下面介绍的只是一个比较通用的开发流程。实际上，每家公司的流程可能都不一样，甚至同一个公司不同项目的流程也会有差异。所以入职之后，一定要尽早搞清楚你所在团队的实际开发流程——比如用什么分支管理、怎么提测、开发规范、谁来部署、环境有哪些、上线审批走什么流程等等。别等出了问题才去问，早点了解心里更有底，也能避免后续因为流程问题而内耗。

二、开发流程关键步骤解释#

1. 需求评审

   评审需求是否清晰、可行、可验收。重点确认：

   • 目标是什么（为什么做）
   • 范围边界（做哪些 / 不做哪些）
   • 验收标准（做到什么算完成）
   • 技术评估：能不能做、有没有更简单的实现方式、是否需要提出替代方案，以及技术上的风险和依赖

   建议：需求评审时建议录音（线下会议）或录屏（线上会议），方便后续回顾。会上讨论的东西可能很多，光靠脑子记容易遗漏关键细节，尤其是新人，有录音/录屏回头听一遍，理解会更到位。

   举个例子：产品提出需求”在大屏上实时展示用户操作记录”。

   • 目标：让运营人员能及时看到用户行为，便于监控和分析
   • 范围边界：只展示操作记录，不包含用户个人信息；只在内部大屏展示，不做对外功能
   • 验收标准：大屏能显示操作记录，延迟不超过1分钟
   • 技术评估：实时同步开发成本高、容易出 bug、对服务器压力大。可以提出替代方案：“每5秒刷新一次”，既满足业务展示需求，又大幅降低实现难度和风险

2. 项目经理分配任务

项目经理会把需求拆分成任务，分给不同角色（后端/前端/测试等）。有些项目经理会在分配任务时顺便问你“多久能做完”。这个时候不要为了显得厉害就当场拍时间，可以更稳妥地说： “我先把需求理解清楚，把实现方案和影响面梳理一下，再给你一个更准确的时间。” 这样既专业，也能避免因为信息不全导致估时不准。

3. 根据任务进行排期

如果项目经理只分配了任务、没有给具体排期，那就需要开发人员自己先做排期。排期时不要只算写代码的时间，至少要把下面这些都算进去：

• 需求梳理/方案设计（复杂需求很重要）
• 编码实现
• 自测（主流程、边界、异常）
• 联调（和前端/其他服务对接）
• 修 bug + 回归验证
• 部署测试环境/提测沟通（如果你负责） 你可以给出一个拆解后的时间，而不是一句“我估计两天”。这样项目经理更容易判断整体排期是否合理。

4. 确认任务能否按时完成，有没有疑问

   如果项目经理在分配任务时已经给了排期，那么在排期发出来之后，你要第一时间判断：这个时间是否合理、有没有卡点。

• 有问题一定要及时沟通，不要闷头硬扛到最后爆雷，影响整个版本。
• 沟通时不要只说“有难点”，要把难点说具体：卡在哪里、影响是什么、需要谁支持、有没有替代方案。 很多你以为的难点，可能只是你还没见过类似实现——项目经理或同事一句话点一下，你就知道可以参考现有样例，复制改造就能解决。

5. 根据需求进行设计开发

   有些公司在开发前要求写设计文档（方案文档），那就按规范写并参与评审。不会写时可以找同事要一份模板参考。 如果公司不强制要求，你也可以在需求复杂时自己简单写一版方案，目的不是走形式，而是通过设计，能够对需求有更深刻的理解。

当然，开发过程中如果对需求有疑问，仍然要及时跟产品经理沟通，避免做偏。

6. 自测

   代码写完后，先自己测一遍，把低级问题消灭掉。至少要验证：主流程、关键边界、常见异常，以及日志/错误码是否符合预期。

   举个例子：假设你写了一个”根据用户ID查询订单”的接口，自测时至少要验证：

   • 主流程：传入正常用户ID，能返回订单列表
   • 关键边界：用户ID为空、用户ID不存在、用户有0条/1条/多条订单
   • 常见异常：参数格式错误（如ID传了字符串）
   • 日志/错误码：正常返回日志是否记录、异常时错误码和提示信息是否清晰

7. 与前端联调

   自测通过后，与前端进行联调，重点是把”各自能跑”变成”整体能跑”。要对齐：

   • 接口字段（名称、类型、是否可为空、默认值）
   • 入参校验规则
   • 返回结构与异常处理（错误码、提示信息）

   联调过程中前端往往也会发现一些问题（字段不一致、边界漏测、错误码不匹配、后端异常报错等），这些都需要你配合修复。

8. 提测

   联调完成后，将个人分支的代码合并到测试分支（如 test 或 develop），部署到测试环境，提交给测试团队验证。

   测试过程中大概率会发现 bug，你需要在个人分支上修复，修复后再次合并到测试分支、部署测试环境，让测试同学重新验证。

   注意：不要在测试通过之前就合并到主分支，避免有问题的代码污染主分支。

9. 代码评审（CR）与上线发布

   测试全部通过后，将代码推送到远程仓库，提交合并请求（MR/PR）到主分支（如 master 或 main），等待同事进行代码评审。

   为什么 CR 放在这个阶段？ 因为测试过程中会反复修复 bug，如果提前做 CR，这些修复的代码就没有被 review。在合并到主分支时做 CR，审的就是最终稳定版本，所有改动都包含在内。

   CR 的目的不是挑毛病，而是：

   • 保证质量：发现潜在的逻辑漏洞、边界问题、安全隐患
   • 知识共享：让团队成员了解彼此的改动，避免信息孤岛
   • 统一规范：确保代码风格、命名、结构符合团队标准

   新人必做：入职后先搞清楚团队有没有代码评审、有没有相关的开发规范（命名规则、代码风格、分层结构、注释要求等）。如果有，写代码的时候就按规范来，别等 CR 的时候被指出一堆规范问题——逻辑问题可以理解，但规范问题全是本可以避免的，既浪费评审人的时间，也显得自己不够专业。

   CR 一般关注：逻辑是否正确、是否有更好的实现方式、是否有遗漏的异常处理、SQL 是否有性能问题、是否有安全风险等。

   新人对待 CR 意见的态度：虚心接受，不懂就问。CR 意见不是质疑你的能力，而是帮你快速成长的途径。有不同看法可以讨论，但不要把意见当成针对个人，本能地反驳或找借口。

   CR 通过后，合并代码到主分支，部署到生产环境。

   上线后要做的事：

   • 观察监控和日志：关注错误率、接口响应时间、系统资源使用情况，确认服务运行正常
   • 及时响应问题：如果出现严重问题，第一时间通知相关人（项目经理、测试、运维），并评估是否需要回滚
   • 回滚优先于修复：线上出问题时，先恢复服务（回滚到上一版本），再排查根因，避免长时间影响用户

   部分公司会采用灰度发布，先让小部分用户使用新版本，确认没问题后再全量放开。

三、常见术语#

下面列出的是通用术语。实际工作中，每个公司、每个项目还会有自己的内部术语或业务术语。遇到不认识的术语，可以先百度或问大模型，如果查不到，大概率就是内部术语，直接问同事即可。

但要注意：通用术语不能靠临时查，必须提前掌握。如果连这些基本术语都不知道，和同事沟通时很容易懵，甚至露馅。

四、新人常见误区#

以下是新人入职后容易踩的坑，提前了解可以少走弯路：

1）自测只走正常流程

只测”happy path”（正常流程），不测异常和边界，结果提测后被测试同学打回来一堆 bug，反而耽误时间。

正确做法：自测至少覆盖——正常流程、参数为空/非法、权限不足、数据不存在等常见异常场景。

2）不看现有代码就动手改

拿到需求直接写新代码，不先了解现有逻辑，结果改出新 bug 或者重复造轮子。

正确做法：先通读相关代码，理解现有逻辑和设计思路，再动手。不懂的地方问同事。

3）上线完就不管了

代码部署到生产环境后就去做别的事，不看监控、不看日志，出了问题都不知道。

正确做法：上线后至少观察15-30分钟，关注错误日志、监控告警、接口响应时间，确认服务稳定运行。

4）估时只算写代码的时间

排期时只算了编码时间，漏掉了自测、联调、修 bug、写文档的时间，导致实际交付时间远超预期。

正确做法：排期时按”编码占40%-50%“来估算，留出自测、联调、修 bug、 buffer 的时间。