對於後端來講，一個項目究竟應該怎麼作

引子

做爲一個程序員，平時的工做是與項目來掛鉤的，可是有的時候會發現有些項目作得風生水起，有的則作得渾身難受，那麼一個項目究竟應該怎麼作？

一個後端接到項目的主要流程

1. 需求諮詢
2. 需求評審
3. 項目估期
4. 技術評審
5. 跟上游約定 api
6. 開發
7. 聯調測試
8. 產品驗收
9. 上線
10. 整理必要的文檔

需求諮詢

這個階段是後端最初接觸某項目的初始階段，此時產品會給出最初的需求文檔（線框圖此時可能沒有），甚至是人肉來諮詢後端作最初的評估，已肯定某些需求的可能性。

討論結束後產品會根據討論獲得的結果回去開腦洞，項目可能夭折或者繼續進行。

需求評審

產品通過他們本身的討論設計，給出需求文檔線框圖（此時設計稿通常沒有），召集先後端等項目成員進行需求評審。此時後端同窗須要根據需求的合理性、項目的開發週期進行討論（砍需求）。

砍需求的目的不是爲了砍需求而砍需求，須要根據手上已有系統的功能以及新需求作出綜合考慮，儘可能在相對簡單的狀況下實現產品的需求。

簡單的說就是難的我也能作，可是要花時間，砍需求的目的就在於在項目的 deadline 內可以完成這個項目。實在不行這個需求放在二期，太多的所謂二期需求就沒有二期的項目了（可見有時候產品的需求...）

注意，產品會接受開發砍需求，可是開發請對確認後的需求認真估期，保證 deadline。不然又砍需求時間到了又作不完，呵呵。

項目估期

根據需求評審獲得的需求，後端會先作初步的技術調研，需求拆分，在評審結束的1~2天內給出估期。

估期時須要注意，估期很難一次性估準，一個開發對於大於一週以上的估期就能夠認爲是憑感受瞎估了，這裏有個估期的經驗：將需求拆細後拆到開發級別的力度創建對應的 task，對於每一個 task 來作估期，當發現一個 task 的時間大於5後（單位爲天），則須要拆分子 task，估期時採用斐波那契數列的評估方式: 1 2 3 5 8 13 21，對應於1天 2天 半周 1周 1.5周 2周 3周，能夠上下加減0.5。而後根據子任務的時間合估計主任務的時間。

須要注意的是，估期時須要估計先後端聯調時間，上線時間，資源申請時間，幺蛾子時間。幺蛾子時間爲處理非此項目事件所花費的時間，這個跟開發自己所處的環境有關，能夠在總估期的基礎上乘以 1.2 ~ 1.5。

技術評審

復瑣事情須要技術評審，尤爲是本身作的事情內心也沒有底氣，須要其餘開發一塊兒討論的時候。技術評審是保證復瑣事情能夠順利完成，減小後期返工可能性的一個重要環節。

技術評審開發自己本身須要給出評審文檔，包括項目背景，技術選型，主要的技術約束，本身想到的設計實現。

跟上游約定 api

通常一個項目會由多個部門並行開發，例如 數據、後端、前端、客戶端，並行的過程當中若是某個端開發比較慢，會致使卡另外一個端的開發進度，因此須要開發前跟本身的上游約定 api，並給出文檔，各個端遵循接口文檔進行開發。

開發

根據技術評審後（簡單的事情沒有評審，本身內心有數）獲得的方案以及以前創建的任務進行開發。

開發過程當中須要仔細研究設計稿的細節，有任何存疑問的點去找產品確認，確認後的需求記錄在某個文檔上。開發前幾分鐘的幾句話，會大大下降返工的可能性。

記錄後@產品畫押，開發和產品的記性都不好，畫押很是必要。後期甩鍋有用。

開發時注意把某些流程繁瑣的事情放在前面作，例如申請某些資源可能須要其餘部門同窗支持，有額外等候時間。

開發過程當中遇到難點及時向其餘開發求助，不要憋着。

若是可能遇到延期風險，請及時通知產品，deadline 請儘可能遵循（這句話的意思很明顯）。

聯調測試

先後端開發完後作總體的聯調測試，在扔個產品測試前，請本身測過本身開發的 feature。不然氣死產品事小，被產品打死事大。

產品驗收

迎接可能的返工。

上線

上線注意各類細節，例如數據庫變動，是否須要熱緩存，灰度或者預發佈後是否須要 cms 添加某些基礎數據等等。

上線前請提供回滾方案。

整理必要的文檔

文檔記錄下各類連接（需求文檔、技術評審、 api），主要的實現，需求的變動便可。

正常狀況下，上完線就結束了，也沒有人會作這一步，可是若是後端作掉這一步的話，以後維護起來就會節省不少看代碼思考邏輯的時間。

後記

請尊重項目的 deadline。