前言
-
隨著環境的變遷，大家總會更換工作，有裁員的，有跳槽的，除了進進出出的老人，還有源源不斷入坑的新人。
-
很多人入職之後還不知道怎麼快速適應工作，對我而言，除去寥寥可數的同事感情，對我而言，更換工作更像是換個環境辦公。
-
今天記錄一下每次功能開發的工作流程，當然這個流程並不具有代表性，特別是與"大公司"完善的制度相比，這隻能算是給新人指路而已。每個公司的需求開發步驟都不相同，讓我們一起完善這個開發步驟，給後來者指明方向。
注：步驟是死的，人是活的，不清楚的地方及時提問，畢竟向同事提問是不收費的。
1 開發檔案獲取
- 開發之前，都會有開發檔案、產品原型說明之類的輔助資料，就算是在細小簡單的功能，基本上都會有相應的描述。如果全是口頭描訴的功能，那就？跑？！hhh
2 需求理解及準備工作
-
在閱讀需求檔案的時候，需要仔細閱讀，並且閱讀的時候，弄清楚這個功能的定位。特別是對於寫程式碼的人來說，要知道這個功能開放式屬於哪個功能模組裡面的，至少你的程式碼寫在哪裡，這個你還是要弄清楚的。
-
不論是shi山雕花，還是堆砌新的shi山，功能前後關係都要捋清楚，這個功能是新功能，還是擴充套件功能，這個功能跟其他模組相關聯的程式碼要閱讀，有關的資料表要提前捋一下。如果弄不清楚前後關係，那麼開發的功能很容易偏離實際的功能要求。
-
如果透過看程式碼，看檔案，看需求檔案，有些地方還不能理解的，也不用著急，因為後面還會有會議討論，這些需要做的就是盡力去理解，對於一知半解的地方可以去詢問其他同事，如果還是有疑問，記錄下來，開會的時候提問即可。這樣的情況我也遇到過，當時有點慌，但是開完會，我就理解了。
3 會議記錄
-
會議還是比較重要的，如果第一次開會一直蒙圈，那就要做功課複習了。
-
會議上需要明確需求功能點，開發功能點，如果遇到棘手的地方要及時提問，這時候還有不理解的，一定要在會議上提問清楚，如果弄不清楚，開發起來會很痛苦。這時候需求的提前理解，相關的程式碼閱讀，資料庫表的提前瞭解，在這裡顯得尤為重要，不然你很可能不知道會議在聊啥。
-
會議上捕抓到的重要資訊，大概記錄下來，我的建議是開會之前帶個本子：好記性不如爛筆頭
注意：到了這一步，決定你是否能和產品同事進行有效交流
4 介面定義
- 會議開完，一般都是和前端需要定義好介面資料，入參和返回值，固定的介面結構，避免定義好的結構在後期進行大改，不然很容易阻礙專案的開發進度。
- 作為一個後端，一個原則：儘量寵前端，後端能做的事情儘量在後端去做，秉承著能不讓前端修改就不讓前端修改，你把前端寵得像個小嬌妻，你們的對接工作不就輕鬆愉快了嘛。一個功能的開發萬萬不可離開前端，否則就是一個人玩過家家了，有修改的地方，及時通知到位，別到最後，直接甩檔案給到前端，這無疑會增加雙方的工作量。
- 如果還沒有專門的介面工具類，所以和前端整理好介面結構之後，最好自己整理一遍，這樣開發的過程中才不至於模凌兩可。
注意：很多後端後面和前端同事鬧得不愉快，就是因為這裡的基礎沒打好。
5 程式碼開發
- 程式碼開發之前，需要明確自己的程式碼是基於哪個分支去開發的，怎麼明確？問唄！大家都會問，那我就把目前的開發分支資訊給截圖一下。千萬別盲目參考檔案，有些檔案寫完之後就從不更新了。所以你需要去和同事或者領導多多交流。儘量弄清楚每個分支的作用，這樣有助於我們後面的工作進行。
- 功能開發完成，需要在本地除錯一下，大多數時候我都是用 postman 請求一遍自己的介面，看看入參和返回值是否一樣。一般我們除錯，都是把免登陸開啟，專注看介面功能就行。免登陸只需要在介面上加上：@NoLogin 註解即可 。至於單元測試，每個人根據自己的情況來定，這個不好言語。
6 程式碼提交&環境構建&前後端聯調
- 程式碼開發完成，需要提交到test分支，與前端進行聯調(或者在本地聯調也可以)
- 程式碼提交後需要藉助 jenkins 進行環境構建(這一步每個公司不一樣了)
7 程式碼稽核&釋出檔案編寫
- 釋出完成，就等前端聯調完成即可，工作完成之後需要書寫釋出計劃檔案以及找人幫 review 程式碼。
到這裡，作為後端開發的主要工作就差不多完成了，剩下的是不斷測試，修改bug，釋出，後面的步驟每個公司具體執行都有差異。最後就是提交程式碼，合併到master，但是我們也不一定有合併許可權，根據實際情況去處理。到這裡，基本上就完成一個功能的開發了。
結尾
- 好像說完了，好像又沒有說完。這裡主要還是作為一個後端開發，去"幹活"的一個角度描寫，當然，我是不希望大家止步於文章這裡。比如很多時候，我們需要根據產品檔案寫一篇自己的技術檔案，然後做一下技術評審，或者是各個環節中的跨部門交流的能力顯得尤為重要，這裡往往能提現出一個人的強大與否。最後祝大家事業有成節節高~