最近分享了很多技術篇，今天來一點非技術但是在工作中也同樣重要的乾貨，不知道是否能夠幫助到剛畢業的學生(不可生搬硬套，要抽取核心點?)。反正是真真切切寫出了我的心聲。以上，僅僅代表偽小編我的個人想法。
正文
如下觀點不一定適用於所有場景
歡迎小夥伴踴躍補充！！
產品
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