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

概述

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

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

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

[m_2_1]

我們從一次完整項目的發佈提及，一次完整項目的發佈，大概須要通過這幾個大的節點：

項目立項 -> 需求評審 -> 視覺稿評審 -> 技術評審 -> 項目啓動 -> 開發 -> 聯調 -> 測試 -> 發佈

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

那麼，一線管理者要作的就是保證每一個節點的質量，來保證整個項目的質量。

怎麼保證？往下看。

制定規範

技術評審規範

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

設計技術方案要從 整體 到 局部 ，作到面面俱到。

整體：

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

局部：

• 功能的變動
• 數據庫字段的變動
• 業務流程上的變動
• 上下游接口約定的變動

當技術方案肯定了，咱們就肯定了：

• 技術選型（前端/後端框架、日誌中間件、消息中間件、數據庫...）
• 技術架構（組件與組件之間如何協同工做，如何部署）
• 技術難點預知（明確存在的技術難點，並肯定解決方案）
• 性能瓶頸預知（明確可能存在性能瓶頸的地方，並肯定應對措施）
• 上下游系統交互（明確在流程中的哪一個位置，約定接口文檔提供時間、接口聯調時間）
• 功能模塊劃分（任務拆分和分配）

當技術方案肯定了，須要輸出文檔：

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

  功能除了包括正常的開發工做，還要包括 提供接口文檔，接口聯調，研發自測，文檔更新 等。

  正常的功能開發，拆分紅工時的顆粒度最大爲 2h，這樣的顆粒度可以下降工做的複雜度，使不熟悉相關業務的研發也可以快速上手，好比 2h 就寫一個方法。

• 更新項目文檔，包括 項目介紹、產品文檔、業務流程、系統結構、接口文檔、數據字段、外部依賴、其餘 等。

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

代碼風格規範

雖然代碼風格並不影響程序的運行，也不會給程序帶來潛在的危險，可是一段好的代碼風格，閱讀起來能讓人賞心悅目，特別是閱讀別人的代碼，就像本身寫的同樣。

根據本身使用的語言，制定代碼風格規範，可參考語言的相關標準，好比 PHP 有 PSR 。

代碼風格規範達成一致後，必定要落實到文檔上！！！方便其餘同事進行 CodeReview 時使用。

代碼開發規範

• 接入 統一可視化日誌 平臺。
• 接入 統一配置中心 平臺。
• 接入 統一異常監控 平臺。
• 接入 統一消息中間件 平臺。
• 異常處理規範：直接返回、拋出異常、重試處理、熔斷處理、降級處理。
• 統一 API 規範：HTTP 接口、RPC 接口，Code、Msg、Data 等。
• 分支開發規範：分支名稱規範、熱修復規範、上線規範 等。
• 其餘規範，你們能夠自行補充 ...

代碼管理規範

經常使用的代碼管理工具：Git、SVN。

工具的使用，你們都知道，就很少說了，約定一些基礎的規範。

• 不要提交本身的用戶配置，好比 IDE 配置。
• 不要提交不能經過編譯的代碼。
• 要早提交、常提交，提交以前要先更新。
• 提交信息必定要認真填寫，參考以下規範。

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

type 表示 動做類型，可分爲：

1. fix：修復 xxx Bug
2. feat：新增 xxx 功能
3. test：調試 xxx 功能
4. style：變動 xxx 代碼格式或註釋
5. docs：變動 xxx 文檔
6. refactor：重構 xxx 功能或方法

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

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

CodeReview 規範

說實話，因爲種種緣由，本身實施的並很差。

CodeReview 檢查哪些問題？

• 規範性檢查

  • 是否遵循代碼開發風格規範、代碼開發規範。
  • 是否全部的變量都被正肯定義和使用，註釋是否準確。

• 健壯性檢查

  • 是否無心中陷入了死循環。
  • 是否存在異常未處理、資源未釋放的狀況。
  • 是否存在運行時錯誤（數組邊界溢出、除以零的狀況）。

• 重用性檢查

  • 是否存在相同的方法寫了兩次，是否能夠寫成通用類、方法、組件等。

• 安全性檢查

  • 是否存在 SQL注入、XSS、SSRF、CSRF、越權、文件上傳 等漏洞。

• 性能檢查

  • 是否存在同步執行太慢，須要轉成異步執行的狀況。
  • 是否存在未加緩存，頻繁連接 DB 的狀況。
  • 是否須要使用鏈接池。

CodeReview 如何執行？

• 前期準備

  • 制定 CodeReview 規範和標準，這樣在審查過程當中能夠有據可依，有理可循。
  • 肯定 CodeReview 審查者、參與者。

• 實施期

  • 在 CodeReview 前，審查者需將 審查內容 及 審查的規範和標準 告知全部參與者和代碼做者。
  • 在 CodeReview 時，審查者要進行逐項審查，不能由於時間不足等因素一掃而過。
  • 在 CodeReview 後，審查者要對發現的問題，給予解決方案，同時進行問題記錄，便於過後跟蹤。
  • 審查者不能只在發現問題時提問，遇到不清楚的代碼設計和業務，也可讓代碼做者進行講解，便於本身熟悉整個業務和代碼設計。
  • 期間營造一個討論問題、解決問題的氛圍，不能搞成批判會，這樣會影響你們的積極性。

• 過後跟蹤

  • 對發現的問題，肯定修復的難易程度以及影響的範圍。
  • 對發現的問題，肯定修復完成的時間點。
  • 對發現的問題，修復後要進行驗證。

小結

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

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

這個問題... 首先要認可在大部分的公司中，業務代碼是剛需，由於是靠這些業務掙錢的，須要快速上線佔領市場的。

當隨着公司的發展，技術人員的擴充，規範確定要慢慢創建起來的，不然就會出現這樣那樣的問題。

若是公司就幾名技術人員，能夠先不用搞這些，優先快速發展業務吧。

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

推薦閱讀

• 一我的被提拔，不只僅是能力，而是信任