前言

在這個春風得意馬蹄急，金三銀四跳槽季的日子里，相信很多小伙伴都拿到了心儀的offer了吧，其中不乏有初入職場的同學。那么今天，我就從服務(wù)端的角度來給大家分享一些關(guān)于工作中開發(fā)流程的經(jīng)驗，希望初入職場的同學盡量少踩坑不背鍋，能夠順利通過考核期。

進入公司你會發(fā)現(xiàn)，一般正規(guī)點的公司都會分很多部門，如開發(fā)部（科技部或研發(fā)部）、產(chǎn)品部（業(yè)務(wù)部）等，這兩個部門是相互對等的，也就是說后者負責產(chǎn)品功能的創(chuàng)意、設(shè)計，產(chǎn)品的大方向，說白了就是負責提出產(chǎn)品需求，把控產(chǎn)品的定位和走向；而前者則是需求的受理者，負責從軟件、技術(shù)層面來實現(xiàn)后者提出的需求。兩個部門沒有上下級的關(guān)系。

而對于我們程序員來說，做一個需求從接到需求到上線的完整流程大致如下：

• 需求分析（包括需求調(diào)研，需求討論，需求確定，接口確認）
• 系統(tǒng)設(shè)計（設(shè)計該功能實現(xiàn)細節(jié)，要用到什么技術(shù)等）
• 系統(tǒng)實現(xiàn)（從軟件代碼技術(shù)層面實現(xiàn)功能）
• 功能測試（包括開發(fā)自測，提交測試，業(yè)務(wù)測試）
• 需求上線（業(yè)務(wù)驗收，驗收是否通過，代碼是否回退）

需求分析

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

需求背景：
主要告訴你為什么會有這個需求，提這個需求的目的是什么。
需求描述：
這才是這個需求的重點，主要告訴你要實現(xiàn)什么樣的功能，做成什么樣的效果，以及一些業(yè)務(wù)規(guī)則等，可能還會放幾個頁面的原型圖，這就再好不過了。

這些都是業(yè)務(wù)部門經(jīng)過深思熟慮、各級領(lǐng)導審核通過后的需求，才會到研發(fā)部門，研發(fā)部受理這個需求，分給你的組長或直接分給你。

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

1、快速通讀

可以先快速地通讀一遍，了解需求的大致意思，對需求有個整體的把握，做到心中有數(shù)。

2、抓重點、記疑問

然后第二遍，看細節(jié)，抓疑問點。

這一遍，你可以看仔細點，把一些關(guān)鍵點認真看看理解一下，同時看的時候可能會發(fā)現(xiàn)需求有寫的不明確的地方，或者需要確認的地方，或者你會有一些疑問，這個時候你可以把這些點記錄下來，認真讀完一遍之后，你記錄了一些問題。

3、答疑解惑

讀完兩遍之后，你有一些疑問。然后你可以找個時間拉上經(jīng)理或需求負責人，開發(fā)組長，前后端開發(fā)人員，業(yè)務(wù)（提需求的業(yè)務(wù)人員，他是最了解需求的人）、測試負責人一起當面開個小會（能當面絕不群里聊），去解決你記錄的疑問點，把這些需求里你認為寫的不確定的地方弄清楚。這個過程就是答疑解惑。

在這個討論過程中，定下來的業(yè)務(wù)規(guī)則務(wù)必要記錄下來，會后可以發(fā)一封電子郵件，把需求確認的東西或者業(yè)務(wù)又新加的東西寫在郵件里，提醒業(yè)務(wù)確認無誤后讓他更新需求文檔，并且郵件抄送給一起開會的人。

為什么拉上這么多人呢？因為你有疑問的地方你的組長，經(jīng)理等也可能有疑問，這種拍板釘釘?shù)氖虏荒苤蛔屇阋粋€人知道，到時候做完了上線了，業(yè)務(wù)發(fā)現(xiàn)不想要那樣的效果了賴賬不承認了咋辦。拉上測試是為了避免開發(fā)和測試理解需求上有偏差，避免測試寫的測試案例和需求要求有出入。

