背景:产品经理给了一个需求,直接哐哐哐敲代码?错! 如果没有一个正确的思绪,写出来的都是 坑,是屎。是给自己的猝死埋下了伏笔
从业几年,总结了一下自己的错误操作,以此记录,提醒自己。如果对您有帮助,欢迎给个三连~
1.参与需求评审,并且记录笔记,如果怕记不住会议重点记得录音
需求评审是我们接触一个需求的第一步,参与需求评审我们会在脑子里画出一个功能流程图或架构流程图。如果用盖房子来说,就是知道了屋子大概的样子
2.会后争取第一时间去用白话文总结一下大概的流程,找产品确认
就是说你要把你脑子里想的的大概框架,画在纸上。然后找总设计师去确认自己的想法有没有毛病,哪里有问题,哪里需要修改
3.列出对接清单
对接清单,就像你盖房子需要的材料清单一样。有了这个清单,你才能明白自己需要什么配合,该找谁对接。
4.再次修改第二步提到的流程文档,争取看一眼这个文档,代码已经跃于纸上。
需要说明的是这个文档按理说是我们自己看的,但是实际上这个文档也可以给测试的同学和产品同学看,如果产品确认你的文档没问题,测试同学也可以按你的文档准备测试样例。
5.清晰思路,把文档中重要部分精简成几行注释,明白自己大概要写几个模块,然后写代码
写代码对我来说不是最重要的一个环节,
最重要的环节就是本文的中心思想 ------ 一个清晰的流程文档
只有自己对流程理解的透彻,写出来的代码才会么有bug。
注意身体,杜绝996从我做起。-- 橘子