前言
在這個春風得意馬蹄急，金三銀四跳槽季的日子里，相信很多小伙伴都拿到了心儀的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這樣的開發管理平台，如果沒有這些東西或沒要求做這些，可以自己保存下來，以便以后查閱。
總結
軟件工程是一門學科，這里主要站在后端程序員的角度分享了自己總結的需求開發流程及開發過程中避免踩坑背鍋的經驗，可能寫的有點粗略，或廢話很多，可能有的公司沒那么規范，也可能有的公司比這流程復雜多了，但是這里提到的需求分析、系統設計部分應該跟公司定的開發流程沒關系，是開發人員自己的習慣和經驗、自己給自己定的規范。還是那句話，我們程序員不甩鍋也絕不無故背鍋！