為什么發(fā)郵件呢？做這一步也是為了規(guī)范開發(fā)流程以及留個底有個證據(jù)吧，防止以后問你為啥這樣做，你就有據(jù)可依了。不然你單憑嘴說：當時討論就這樣定的。這樣說服力不夠啊。我們一定要做到，不甩鍋也絕不無故背鍋！

4、準備材料

需求討論過程中如發(fā)現(xiàn)涉及其他系統(tǒng)，提出來，并確認下其他系統(tǒng)接口有沒有提供好，并通過項目經(jīng)理向其他系統(tǒng)要接口文檔（系統(tǒng)間的文檔收發(fā)，最好通過系統(tǒng)負責人，即使都是內(nèi)部系統(tǒng)）；另外，如涉及到頁面改動需要提供UI的，督促業(yè)務(wù)及時提供UI，防止延誤需求上線。

為什么出UI？出UI的目的是嚴格按照UI圖的尺寸、色值來做頁面，防止到時候前端做好頁面后業(yè)務(wù)又來扣這些細節(jié)，讓你返工，還顯得你干活不利索。假如有的公司根本沒有UI設(shè)計師，那就提前和業(yè)務(wù)說好，做的時候讓業(yè)務(wù)把把關(guān)，看是否復合他要的效果。

5、工作記錄

其次，針對該需求，寫每日工作進度（日報）時，寫上當前需求到了哪個階段（如需求分析階段，開發(fā)階段等，具體到了哪個階段，自己評估），以及當前遇到的阻礙等。這樣如果有阻礙，即使是延誤了上線，也不是自己的原因。

注意：1、系統(tǒng)間接口聯(lián)調(diào)大概需要1-2天，復雜的接口可能需要更長的時間。系統(tǒng)聯(lián)調(diào)最好放在系統(tǒng)設(shè)計前，這樣可以發(fā)現(xiàn)接口返回內(nèi)容是不是滿足這個需求，并提出這個問題。如果你開發(fā)的時候用到這個接口的時候再聯(lián)調(diào)才發(fā)現(xiàn)問題，那不是耽誤時間了嗎。

2、假如第一次調(diào)用該系統(tǒng)，還要注意開通系統(tǒng)間的網(wǎng)絡(luò)，不然無法訪問。開通網(wǎng)絡(luò)當然也需要項目負責人來申請。而且一定要測試環(huán)境和生產(chǎn)環(huán)境的網(wǎng)絡(luò)一并開通，開通后并測試是否真的已經(jīng)開通。這樣防止沒有開通網(wǎng)絡(luò)，上線后調(diào)不通，又臨時火急火燎的發(fā)郵件申請開通網(wǎng)絡(luò)，這樣只會讓你難堪，顯得你這個人不夠仔細。

系統(tǒng)設(shè)計

需求分析，接口聯(lián)調(diào)，開通網(wǎng)絡(luò)等一些準備工作及雜事處理完后，就可以開始系統(tǒng)設(shè)計了或者邊處理邊進行系統(tǒng)設(shè)計（因為你等著出UI、開網(wǎng)都需要時間）。

系統(tǒng)設(shè)計就是來思考怎么來實現(xiàn)這個功能，實現(xiàn)流程是什么樣的，要不要新增表或增加表字段，表結(jié)構(gòu)如何設(shè)計，要寫幾個接口給前端，調(diào)用順序是什么樣的，返回什么樣的數(shù)據(jù)，數(shù)據(jù)格式什么樣的，可以和前端開發(fā)坐一塊兒討論。這些應(yīng)該在你分析完需求后就有了一個大致的思路，然后現(xiàn)在提取需求的關(guān)鍵詞、關(guān)鍵點作具體的詳細設(shè)計。

