当产品/后端/QA/你本身说了这些话，就要警戒了！

最近分享了不少技术篇，今天来一点非技术可是在工做中也一样重要的干货，不知道是否可以帮助到刚毕业的学生(不可生搬硬套，要抽取核心点😆)。反正是真真切切写出了个人心声。以上，仅仅表明伪小编个人我的想法。

正文

以下观点不必定适用于全部场景
欢迎小伙伴踊跃补充！！

产品

一、『这个功能很简单，跟XX保持一致就行』

跟什么一致啊，小姐姐请把话说清楚，而后明确到交互稿上吧；复制代码

二、『加个小需求呗，很简单的（已经快上线了）』

一旦涉及到业务逻辑，要拉QA、后端一块儿评审，评估清楚影响范围，不怕花时间，就怕线上bug；复制代码

三、『（交互稿）这个地方要这样那样改一下』

必定要求产品更新交互稿（方便QA测试、留下证据、之后产品开发QA都有可能查阅，用处很是大），更新以后再看一看交互，确保本身的理解跟产品是一致的；复制代码

四、『这个字段/文案前端写死就好了』

不管前端写死仍是后端传，要认识到「我比较懒」这个实际状况；复制代码

若是产品要求三端/两端一致，文案让后端拼好直接传就很合适了

后端

一、『接口定义好了发给你』

必定要用NEI！没用过？不要紧，就让小哥哥来手把手的教教你；

接口定义好以后，要先对一遍，有问题能够立刻修改，避免开发过程当中发现缺乏字段，或字段不便于使用；复制代码

二、『别急，接口我就快整理好了，今天必定能给你（开发N天后，后端进度>50%）』

先定义接口再开发是原则问题。不单是口头定义，而是在NEI上详细的定下来。若是实在定不了，能够先定个v1版，后面再进行调整；复制代码

三、『sortType为0是综合，2是新品，5是价格，balabala』

业务逻辑尽可能封装到后端，前端模块尽量通用，只负责根据后端数据进行渲染，尽可能与业务逻辑解耦（尤为是已经/将来会通用的组件）。

在这个例子中，价格(sortType===5)是一种交互效果，其余的是另外一种交互效果，那么要求后端经过新增一个字段，对这两种交互进行区分，前端就不须要关心sortType的具体含义了；复制代码

QA

一、『部署失败了，你看看[.png]（**.java报错）』

对于容易分辨归属（先后端）的问题，教会QA如何分辨它们，当他的分类能力提升，对全部人（尤为是本身）的效率提高都颇有帮助。还能够教给他们如何经过查看同步/异步数据定位问题；复制代码

二、『模块A我测出来个bug，你改一下，（一个小时后），模块C也有问题，你再看看』

建议在互相不影响的状况下，A模块测出问题后，先测试其余模块/页面，最后一块儿交给开发来修改，这样会减小打断开发手头的工做，QA也能够集中精力测试；复制代码

本身

一、『qa妹子好，我这里有个小改动但愿搭车上线』

搭车上线：代码提交到QA的另外一个任务的分支中，一块儿上线
通常不建议搭车，单独提个任务拉分支很难么，还能提升表面上的业绩呢；复制代码

二、『这个任务咱们自测（开发自提需求）』

自测的任务在codereview/resolve以后，要尽快跟QA要测试资源测掉，避免QA觉得你已经自测过，而将未测的代码上线；复制代码

同时：开发自提任务JIRA描述标准，须要有下面几块内容：

• 背景和目的
• 任务内容
• 其余注意事项

未完待续，欢迎补充！！by tianyanan