寫給即將入職的你-軟件工程之需求開發流程

前言

在這個春風得意馬蹄急，金三銀四跳槽季的日子裏，相信不少小夥伴都拿到了心儀的offer了吧，其中不乏有初入職場的同窗。那麼今天，我就從服務端的角度來給你們分享一些關於工做中開發流程的經驗，但願初入職場的同窗儘可能少踩坑不背鍋，可以順利經過考覈期。

進入公司你會發現，通常正規點的公司都會分不少部門，如開發部（科技部或研發部）、產品部（業務部）等，這兩個部門是相互對等的，也就是說後者負責產品功能的創意、設計，產品的大方向，說白了就是負責提出產品需求，把控產品的定位和走向；而前者則是需求的受理者，負責從軟件、技術層面來實現後者提出的需求。兩個部門沒有上下級的關係。

而對於咱們程序員來講，作一個需求從接到需求到上線的完整流程大體以下：

• 需求分析（包括需求調研，需求討論，需求肯定，接口確認）
• 系統設計（設計該功能實現細節，要用到什麼技術等）
• 系統實現（從軟件代碼技術層面實現功能）
• 功能測試（包括開發自測，提交測試，業務測試）
• 需求上線（業務驗收，驗收是否經過，代碼是否回退）

需求分析

從你拿到需求文檔開始提及，你會看到需求文檔至少包括2部分來闡述這個需求：需求背景和需求描述。

需求背景：
主要告訴你爲何會有這個需求，提這個需求的目的是什麼。
需求描述：
這纔是這個需求的重點，主要告訴你要實現什麼樣的功能，作成什麼樣的效果，以及一些業務規則等，可能還會放幾個頁面的原型圖，這就再好不過了。

這些都是業務部門通過深思熟慮、各級領導審覈經過後的需求，纔會到研發部門，研發部受理這個需求，分給你的組長或直接分給你。

言歸正傳，你接到需求，打開需求文檔，開始看需求了。

一、快速通讀

能夠先快速地通讀一遍，瞭解需求的大體意思，對需求有個總體的把握，作到心中有數。

二、抓重點、記疑問

而後第二遍，看細節，抓疑問點。

這一遍，你能夠看仔細點，把一些關鍵點認真看看理解一下，同時看的時候可能會發現需求有寫的不明確的地方，或者須要確認的地方，或者你會有一些疑問，這個時候你能夠把這些點記錄下來，認真讀完一遍以後，你記錄了一些問題。

三、答疑解惑

讀完兩遍以後，你有一些疑問。而後你能夠找個時間拉上經理或需求負責人，開發組長，先後端開發人員，業務（提需求的業務人員，他是最瞭解需求的人）、測試負責人一塊兒當面開個小會（能當面毫不羣裏聊），去解決你記錄的疑問點，把這些需求裏你認爲寫的不肯定的地方弄清楚。這個過程就是答疑解惑。

在這個討論過程當中，定下來的業務規則務必要記錄下來，會後能夠發一封電子郵件，把需求確認的東西或者業務又新加的東西寫在郵件裏，提醒業務確認無誤後讓他更新需求文檔，而且郵件抄送給一塊兒開會的人。

爲何拉上這麼多人呢？由於你有疑問的地方你的組長，經理等也可能有疑問，這種拍板釘釘的事不能只讓你一我的知道，到時候作完了上線了，業務發現不想要那樣的效果了賴帳不認可了咋辦。拉上測試是爲了不開發和測試理解需求上有誤差，避免測試寫的測試案例和需求要求有出入。

爲何發郵件呢？作這一步也是爲了規範開發流程以及留個底有個證據吧，防止之後問你爲啥這樣作，你就有據可依了。否則你單憑嘴說：當時討論就這樣定的。這樣說服力不夠啊。咱們必定要作到，不甩鍋也毫不無端背鍋！

四、準備材料

需求討論過程當中如發現涉及其餘系統，提出來，並確認下其餘系統接口有沒有提供好，並經過項目經理向其餘系統要接口文檔（系統間的文檔收發，最好經過系統負責人，即便都是內部系統）；另外，如涉及到頁面改動須要提供UI的，督促業務及時提供UI，防止延誤需求上線。

爲何出UI？出UI的目的是嚴格按照UI圖的尺寸、色值來作頁面，防止到時候前端作好頁面後業務又來扣這些細節，讓你返工，還顯得你幹活不利索。假若有的公司根本沒有UI設計師，那就提早和業務說好，作的時候讓業務把把關，看是否複合他要的效果。

五、工做記錄

其次，針對該需求，寫每日工做進度（日報）時，寫上當前需求到了哪一個階段（如需求分析階段，開發階段等，具體到了哪一個階段，本身評估），以及當前遇到的阻礙等。這樣若是有阻礙，即便是延誤了上線，也不是本身的緣由。

注意：一、系統間接口聯調大概須要1-2天，複雜的接口可能須要更長的時間。系統聯調最好放在系統設計前，這樣能夠發現接口返回內容是否是知足這個需求，並提出這個問題。若是你開發的時候用到這個接口的時候再聯調才發現問題，那不是耽誤時間了嗎。