系統(tǒng)設(shè)計也是很重要的一環(huán)，是在寫代碼之前定的目標，做的一個宏觀規(guī)劃。盡量不要邊寫代碼邊想怎么實現(xiàn)，這樣會導致最后思路很亂寫的代碼也很亂。

建議最好畫流程圖，條件允許的情況下小組內(nèi)評審下，找出不足。

在系統(tǒng)設(shè)計階段如果需引入新技術(shù)，一定要考慮使用什么技術(shù)，技術(shù)的復雜度，成熟度等，為什么用這個技術(shù)，好處是什么。如果自己不敢確定用什么技術(shù)，可以找技術(shù)經(jīng)理或比自己經(jīng)驗豐富的同事一起定一下。初入職場或經(jīng)驗頗少的同學，可以把自己的設(shè)計思路和他們說一下，讓他們把把關(guān)。

系統(tǒng)實現(xiàn)

這一步就是你最喜歡的寫代碼階段了，寫代碼的一些規(guī)范不用我多說了吧，下載阿里的開發(fā)手冊看看，或自己公司的開發(fā)規(guī)范。

業(yè)務(wù)代碼一定要加注釋，在關(guān)鍵步驟加上簡單的注釋，以便日后自己看或者其他同事接替你的時候能一目了然，看懂這代碼是在干嘛，不至于背地里被吐槽被罵娘。很多時候一些同學自己寫的代碼，不加一行注釋，時間長了自己看的時候都懵逼了。加必要的注釋是程序員最最起碼的修養(yǎng)。

在功能開發(fā)到近一半的時候，郵件給測試負責人并抄送相關(guān)人員，告知此需求已開發(fā)過半，目的提醒其寫需求的測試案例，以免延誤測試。這一點根據(jù)你們開發(fā)流程定，建議如此。

功能測試

開發(fā)完成就進入功能測試階段了，或開發(fā)完某一接口（給前端調(diào)用的）開發(fā)人員就可以邊開發(fā)邊測了。

1、開發(fā)自測

開發(fā)人員對自己開發(fā)的功能自己測試，主要測試接口的邏輯，入?yún)⒊鰠⑹欠裾_等，邊開發(fā)邊測，前后端可以一起測。

當整個功能都開發(fā)完成后，開發(fā)人員對該需求做整個流程的測試，針對可能出現(xiàn)問題的場景重點測試，當覺得本地測試的差不多的時候，可以把代碼合并到測試環(huán)境再進行一次完整的測試。當覺得可以的時候，請小組組長發(fā)起走查代碼，主要檢查代碼邏輯及代碼規(guī)范等常見的顯而易見的問題（畢竟旁觀者清，自己寫的代碼可能看很久也發(fā)現(xiàn)不了問題），有問題就改一下，走查沒問題了就可以提交給測試人員了。

這里走查可以記錄到代碼走查記錄里，主要寫走查負責人，開發(fā)人員，走查時間，需求名，走查發(fā)現(xiàn)的問題，是否解決，何時解決等。通過走查代碼可以防止同樣的問題再發(fā)生，或大家互相引以為戒。

2、提交測試

自測完畢后，郵件給測試負責人及相關(guān)人員，郵件說明某某需求已經(jīng)合并到某某分支，或已發(fā)布在某某測試環(huán)境，現(xiàn)在提測本需求，及時測試等等...并說明涉及到的功能和系統(tǒng)，以及主要的測試點。
接下來你就配合測試人員啦，有bug改bug。

3、業(yè)務(wù)測試

當測試人員測的差不多了，她們會郵件給業(yè)務(wù)人員。業(yè)務(wù)測完覺得沒問題，那就等著上線吧。

需求上線

需求上線前一定要檢查你的代碼完整性，把你的需求涉及到的SQL語句（如新增的系統(tǒng)參數(shù)，新增表結(jié)構(gòu)等）、改動的配置文件（新增或修改配置）提交給運維。（重要?。。。?/strong>