文档简介📚： 在开发需求过程中需要注意的各个方面，从交付时间的管理到与产品、设计、测试同事的沟通，再到上线前后的注意事项。
每一条建议都是我在实际工作中积累的经验和血泪教训😭，旨在帮助你更高效地完成任务，避免常见的坑。
文档涵盖了开发需求、测试相关、上线相关等多个方面，详细介绍了每个阶段需要做的事情和注意事项。希望内容能给你一点点帮助，快速提升自己的工作效率和质量💻。祝工作顺利！☀️
开发阶段注意事项：
开发需求相关：
1. 交付时间是第一关注点。 与产品沟通好需求的截止时间与发布时间，截止时间是定死的还是可变动的，如果是定死的，需要尽快给出工作量估算，留足缓冲时间，避免延期；如果可变动，根据时间的富余程度，可以与产品进行讨论，合理安排开发周期。
2. 职责清晰。 在提测&产品体验前，充分进行自测。第一个使用产品的人是自己，自己要全面把控质量，测试同学只是代码质量的兜底，个人对产出代码质量完全负责。
产品在上线前会进行验收，产品并不负责测试，不要把产品当测试使用，爱护产品同学。
3. 了解不同项目的发布节奏。 如果你是首次进入公司实习，需要更加关注这一条。不同项目可能有不同的发布节奏，并非开发并测试完即可立即上线。
项目一般有hotfix和固定发版的节奏，针对灰度和外网全量又有不同的时间周期。紧急的需求或bug一般会采取hotfix进行外发，如果是可以跟着固定发版的时间节奏走的需求，一定要问相关的人员该项目的发版节奏，不要错过那个时间节点。
4. 了解和熟悉需求比代码开发更为重要。需要提前预研需要的接口和API，以及清楚每个功能点不同的模块，具体的场景是什么，一定要有清晰的记录。如果需要其它模块或前端 / 后端 / 设计的配合，在预研阶段就可以提出需求，同步开发节省时间，避免上线前才发现缺失后端接口、链路不通等要命的问题。
这将极大的在测试环节节省你出bug的概率和不必要花费的时间，可以写文档来记录开发细节，同时帮助你理清思路。
5. 问题边界明确。 熟悉自己在需求中负责部分的边界，这样既方便定位问题，又可以节省时间。拿到问题之后，第一时间分辨是自己代码的问题，还是同事代码的问题，不是自己的问题，第一时间转交，如果自己时间充裕可以帮助定位问题，如果时间不充裕，优先完成自己的任务。
6. 设计UI完全还原。 对于前端开发，设计稿的还原必须达到一比一还原，是否使用响应式布局，是否要适配多端的布局，需要和产品、设计同学第一时间确认。如果你是第一次还原设计稿，请一定要谨记一比一还原的重要性，不然后期产品和测试以及测试的验收将在这里耗费你大量的时间。提一嘴，除了静态的效果，也请一并询问active、hover的动态效果。
7. 确认接口。 在确定好你需要使用的接口后，开发前询问后端相关的参数和接口，思考你所需要的参数，若后端接口无法满足，需要尽快对后端提出需求。后端接口上线后，记得清空环境，在现网环境进行抓包和调用查看，一定要清空环境，避免在测试环境中成功调用，导致给后端已成功的反馈，确保你的调用是有效的。
注意：后端接口变动无法立即发布生效，流程：后端开发 - 给前端测试环境 - 走发布流程 / 紧急发布（一定要尽量避免紧急发布，给后端生产环境降低风险），走正常的发布流程起码需要四天左右，具体时间根据各个公司来定，规模不大的话，也有可以迅速发布的。
8. 及时求助。 时间不充裕的时候，半个小时没有搞定就需要去求助，如果时间足够充裕，可以自己慢慢研究，切记研究不等于做无用功。为了在既定时间内完成目标，一定要使用各种办法。学会提有效的问题，避免宽泛的提问，节约你和被提问人的时间。（比如：你遇到的问题的描述，重现的环境和操作，使用的设备和软件版本，出现的故障表现，你已经做出过的尝试，问题的紧急程度等）
9. 【再次强调】对代码百分百负责。 你要让你的代码具有足够的健壮性，并且清楚的明白你每处的修改会产生什么影响，不要让他处于一个黑盒的状态。不是表面上运行没问题就真没问题。你得真的确保每处运行的先后顺序，互相之间的影响。
10. 提高代码质量 ，让代码审查人员明白每一处的用意**。**
- 复杂的地方写好注释，解释为什么要用这种写法
- 多写注释标识每处的用意。变量函数命名尽量简洁符合功能的意思。
- 避免ts-igonre的出现，尽量把每一处的类型标注好。提前可以把Merge Request提出来，因为提了MR后面也是可以改的。让导师提前进入CR阶段。不要等到最后再进行Code Review。在上线前一定切记不要再改了，除非你非常确定改动的影响。
11. 多线程运转，学会系统中断。 如果和你对接或者询问的人未及时回复你，可以先做手头的其他工作，如果影响到你的进度了，可以电话的方式直接联络，不明白的事情一定要问清楚，毕竟是你要用他负责的模块。
12. 预期管理并理解不同类角色的预期：
作用：在职场提升个人的在工作中的信用，变成更可靠的人，有及时反馈的人，凡事有交代，件件有着落，事事有回音。
a. 产品预期：
- 需求宣讲完后：希望尽快得到需求的预估开发时间
- 产品和老板之间的沟通：用户量增长、商业变现、功能灰度发布时间
d. 设计同学预期：像素级还原（提醒各种屏幕适配的问题：按比例或像素还原）
e. 测试同学预期：最好很少的Bug或无Bug（控制在五个以内）
参考身边大佬特征：
i. 基础：守信，答应的约定交付时间，一定准时交付；
ii. 中级：如果项目出问题，能推动项目往前走，给出解决方案；
iii. 高级：担任多角色任务，从多角度去审视问题，帮你解决他工作边界外的事情。
测试相关：
1. 如果测试提出的bug（如某个功能在不同的场景下有不同的应用结果）是业务上的遗漏，需要立刻和产品同步，询问她给你补全所有的信息，不要自己去找，不要自己去探索，不要自己去猜测。 即使产品给你的信息有场景遗漏，也可以在后期的测试中补上，这将比自己寻找节省大量的时间。
2. 如果你对自己的代码的场景并不完全肯定，可以找测试要一份测试用例，开发完自己先走一遍，避免后期测试提bug单，提高工程交付质量，减轻测试和产品审查的工作量。
上线相关：
- 上线前已经经过测试和走查的代码，在发布当天，一定不能有bug，而且尽量不要改动，最大程度降低引入新风险的可能。
- 上线前需要预留一整天，避免晚上发布，一定要在上线前一天完成代码的开发和测试，上线那一天只能做和上线相关的事情。
总结各阶段工作：
需求宣讲前：
- 帮助产品判断需求是否合理；
- 找到对应的仓库代码和设计稿，熟悉对应的页面和代码；
- 是否有很难实现的部分，整个流程是否可以打通（问了解的人，也可一起拉会进行探讨）;
- 分析需要合作的部分（与后台或前端的其它模块）和可以复用的部分（页面/组件）；
需求宣讲中：
- 判断需求的核心路径是否能通
- 是否需要调研再给排期（控制预期）
- 多端适配的情况要考虑
- 考虑有可能的逻辑分支并暴露（尤其是文档内没有提到的）
需求宣讲后：
- 给产品需要提前调查的时间；
- 如果产品预设实现的思路不通，带着方案和产品去聊，再去讨论最后排期；
- 时间预估：【（乐观开发时间 + 悲观开发时间 ）/ 2 + 联调时间 + 自测时间 + （组内体验）+ 测试时间 + 缓冲时间】
● 开发初期： 和后台商量好接口（最重要）、可以自己mock数据开始开发
● 开发中期： 根据开发进度判断会不会延期，顶多改一次期，不要多次改期
● 开发后期： 自测
● 体验 & 测试 & 改bug阶段
● 发布阶段： 线上自测验证
● 发布后： 询问需求效果如何（看数据，看故障率），线上效果确认
● （进阶）需求完成后： 可以再想想重头开始需要多久，看看和自己的实际使用时间相比，差了多少，75%左右比较健康。