二、假如第一次調用該系統，還要注意開通系統間的網絡，否則沒法訪問。開通網絡固然也須要項目負責人來申請。並且必定要測試環境和生產環境的網絡一併開通，開通後並測試是否真的已經開通。這樣防止沒有開通網絡，上線後調不通，又臨時火急火燎的發郵件申請開通網絡，這樣只會讓你難堪，顯得你這我的不夠仔細。

系統設計

需求分析，接口聯調，開通網絡等一些準備工做及瑣事處理完後，就能夠開始系統設計了或者邊處理邊進行系統設計（由於你等着出UI、開網都須要時間）。

系統設計就是來思考怎麼來實現這個功能，實現流程是什麼樣的，要不要新增表或增長表字段，表結構如何設計，要寫幾個接口給前端，調用順序是什麼樣的，返回什麼樣的數據，數據格式什麼樣的，能夠和前端開發坐一起討論。這些應該在你分析完需求後就有了一個大體的思路，而後如今提取需求的關鍵詞、關鍵點做具體的詳細設計。

系統設計也是很重要的一環，是在寫代碼以前定的目標，作的一個宏觀規劃。儘可能不要邊寫代碼邊想怎麼實現，這樣會致使最後思路很亂寫的代碼也很亂。

建議最好畫流程圖，條件容許的狀況下小組內評審下，找出不足。

在系統設計階段若是需引入新技術，必定要考慮使用什麼技術，技術的複雜度，成熟度等，爲何用這個技術，好處是什麼。若是本身不敢肯定用什麼技術，能夠找技術經理或比本身經驗豐富的同事一塊兒定一下。初入職場或經驗頗少的同窗，能夠把本身的設計思路和他們說一下，讓他們把把關。

系統實現

這一步就是你最喜歡的寫代碼階段了，寫代碼的一些規範不用我多說了吧，下載阿里的開發手冊看看，或本身公司的開發規範。

業務代碼必定要加註釋，在關鍵步驟加上簡單的註釋，以便往後本身看或者其餘同事接替你的時候能一目瞭然，看懂這代碼是在幹嗎，不至於背地裏被吐槽被罵娘。不少時候一些同窗本身寫的代碼，不加一行註釋，時間長了本身看的時候都懵逼了。加必要的註釋是程序員最最起碼的修養。

在功能開發到近一半的時候，郵件給測試負責人並抄送相關人員，告知此需求已開發過半，目的提醒其寫需求的測試案例，以避免延誤測試。這一點根據大家開發流程定，建議如此。

功能測試

開發完成就進入功能測試階段了，或開發完某一接口（給前端調用的）開發人員就能夠邊開發邊測了。

一、開發自測

開發人員對本身開發的功能本身測試，主要測試接口的邏輯，入參出參是否正確等，邊開發邊測，先後端能夠一塊兒測。

當整個功能都開發完成後，開發人員對該需求作整個流程的測試，針對可能出現問題的場景重點測試，當以爲本地測試的差很少的時候，能夠把代碼合併到測試環境再進行一次完整的測試。當以爲能夠的時候，請小組組長髮起走查代碼，主要檢查代碼邏輯及代碼規範等常見的顯而易見的問題（畢竟旁觀者清，本身寫的代碼可能看好久也發現不了問題），有問題就改一下，走查沒問題了就能夠提交給測試人員了。

這裏走查能夠記錄到代碼走查記錄裏，主要寫走查負責人，開發人員，走查時間，需求名，走查發現的問題，是否解決，什麼時候解決等。經過走查代碼能夠防止一樣的問題再發生，或你們互相引覺得戒。

二、提交測試

自測完畢後，郵件給測試負責人及相關人員，郵件說明某某需求已經合併到某某分支，或已發佈在某某測試環境，如今提測本需求，及時測試等等...並說明涉及到的功能和系統，以及主要的測試點。
接下來你就配合測試人員啦，有bug改bug。

三、業務測試

當測試人員測的差很少了，她們會郵件給業務人員。業務測完以爲沒問題，那就等着上線吧。

需求上線

需求上線前必定要檢查你的代碼完整性，把你的需求涉及到的SQL語句（如新增的系統參數，新增表結構等）、改動的配置文件（新增或修改配置）提交給運維。（重要！！！）

在需求上線的那天，你熬夜等上線（大部分都是晚上上線避開高峯期，也有的是灰度發佈能夠提早上）。當生產發完後，測試人員和業務人員會在生產驗證，當業務說驗收經過時，恭喜你能夠回家了。若是有問題，你還得去查日誌排查問題，而後解決，再上，再驗證；若是問題太嚴重，你的代碼就須要撤下來，暫時不上。

最後

上線完畢後，將本次需求全部有關的文檔打包歸檔，提交至大家的文檔庫或者相似confluence這樣的開發管理平臺，若是沒有這些東西或沒要求作這些，能夠本身保存下來，以便之後查閱。

總結

軟件工程是一門學科，這裏主要站在後端程序員的角度分享了本身總結的需求開發流程及開發過程當中避免踩坑背鍋的經驗，可能寫的有點粗略，或廢話不少，可能有的公司沒那麼規範，也可能有的公司比這流程複雜多了，可是這裏提到的需求分析、系統設計部分應該跟公司定的開發流程不要緊，是開發人員本身的習慣和經驗、本身給本身定的規範。仍是那句話，咱們程序員不甩鍋也毫不無端背鍋！
***
【END】
原文連接：http://www.javashuo.com/article/p-rvhkrapu-eu.html