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

正文

如下观点不一定适用于所有场景
欢迎小伙伴踊跃补充！！

产品

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

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

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

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

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

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

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

无论前端写死还是后端传，要认识到「我比较懒」这个实际情况；

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

后端

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

一定要用NEI！没用过？没关系，就让小哥哥来手把手的教教你；

接口定义好之后，要先对一遍，有问题可以马上修改，避免开发过程中发现缺少字段，或字段不便于使用；

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

先定义接口再开发是原则问题。不单是口头定义，而是在NEI上详细的定下来。如果实在定不了，可以先定个v1版，后面再进行调整；

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

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

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

QA

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

对于容易分辨归属（前后端）的问题，教会QA如何分辨它们，当他的分类能力提高，对所有人（尤其是自己）的效率提升都很有帮助。还可以教给他们如何通过查看同步/异步数据定位问题；

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

建议在互相不影响的情况下，A模块测出问题后，先测试其他模块/页面，最后一起交给开发来修改，这样会减少打断开发手头的工作，QA也可以集中精力测试；

自己

1、『qa妹子好，我这里有个小改动希望搭车上线』

搭车上线：代码提交到QA的另一个任务的分支中，一起上线
一般不建议搭车，单独提个任务拉分支很难么，还能提高表面上的业绩呢；

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

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

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

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

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