[[373380]]

本文轉載自微信公眾號「bugstack蟲洞棧」，作者小傅哥。轉載本文請聯系bugstack蟲洞棧公眾號。    

一、前言

互聯網公司常見工種有哪些?

互聯網中一個項目的上線會需要各個工種間的配合，以研發為視角上會承接產品需求，下會交給測試驗證，最終完成項目交付上線。其實除此之外，還會有業務、運營、UI設計、運維，來配合項目的發起、使用和運維維護。

圖 18-1，互聯網工種協同合作。

圖 18-1互聯網工種協同合作

除了一條線上的工作交替配合，還有同工種間的跨部門協同工作。比如：

• 產品階段：A產品中的部分服務，需要由另外一個部門配合開發相關服務支撐。那么雙方產品需要協調好時間節奏，配合上線。
• 研發階段：承接著產品跨部門的對接功能，雙方研發會定義好對接接口、對接時間，以及最終的聯調上線。
• 測試階段：按照產品的功能節點、研發的開發流程以及接口描述，進行測試驗證。

最終，同部門工作的交替、跨部門的工作協同，保障項目開發過程所需的各項物料都如期上線。

接下來我們來說一說，項目上線中各個階段的執行過程。 當然，并不一定所有的開發都是按照這個過程執行。會根據公司的體量、項目的大小、架構的模式有些許差異。所以，僅作為參考學習即可，不需要強制趨同。

二、時間節奏

圖 18-2 定義時間節奏

• 級別：
• 事項：定義項目開發時間節點
• 人員：業務、產品、研發組長、測試組長、架構師、核心項目成員
• 描述：這個時間節奏的定義非常重要，它可以是項目經理發起也可以是產品發起。一般很多時候互聯公司發一個項目，經常會聽到老板說我要這個時間上。可能這句話看上去很不合理，但為了活下去，為了快速站住市場，壓到下面執行人員就是一個必須要上線的時間。但，這個上線的時間如果想滿足， 那么就需要把整體的時間節奏確認出來。比如業務和產品什么時候把需求確認清楚，什么時間與研發過PRD，研發什么時候開發到提測，測試什么時間測試完成。如果，沒有這個時間節奏，前面的職責人員把時間都耗費沒了以后，越往后面風險越高。就像最后研發只有4天，測試只有2天，那帶BUG上線嗎!?所以要整體把控才是對項目的負責。

三、資源投入

圖 18-3 安排資源投入

• 級別：
• 事項：研發資源投入
• 人員：架構師、研發人員、測試人員
• 描述：站在研發視角，研發需要從工程開發、配合測試(改bug)、項目上線等的全流程參與，是一個較長周期的工作。但在某個階段所投入的時間成本會有差異，可以按照一定的資源占比進行投入(1是100%、0.8是80%)。那么，當一個新的項目下來以后，就需要按照最近原則和項目的人員可投入情況，進行資源投入安排。如果項目較多的情況下，資源安排不合理。可能會導致項目提交測試晚或某些功能全部由一個研發提交測試的，最終改不過來BUG。從而也就導致了，項目的延期風險。

四、研發、測試、上線階段

圖 18-4 研發、測試、上線階段

• 級別：
• 事項：研發、測試、上線階段
• 人員：研發人員、測試人員、架構師/技術組長
• 描述：這個階段包括的內容較多，主要是以研發視角看上下銜接人員。研發接過產品的需求開始做設計，設計完成后由研發主導發起設計評審，這個階段參與的人員較多(研發、架構師、測試、產品等)。功能的合理設計也是可以非常有效的保障資源使用的重要一環，另外一個需求的合理架構將會為后續需求迭代做好鋪墊。就像女廁改男廁，如果沒有流出小便的水管，就很麻煩。 最終研發完成需要提交相應的成果物，尤其是提測報告、接口文檔、單測信息。如果研發不能有完整的單元測試覆蓋度，那么交給測試以后，日常的修復bug的事情就會非常多。當研發和測試工作完成以后，接下來就是發布上線。上線前夕會有研發發起上線報告，同時各方配合以及產品、運用準備相應的線上配置數據和權限。最終上線完成交付產品運營使用。

五、項目復盤

圖 18-5 項目復盤

• 級別：
• 事項：項目復盤
• 人員：面向研發和測試人員
• 描述：復盤可能會因為出現事故、技術總結、分享成長，幾個方向而進行的歸納、總結，避免同類事情的發生。復盤內容一般會包括技術方面的使用，例如：DB、應用開發、網關等，也包括業務領域邏輯的建設。
• 復盤DB：

1. 數據庫連接數配置依照業務場景申請增加
2. 禁止使用復雜嵌套和函數類等做業務查詢
3. 防重邏輯字段加強避免造成不能防重問題
4. 索引字段初始化檢測以及慢查詢問題優化

• 復盤業務：

1. 對于所有營銷類場景的設計需符合標準流程，緩存使用的一致性問題
2. 資金流水結算方面在防重復設計上加強驗證，測試環境模擬多樣場景
3. 對于外部支撐系統的依賴按照業務體量發展，進行通知壓測報告流量
4. 所有核心功能流程加強研發側代碼評審質量，并不斷按照發展量優化
5. 研發側代碼質量提升定期復盤問題以及優化，通過鍛煉不斷加強質量
6. 在研發提測、修復、上線流程注意開發分支，避免錯亂合并產生問題
7. 所有的業務流程配置監控與圖表并打印日志，方便及時追蹤線上異常
8. 核心場景的全鏈路壓測可以有效的保證質量，也可很好降低流量風險

• 復盤功能：

1. 功能邏輯封裝優化，緩存、線程、驗證
2. 日志完整性校驗，入參、出參、異常
3. 調用外部接口的超時時長設定以及重試約定
4. 異常展示的緊急問題，測試環境復現追溯

• 復盤部署：

1. 按照壓測標準部署服務
2. 核心業務雙機房三機房
3. 非核心業務隔離RPC接口配置
4. 按需調整JVM、連接數、日志等參數

• 復盤接口：

1. 功能驗證的完整性
2. 異常流程的復測性
3. 數據指標監控范圍
4. 新上線后定期檢測

綜上，可能僅僅是對某一次項目的總結性復盤，便于新人接受和理解項目的重點內容。如果團隊中能及時有效的匯總技術并落地資料，可以非常有效的做好技術傳承。

六、總結

• 互聯網中一般中大型項目的開發過程，涉及的流程一般較多，也需要合理的把控。否則可能會出現一些過程中的風險，導致項目不能如期上線。當然也并不是所有項目都需要這樣處理，例如一些小功能的迭代和簡單需求的開發，可以簡化流程，快速迭代。蓋茅坑、豬圈、三居室還是不同的，不能一概而論
• 做好技術分析、復盤、總結、歸納，沉淀出的技術資料非常有價值，既可以把項目開發經驗傳承給新人，也可以讓所有人做好各自的技術成長。并且通過復盤和總結，又可以提煉出更多新的思路和提升技術氛圍。
• 好了，本章就總結到這，可能對具體的你或者具體的公司，會有不同的視角和結果。如果有一些好的點可以互相討論學習。另外最近學會了個新東西分享給大家：內卷的反義詞是：外包，合同的反義詞是：離異!