當產品/後端/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