最近分享了很多技術篇，今天來一點非技術但是在工作中也同樣重要的乾貨，不知道是否能夠幫助到剛畢業的學生(不可生搬硬套，要抽取核心點?)。反正是真真切切寫出了我的心聲。以上，僅僅代表偽小編我的個人想法。

正文

如下觀點不一定適用於所有場景
歡迎小夥伴踴躍補充！！

產品

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