作為一名后台開發同學，做需求開發不可避免，無論是產品需求還是技術需求，需求雖然在變，但做事的方法是相同的，這里簡單總結下從接到一個需求開始至需求上線的整個過程，以及其中需注意的點，避免后續踩坑
1. 明確需求
以產品需求舉例，接到一個需求之后，首先要做的是搞明白這個需求，而不是一上來就是開始擼代碼，這樣很有可能導致最后上線的功能不符合產品預期
怎樣明確一個需求？
- 為什么做這件事，收益在哪里，讓需求方來即產品經理講，如果這個都講不明白，這個需求可以直接拒掉，畢竟做了也沒什么收益，這個道理在哪里都說得通
- 明白1之后，產品一般都會提出自己的方案，但是這個方案是否合理 也需要我們開發自己來思考，不當工具人，有不合理的地方應該直接提出來和產品討論
- 需求預期上線時間以及驗收標准
重點： 產品需求清晰后要追細節，避免一句話需求，凡是方案涉及到的細節點都需要在tapd or 企業微信中同步出來，避免后續返工
2. 開發
需求明確后，一般會開始排期，評估工作量，工作量拍腦門可不行，需方案明確后才能給出相對准確的排期
這里評估工時
- 工作點拆分的越細，一般評估的工時會更加准確
- 可以請有經驗的同學幫忙評估，自己再留一定buff也可
拆分工作這里建議 寫設計文檔，之后排期也可以很明確的給出來，下邊列下開發中要注意的點
-
設計文檔
- 需求描述，架構圖，細節流程圖，監控點，測試點等等，可以參考這里就不展開講
- 方案選型和涉及建議要有和業界或者公司內部部門的比較
- 整體架構和方案指定后需評審，可以找組內小伙伴或者leader或者總監，都可以，查漏補缺
-
編碼
- 編碼階段注意寫單元測試
- 編碼種碰到問題及時反饋出來討論，技術問題或者產品邏輯問題都可以， 或者寫入todo項也可
-
自測
- 前提是單元測試已ok
- 針對接口或者邏輯進行測試，后台開發一般需看日志來確認邏輯正常
- 需測試到異常分支，這里最容易出問題
-
聯調
- 需求如果涉及到多方，需和上下游服務進行聯調，此時更應該看服務端日志確認自己的邏輯正常才可以
-
監控
- 需能看到異常or關鍵邏輯的監控是否正常
-
debug
- 需要有debug能力，比如可以針對單個用戶染色，接入天機閣，可以很方便看到此用戶日志，要不然排查問題成本太高
-
效果驗收
- 需讓需求提出放在測試環境 驗收，符合預期后進入下一步
-
性能驗收
- 壓測當前服務，給出QPS，分位耗時等數據
-
CR
- 強烈建議 代碼走讀，前置查漏補缺，總比在線上發現問題好
這里要注意
- owner意識，自己承諾的時間點盡量要達到，如果有插入需求或者編碼中碰到問題會影響進度，需及時反饋出來，而不能等到最后一天了才說沒完成
- 追求效率，30min法則，如果一個問題自己google和思考30min還沒解決的，及時反饋給導師or高T，再解決不了再向上反饋，不能死撐着
- 口頭溝通基本無效，關鍵點需同步出來
此時開發側基本工作已完成，下一步需在正式環境部署服務上線
3. 上線
-
資源評估
- 建議前置，我廠資源申請還是比較麻煩的
- 服務上線需要使用多少資源，cpu，mem，底層存儲（redis，dcache）等等 需要前置評估出來
- 這里根據之前的QPS數據，再結合預估的峰值流量 即可預估出需要部署多少節點
- 這里要注意線上節點的負載不能過高，需要有一定冗余，線上負載建議在40-50%之間
-
資源申請
- 一般是向運維同學申請，需說明需求背景，收益，資源推導公式 便於運維同學審批
-
資源部署
- 部署在正式 和 灰度節點即可
-
壓測
- 之前壓測使用的是自己構造的client，req和線上用戶是不同的，這里建議使用線上旁路流量指定后端某一個節點進行壓測，數據最為准確
-
發布流程
-
灰度發布
- 發布灰度節點，用戶量比較小
- 產品需在此環境驗收功能是否正常
- 開發需在此環境驗收邏輯是否正常，通過日志確認
-
旁路驗證
- 因之前機器資源是根據壓測結果推導而來，假如結果不准 會導致線上服務異常，這里建議可以 先旁路線上流量至新服務上，對線上無影響，又可以驗證服務性能，提前發現問題 提前解決
-
正式發布
- 這里建議使用 白名單+灰度百分比方式放量，風險最小
- 產品開發先使用白名單體驗，通過日志確認，功能正常之后再開始按百分比放量
- 放量中注意觀察服務負載和之前的監控等數據，有異常及時處理
- 這里建議使用 白名單+灰度百分比方式放量，風險最小
-
這里多說兩句，后台開發需對發布有敬畏之心，發布要灰度上線，邏輯都驗證到才可以，切記不可發布完事就完事了，要對自己的發布負責，畢竟我們寫的可不是玩具程序，是真的會影響上億用戶的體驗的
4. 后續
- 功能上線之后，還需關注上線之后效果如何，是否符合預期，可以和產品討論是否有后續的優化點
- 系統是否便於debug，如果不是 這里也是優化的點，畢竟開發同學有大部分時間都是在查case，這里效率一定要提高
- 如何處理線上問題，建議看這篇，以恢復線上為第一原則
- 開發側是否為了趕工期 有挖坑，比如有臨時的解決方案，該填的坑也得填了
- 總結。方案架構設計的對比，思考等等，持續總結才能提高自己的架構設計能力
- 項目中使用的上下游組件是否了解其原理，比如使用 redis or kafka 是否真的了解了，都是可以學習的點
歡迎大家一起交流學習：
qq：564790073
github：https://github.com/hashyong