概述
上篇文章《一個人被提拔，不僅僅是能力，而是信任》 中分享了兩個點：
- 什么樣的工程師，容易被提拔？
- 當被提拔到一線管理者后，你的初衷是什么？
這篇文章分享 一線技術管理者 究竟在管什么事？
咱們從一次完整項目的發布說起，一次完整項目的發布，大概需要經過這幾個大的節點：
項目立項 -> 需求評審 -> 視覺稿評審 -> 技術評審 -> 項目啟動 -> 開發 -> 聯調 -> 測試 -> 發布
有句話是這么說的，通過控制過程質量，來保證結果質量。
那么，一線管理者要做的就是保證每個節點的質量，來保證整個項目的質量。
怎么保證？往下看。
制定規范
技術評審規范
在技術評審前要熟悉產品同學提供的產品文檔、業務流程圖、交互原型圖，反復與產品同學確認，在雙方達成一致的情況下，再設計技術方案。
設計技術方案要從 總體 到 局部 ，做到面面俱到。
總體：
- 總體結構圖
- 業務流程圖
- 時序圖
- 核心類圖
局部：
- 功能的變更
- 數據庫字段的變更
- 業務流程上的變更
- 上下游接口約定的變更
當技術方案確定了，我們就確定了：
- 技術選型（前端/后端框架、日志中間件、消息中間件、數據庫...）
- 技術架構（組件與組件之間如何協同工作，如何部署）
- 技術難點預知（明確存在的技術難點，並確定解決方案）
- 性能瓶頸預知（明確可能存在性能瓶頸的地方，並確定應對措施）
- 上下游系統交互（明確在流程中的哪個位置，約定接口文檔提供時間、接口聯調時間）
- 功能模塊划分（任務拆分和分配）
當技術方案確定了，需要輸出文檔：
-
預估開發工期.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 后，審查者要對發現的問題，給予解決方案，同時進行問題記錄，便於事后跟蹤。
- 審查者不能只在發現問題時提問，遇到不清楚的代碼設計和業務，也可以讓代碼作者進行講解，便於自己熟悉整個業務和代碼設計。
- 期間營造一個討論問題、解決問題的氛圍，不能搞成批判會，這樣會影響大家的積極性。
-
事后跟蹤
- 對發現的問題，確定修復的難易程度以及影響的范圍。
- 對發現的問題，確定修復完成的時間點。
- 對發現的問題，修復后要進行驗證。
小結
如上就是一線技術管理者要做的事，這些只是 管事 當中的一小部分。
我猜想，有些讀者可能會有這個問題：哪來的時間呀？業務代碼天天加班都搞不完，哪些時間搞這些？
這個問題... 首先要承認在大部分的公司中，業務代碼是剛需，因為是靠這些業務掙錢的，需要快速上線占領市場的。
當隨着公司的發展，技術人員的擴充，規范肯定要慢慢建立起來的，否則就會出現這樣那樣的問題。
如果公司就幾名技術人員，可以先不用搞這些，優先快速發展業務吧。
當各位發現有哪些地方不對 或 不完善的地方，歡迎批評指正。