一線技術管理者究竟在管什麼事？

概述

上篇文章《一個人被提拔，不僅僅是能力，而是信任》中分享了兩個點：

什麼樣的工程師，容易被提拔？
當被提拔到一線管理者後，你的初衷是什麼？

這篇文章分享一線技術管理者究竟在管什麼事？

我們們從一次完整專案的釋出說起，一次完整專案的釋出，大概需要經過這幾個大的節點：

專案立項 -> 需求評審 -> 視覺稿評審 -> 技術評審 -> 專案啟動 -> 開發 -> 聯調 -> 測試 -> 釋出

有句話是這麼說的，通過控制過程質量，來保證結果質量。

那麼，一線管理者要做的就是保證每個節點的質量，來保證整個專案的質量。

怎麼保證？往下看。

制定規範

技術評審規範

在技術評審前要熟悉產品同學提供的產品文件、業務流程圖、互動原型圖，反覆與產品同學確認，在雙方達成一致的情況下，再設計技術方案。

設計技術方案要從總體到區域性，做到面面俱到。

總體：

總體結構圖
業務流程圖
時序圖
核心類圖

區域性：

功能的變更
資料庫欄位的變更
業務流程上的變更
上下游介面約定的變更

當技術方案確定了，我們就確定了：

技術選型（前端/後端框架、日誌中介軟體、訊息中介軟體、資料庫...）
技術架構（元件與元件之間如何協同工作，如何部署）
技術難點預知（明確存在的技術難點，並確定解決方案）
效能瓶頸預知（明確可能存在效能瓶頸的地方，並確定應對措施）
上下游系統互動（明確在流程中的哪個位置，約定介面文件提供時間、介面聯調時間）
功能模組劃分（任務拆分和分配）

當技術方案確定了，需要輸出文件：

預估開發工期.xlsx，包括 系統、模組、功能、功能簡述、研發人員、工時(h)、預計完成時間 等。

功能除了包括正常的開發工作，還要包括 提供介面文件，介面聯調，研發自測，文件更新 等。

正常的功能開發，拆分成工時的顆粒度最大為 2h，這樣的顆粒度能夠降低工作的複雜度，使不熟悉相關業務的研發也能夠快速上手，比如 2h 就寫一個方法。
更新專案文件，包括 專案介紹、產品文件、業務流程、系統結構、介面文件、資料欄位、外部依賴、其他 等。

這個分類可自定義，主要是為了解決當人員發生流動導致系統交接時產生遺漏的問題。

程式碼風格規範

雖然程式碼風格並不影響程式的執行，也不會給程式帶來潛在的危險，但是一段好的程式碼風格，閱讀起來能讓人賞心悅目，特別是閱讀別人的程式碼，就像自己寫的一樣。

根據自己使用的語言，制定程式碼風格規範，可參考語言的相關標準，比如 PHP 有 PSR 。

程式碼風格規範達成一致後，一定要落實到文件上！！！方便其他同事進行 CodeReview 時使用。

程式碼開發規範

接入統一視覺化日誌平臺。
接入統一配置中心平臺。
接入統一異常監控平臺。
接入統一訊息中介軟體平臺。
異常處理規範：直接返回、丟擲異常、重試處理、熔斷處理、降級處理。
統一 API 規範：HTTP 介面、RPC 介面，Code、Msg、Data 等。
分支開發規範：分支名稱規範、熱修復規範、上線規範等。
其他規範，大家可以自行補充 ...

程式碼管理規範

常用的程式碼管理工具：Git、SVN。

工具的使用，大家都知道，就不多說了，約定一些基礎的規範。

不要提交自己的使用者配置，比如 IDE 配置。
不要提交不能通過編譯的程式碼。
要早提交、常提交，提交之前要先更新。
提交資訊一定要認真填寫，參考如下規範。

<type>(scope)：<subject>，比如：fix(首頁模組)：修復彈窗 JS Bug。

type 表示動作型別，可分為：

fix：修復 xxx Bug
feat：新增 xxx 功能
test：除錯 xxx 功能
style：變更 xxx 程式碼格式或註釋
docs：變更 xxx 文件
refactor：重構 xxx 功能或方法

scope 表示影響範圍，可分為：模組、類庫、方法等。

subject 表示簡短描述，最好不要超過 60 個字，如果有相關 Bug 的 Jira 號，建議在描述中加上。

CodeReview 規範

說實話，由於種種原因，自己實施的並不好。

CodeReview 檢查哪些問題？

規範性檢查
- 是否遵循程式碼開發風格規範、程式碼開發規範。
- 是否所有的變數都被正確定義和使用，註釋是否準確。
健壯性檢查
- 是否無意中陷入了死迴圈。
- 是否存在異常未處理、資源未釋放的情況。
- 是否存在執行時錯誤（陣列邊界溢位、除以零的情況）。
重用性檢查
- 是否存在相同的方法寫了兩次，是否可以寫成通用類、方法、元件等。
安全性檢查
- 是否存在 SQL隱碼攻擊、XSS、SSRF、CSRF、越權、檔案上傳等漏洞。
效能檢查
- 是否存在同步執行太慢，需要轉成非同步執行的情況。
- 是否存在未加快取，頻繁連結 DB 的情況。
- 是否需要使用連線池。

CodeReview 如何執行？

前期準備
- 制定 CodeReview 規範和標準，這樣在審查過程中可以有據可依，有理可循。
- 確定 CodeReview 審查者、參與者。
實施期
- 在 CodeReview 前，審查者需將審查內容及審查的規範和標準告知所有參與者和程式碼作者。
- 在 CodeReview 時，審查者要進行逐項審查，不能因為時間不足等因素一掃而過。
- 在 CodeReview 後，審查者要對發現的問題，給予解決方案，同時進行問題記錄，便於事後跟蹤。
- 審查者不能只在發現問題時提問，遇到不清楚的程式碼設計和業務，也可以讓程式碼作者進行講解，便於自己熟悉整個業務和程式碼設計。
- 期間營造一個討論問題、解決問題的氛圍，不能搞成批判會，這樣會影響大家的積極性。
事後跟蹤
- 對發現的問題，確定修復的難易程度以及影響的範圍。
- 對發現的問題，確定修復完成的時間點。
- 對發現的問題，修復後要進行驗證。

小結

如上就是一線技術管理者要做的事，這些只是管事當中的一小部分。

我猜想，有些讀者可能會有這個問題：哪來的時間呀？業務程式碼天天加班都搞不完，哪些時間搞這些？

這個問題... 首先要承認在大部分的公司中，業務程式碼是剛需，因為是靠這些業務掙錢的，需要快速上線佔領市場的。

當隨著公司的發展，技術人員的擴充，規範肯定要慢慢建立起來的，否則就會出現這樣那樣的問題。

如果公司就幾名技術人員，可以先不用搞這些，優先快速發展業務吧。

當各位發現有哪些地方不對或不完善的地方，歡迎批評指正。