前言
在這個春風得意馬蹄疾，金三銀四跳槽季的日子裡，相信很多小夥伴都拿到了心儀的offer了吧，其中不乏有初入職場的同學。那麼今天，我就從服務端的角度來給大家分享一些關於工作中開發流程的經驗，希望初入職場的同學儘量少踩坑不背鍋，能夠順利通過考核期。
進入公司你會發現，一般正規點的公司都會分很多部門，如開發部（科技部或研發部）、產品部（業務部）等，這兩個部門是相互對等的，也就是說後者負責產品功能的創意、設計，產品的大方向，說白了就是負責提出產品需求，把控產品的定位和走向；而前者則是需求的受理者，負責從軟體、技術層面來實現後者提出的需求。兩個部門沒有上下級的關係。
而對於我們程式設計師來說，做一個需求從接到需求到上線的完整流程大致如下：
- 需求分析（包括需求調研，需求討論，需求確定，介面確認）
- 系統設計（設計該功能實現細節，要用到什麼技術等）
- 系統實現（從軟體程式碼技術層面實現功能）
- 功能測試（包括開發自測，提交測試，業務測試）
- 需求上線（業務驗收，驗收是否通過，程式碼是否回退）
需求分析
從你拿到需求文件開始說起，你會看到需求文件至少包括2部分來闡述這個需求：需求背景和需求描述。
需求背景：
主要告訴你為什麼會有這個需求，提這個需求的目的是什麼。
需求描述：
這才是這個需求的重點，主要告訴你要實現什麼樣的功能，做成什麼樣的效果，以及一些業務規則等，可能還會放幾個頁面的原型圖，這就再好不過了。
這些都是業務部門經過深思熟慮、各級領導稽核通過後的需求，才會到研發部門，研發部受理這個需求，分給你的組長或直接分給你。
言歸正傳，你接到需求，開啟需求文件，開始看需求了。
1、快速通讀
可以先快速地通讀一遍，瞭解需求的大致意思，對需求有個整體的把握，做到心中有數。
2、抓重點、記疑問
然後第二遍，看細節，抓疑問點。
這一遍，你可以看仔細點，把一些關鍵點認真看看理解一下，同時看的時候可能會發現需求有寫的不明確的地方，或者需要確認的地方，或者你會有一些疑問，這個時候你可以把這些點記錄下來，認真讀完一遍之後，你記錄了一些問題。
3、答疑解惑
讀完兩遍之後，你有一些疑問。然後你可以找個時間拉上經理或需求負責人，開發組長，前後端開發人員，業務（提需求的業務人員，他是最瞭解需求的人）、測試負責人一起當面開個小會（能當面絕不群裡聊），去解決你記錄的疑問點，把這些需求裡你認為寫的不確定的地方弄清楚。這個過程就是答疑解惑。
在這個討論過程中，定下來的業務規則務必要記錄下來，會後可以發一封電子郵件，把需求確認的東西或者業務又新加的東西寫在郵件裡，提醒業務確認無誤後讓他更新需求文件，並且郵件抄送給一起開會的人。
為什麼拉上這麼多人呢？因為你有疑問的地方你的組長，經理等也可能有疑問，這種拍板釘釘的事不能只讓你一個人知道，到時候做完了上線了，業務發現不想要那樣的效果了賴賬不承認了咋辦。拉上測試是為了避免開發和測試理解需求上有偏差，避免測試寫的測試案例和需求要求有出入。
為什麼發郵件呢？做這一步也是為了規範開發流程以及留個底有個證據吧，防止以後問你為啥這樣做，你就有據可依了。不然你單憑嘴說：當時討論就這樣定的。這樣說服力不夠啊。我們一定要做到，不甩鍋也絕不無故背鍋！
4、準備材料
需求討論過程中如發現涉及其他系統，提出來，並確認下其他系統介面有沒有提供好，並通過專案經理向其他系統要介面文件（系統間的文件收發，最好通過系統負責人，即使都是內部系統）；另外，如涉及到頁面改動需要提供UI的，督促業務及時提供UI，防止延誤需求上線。
為什麼出UI？出UI的目的是嚴格按照UI圖的尺寸、色值來做頁面，防止到時候前端做好頁面後業務又來扣這些細節，讓你返工，還顯得你幹活不利索。假如有的公司根本沒有UI設計師，那就提前和業務說好，做的時候讓業務把把關，看是否複合他要的效果。
5、工作記錄
其次，針對該需求，寫每日工作進度（日報）時，寫上當前需求到了哪個階段（如需求分析階段，開發階段等，具體到了哪個階段，自己評估），以及當前遇到的阻礙等。這樣如果有阻礙，即使是延誤了上線，也不是自己的原因。
注意：1、系統間介面聯調大概需要1-2天，複雜的介面可能需要更長的時間。系統聯調最好放在系統設計前，這樣可以發現介面返回內容是不是滿足這個需求，並提出這個問題。如果你開發的時候用到這個介面的時候再聯調才發現問題，那不是耽誤時間了嗎。
2、假如第一次呼叫該系統，還要注意開通系統間的網路，不然無法訪問。開通網路當然也需要專案負責人來申請。而且一定要測試環境和生產環境的網路一併開通，開通後並測試是否真的已經開通。這樣防止沒有開通網路，上線後調不通，又臨時火急火燎的發郵件申請開通網路，這樣只會讓你難堪，顯得你這個人不夠仔細。
系統設計
需求分析，介面聯調，開通網路等一些準備工作及雜事處理完後，就可以開始系統設計了或者邊處理邊進行系統設計（因為你等著出UI、開網都需要時間）。
系統設計就是來思考怎麼來實現這個功能，實現流程是什麼樣的，要不要新增表或增加表欄位，表結構如何設計，要寫幾個介面給前端，呼叫順序是什麼樣的，返回什麼樣的資料，資料格式什麼樣的，可以和前端開發坐一塊兒討論。這些應該在你分析完需求後就有了一個大致的思路，然後現在提取需求的關鍵詞、關鍵點作具體的詳細設計。
系統設計也是很重要的一環，是在寫程式碼之前定的目標，做的一個巨集觀規劃。儘量不要邊寫程式碼邊想怎麼實現，這樣會導致最後思路很亂寫的程式碼也很亂。
建議最好畫流程圖，條件允許的情況下小組內評審下，找出不足。
在系統設計階段如果需引入新技術，一定要考慮使用什麼技術，技術的複雜度，成熟度等，為什麼用這個技術，好處是什麼。如果自己不敢確定用什麼技術，可以找技術經理或比自己經驗豐富的同事一起定一下。初入職場或經驗頗少的同學，可以把自己的設計思路和他們說一下，讓他們把把關。
系統實現
這一步就是你最喜歡的寫程式碼階段了，寫程式碼的一些規範不用我多說了吧，下載阿里的開發手冊看看，或自己公司的開發規範。
業務程式碼一定要加註釋，在關鍵步驟加上簡單的註釋，以便日後自己看或者其他同事接替你的時候能一目瞭然，看懂這程式碼是在幹嘛，不至於背地裡被吐槽被罵娘。很多時候一些同學自己寫的程式碼，不加一行註釋，時間長了自己看的時候都懵逼了。加必要的註釋是程式設計師最最起碼的修養。
在功能開發到近一半的時候，郵件給測試負責人並抄送相關人員，告知此需求已開發過半，目的提醒其寫需求的測試案例，以免延誤測試。這一點根據你們開發流程定，建議如此。
功能測試
開發完成就進入功能測試階段了，或開發完某一介面（給前端呼叫的）開發人員就可以邊開發邊測了。
1、開發自測
開發人員對自己開發的功能自己測試，主要測試介面的邏輯，入參出參是否正確等，邊開發邊測，前後端可以一起測。
當整個功能都開發完成後，開發人員對該需求做整個流程的測試，針對可能出現問題的場景重點測試，當覺得本地測試的差不多的時候，可以把程式碼合併到測試環境再進行一次完整的測試。當覺得可以的時候，請小組組長髮起走查程式碼，主要檢查程式碼邏輯及程式碼規範等常見的顯而易見的問題（畢竟旁觀者清，自己寫的程式碼可能看很久也發現不了問題），有問題就改一下，走查沒問題了就可以提交給測試人員了。
這裡走查可以記錄到程式碼走查記錄裡，主要寫走查負責人，開發人員，走查時間，需求名，走查發現的問題，是否解決，何時解決等。通過走查程式碼可以防止同樣的問題再發生，或大家互相引以為戒。
2、提交測試
自測完畢後，郵件給測試負責人及相關人員，郵件說明某某需求已經合併到某某分支，或已釋出在某某測試環境，現在提測本需求，及時測試等等...並說明涉及到的功能和系統，以及主要的測試點。 接下來你就配合測試人員啦，有bug改bug。
3、業務測試
當測試人員測的差不多了，她們會郵件給業務人員。業務測完覺得沒問題，那就等著上線吧。
需求上線
需求上線前一定要檢查你的程式碼完整性，把你的需求涉及到的SQL語句（如新增的系統引數，新增表結構等）、改動的配置檔案（新增或修改配置）提交給運維。（重要！！！）
在需求上線的那天，你熬夜等上線（大部分都是晚上上線避開高峰期，也有的是灰度釋出可以提前上）。當生產發完後，測試人員和業務人員會在生產驗證，當業務說驗收通過時，恭喜你可以回家了。如果有問題，你還得去查日誌排查問題，然後解決，再上，再驗證；如果問題太嚴重，你的程式碼就需要撤下來，暫時不上。
最後
上線完畢後，將本次需求所有有關的文件打包歸檔，提交至你們的文件庫或者類似confluence這樣的開發管理平臺，如果沒有這些東西或沒要求做這些，可以自己儲存下來，以便以後查閱。
總結
軟體工程是一門學科，這裡主要站在後端程式設計師的角度分享了自己總結的需求開發流程及開發過程中避免踩坑背鍋的經驗，可能寫的有點粗略，或廢話很多，可能有的公司沒那麼規範，也可能有的公司比這流程複雜多了，但是這裡提到的需求分析、系統設計部分應該跟公司定的開發流程沒關係，是開發人員自己的習慣和經驗、自己給自己定的規範。還是那句話，我們程式設計師不甩鍋也絕不無故背鍋！
【END】