業務開發往往是產品需求都比較急，疊帶比較快。往往是快速排期、快速設計、快速開發，快速上線的一個狀態，這就比較考驗程序員的如何來適應這個快速的節奏和建立自己的開發流程和如何拋開工作之外的自我提升。
那怎麼來應對這樣一個快速的節奏呢？
- 理解團隊技術棧
熟悉開發框架，熟悉團隊中間件（如redis、kafka、orm、log、rpc等封裝）的使用，最好深入源碼研究，發現使用方法、什麼場景怎麼使用，有哪些坑，這些最好做總結，在團隊中分享（爲了自己熟悉和提升自己在團隊中的技術影響力）。
- 代碼規範
大部分團隊應該都沒有，有的話更好仔細熟讀理解。沒有的話從源碼中提取列出哪些好的規範和不好的規範整理一個，在合適的機會和同事討論商量做一個規範準則，這樣以後大家共同維護一個項目不至於噁心。
- 瞭解開發流程
通常流程是產品提需求有一個需求會、與其他交互系統確認交互字段、給排期、設計開發、自測、提測、上線、線上驗證等。大體是這個流程可能對應每個產品流程不一樣。在大體符合流程情況下，這裏需要把握自己的節奏。
- 熟悉業務
業務開發業務最重要理解業務實現業務。從宏觀理解再到細節，推薦自己用腦圖梳理自己接手的業務，不斷的疊帶梳理。最終會影響你程序的設計。
- 瞭解業務監控
通常公司運維團隊都建立了一套監控體系，這裏需要外面去梳理從業務層到底層是如何做的監控，和去訂閱，出問題的時候能快速排查和解決問題。
如何建立自己的開發流程？
自己的開發流程是在符合團隊大體流程之上提煉出來自己的開發流程。
- 需求評估
需求評估需要理解產品和用戶的需求，理解要解決什麼問題。明白什麼時間需要交互，評估目前系統邏輯情況與產品溝通好一個比較合理排期時間。需要落實在自己的開發wiki上。
- 需求開發設計
設計主要包含：
1.整理當前系統關於此需求邏輯。
2.整理外部依賴接口和自己暴露接口，依賴的外部接口一定要和提供者溝通你的使用場景和大概的併發量和請求參數範圍等情況（這是一個最耗時的過程），對外暴露接口也一定要收集到調用方的使用場景和併發量等問題思考是否複用原來接口和重新提供接口（提供接口一定要慎重，一旦提供就很難改造）。
3.根據需求排期設計開發方案，如果時間充裕以最優方案做包含重構以前的一些邏輯。若時間不許可，選擇折中方案（欠下技術債）。此時需要專門整理一個技術債wiki，記錄下，待以後償還。如果比較複雜的需求需要發起開發方案評審，若沒有這個流程也可以請求同事或者有經驗的同事把把關。
- 開發
遵守code 準則、做好單元測試、和基本的聯通測試、等自測。完事後提交git 一定要自己做一遍code review。也邀請同事幫忙做一個code rewivew。
- 提測
整理好開發文檔和接口文檔和改動說明和測試點。一定要耐心的和測試同學溝通因爲這是開發質量的最後一道關口。測試同學遇到問題要及時解答，總之配合好測試同學。
- 上線
不管你有沒有上線權限，一定要整理上線文檔，文檔包含上線代碼git merge request，上線cmd，上線配置和sql，和依賴接口、及其上線順序、及其上線影響、上線如何驗證 等整理好，儘量在第二人蔘與情況下上線，同時也做好回滾流程，萬一有問題需要馬上回滾。 這一步很重要，做得不到位很可能發生黑天鵝事件，墨菲定律。
- 上線驗證
一定要做線上驗證，按照驗證計劃。如果實在做不了驗證也應該加強線上狀態實時監控。
- 做好事故回盤
遇到線上事故和重大bug 一定要做好記錄和做好回盤，改進，這個也可能是團隊的要求。自己也關注下其他人的回盤引以爲戒。
如何自我提升
從上面看業務應用開發就是工程性問題，按照自己的一個開發流程週而復始的重複。技術基本也就那幾個技術點，怎麼才能保證技術不被淘汰呢？
最重要的是做好自己的技術規劃。簡單的說是按照規劃做好輸入輸出。業務開發溝通會浪費很多時間，做好碎片化時間管理。和互聯網行業都加班，雖然每天大家都加班，但是百分之八十的時候白天都能完成工作，由於有加班文化，大家都磨洋工拖到晚上。建議白天正常完成工作，晚上流出時間來做自己的技術規劃，日拱一卒。