從一件小事聊聊軟件工程師的自我修養 | 掘金年度徵文

時間 2019-11-16

標籤一件 1件小事聊聊軟件工程師自我修養年度徵文简体版

原文原文鏈接

思考：若是讓你制定代碼提交規範（Git工具），你會怎麼作？html

被忽略的細節

代碼的提交信息是開發中一個很小的細節，因爲它自己對代碼運行自己不形成任何影響，主要做用在於方便查找、回退代碼，因此很容易被開發者忽略。可是它的意義就像項目文檔、註釋同樣，是高質量項目必備的內容，好的提交信息不只能幫助開發者快速找到指定版本的代碼，同時節體現的也是開發者的習慣和意識。前端

這篇文章想和你們聊聊這個小小的細節和軟件工程師（如下簡稱工程師）的修養，或許能給那些初入職場或處於職場上升瓶頸期的讀者一些啓發。git

咱們如今的項目的代碼提交信息比較亂，因此頗有必要創建一個代碼提交規範。github

下面就以3個不一樣工程師的處理方式來聊聊工做中的自我修養。web

普通工程師

除非作過相似的工做，否則接到任務的第一件事通常是打開瀏覽器搜索「代碼提交規範」之類的關鍵字，會發現相關結果不少。經過一番整理，獲得下面的信息：shell

提交信息的編寫格式

<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>

type：提交類型，可選值以下
* work: 開發中(work in progress)
* feature：新功能(new feature)
* fix：修補bug(fix bug)
* doc：文檔(documentation changes)
* style： 格式(change code format)
* refactor：重構(modify code but not feature)
* test：增長測試(test code)
* chore：構建過程或輔助工具的變更(changes don't modify src and test files, only config or tasks) scope： 用於說明 commit影響的範圍，好比數據層、控制層、視圖層等等，視項目不一樣而不一樣。 subject：commit 目的的簡短描述。 body: 對本次 commit 的詳細描述 footer: 描述一些特殊狀況，不兼容變更和issue關閉。 複製代碼

編寫提交信息的工具

好比Commitizen，基本操做以下：npm

# 安裝命令行工具
npm install -g commitizen

# 安裝依賴
commitizen init cz-conventional-changelog --save --save-exact

# 經過擴展命令提交
git add .
git cz
複製代碼

把上面的編寫格式整理成文檔，而後在項目中安裝依賴試用如下，任務完成~瀏覽器

進一步思考

可是這只是作爲普通工程師的標準，優秀工程師該怎麼思考呢？bash

優秀的工程師和普通工程師的區別在於會反思工做並主動改進。也就是說不僅知足把事情作完，而是主動把事情作好。 把事情作好大體有兩種：前端工程師

別人都能作的，可是你作得和別人不同。
別人不能作的但你能作。

顯然制定提交規範屬於第一種狀況，因此優秀的工程師會進一步思考。

優秀工程師

目前的方案有沒有可改善的地方？

編寫格式

每次提交的信息須要編寫的內容很是多，若是每次提交個代碼像寫篇小做文同樣麻煩，必然會引發反感。這就比如原本開車上班路上時間不到半個小時，可是如今要求低碳出行只能騎自行車要1個小時，這種規定的可行性就很低了。因此精簡：

當文件路徑較長或者數量較多時scope會變得很長，影響查看subject。並且修改的文件（夾）名稱也能夠在查詢具體提交記錄的時候查找出來。更麻煩的是若是提交的時候漏寫或寫錯了還會起副作用，因此省略。
body和footer都屬於對提交的詳細描述，合併成可選項description。

提交工具

git cz命令雖然能夠替代git commit命令來提交代碼，可是它的有工程師不使用git cz而仍然使用git commit命令來提交代碼則校驗就會失效。因此須要一個校驗工具來保證咱們的規範有效的執行，至於工具git早已經爲咱們準備好了——鉤子。鉤子相似於web組件的生命週期，能夠在執行某些操做先後觸發對應的shell腳本。與git commit命令相關的鉤子有4個，按順序分別是：

pre-commit。提交前觸發，不接收參數，能夠執行一些文件校驗的工做。
prepare-commit-msg。提交前觸發，接收消息參數，用於在提交以前附加一些內容。
commit-msg。提交前觸發，可接收消息參數，用於檢查提交消息是否符合規範。
post-commit。提交後觸發，可執行自動推送、部署代碼等操做。

這裏咱們選擇commit-msg來實現，對應的腳本會像下面的樣子：

#!/bin/sh 
if grep -Eq "^(work|feature|fix|refactor|doc|test|chore|style|revert):\s*\w+" "$1"; then
  exit 0
else
  echo "Please format your commit message as follow:"
  echo "<type>:<title>"
  echo "<description>(optional)"
  exit 1
fi
複製代碼

目前的方案有沒有能夠補充的地方？

造成規範

規範就像是制度，好的制度不只須要制定者花心思去設計，更須要執行者知曉和配合。因此有了文檔和工具以後須要考慮的另外一件事就是在團隊內部推廣。推廣的方式經常使用的有作個PPT開會培訓一下，或者把資料放到團隊的wiki上提醒你們查看，這裏就不詳述了。

再進一步

到了這一步，任務不只作完了，並且也算是作好了。但要實現我的的最大提高，優秀還不夠，必須卓越。因此除了把事情作好以外，還應該考慮將它最大價值化。

卓越工程師

再回到例子中，這個解決方案有沒有可能用於其它團隊/場景？

通用性

編寫格式這一塊基本上沒有太多問題，可是提交工具會成爲一個較大的障礙。Node.js一般只是前端團隊的工具。若是要在其它團隊中推廣使用，學習成本不說，還會在項目中引入額外的依賴，可操做性並不強。

那是否是也要針對其它開發語言的項目去找合適的解決方案？這固然能夠但不見得是最好的方式，由於時間成本過高，最好的方式是找到一個通用解決方案。

仍是鉤子

其實這個方案git早已經爲咱們提供好，仍是以前用到的鉤子。雖然commitizen這類Node.js模塊不是跨語言的解決方案，可是其採用按步驟給出提示語，而後由用戶輸入的交互方式，對於不熟悉規範的人來講仍是比較好的。因此咱們能夠在鉤子腳本中沿用這種形式。

但對於熟悉規範的開發者來講可能但願直接使用git commit命令一次性提交，因此還加入一些校驗——對於不符合規範的提交信息給出交互提示，引導開發者按步驟完成提交信息。因爲腳本內容較長，這裏就不貼出來了，感興趣的讀者能夠去文末的倉庫地址中查看。

完善

若是要作得更完美一些可使用git提供的template功能，具體使用能夠查看文末提供的倉庫地址。

總結

工做態度決定了工程師的潛力，思考維度決定了工程師能力的天花板（固然這句話在別的崗位也可能通用）。

制定提交規範雖然只是一件很小的事，可是能夠從中總結出不一樣級別工程師在這兩個方面的差別：

	普通工程師	優秀工程師	卓越工程師
工做態度	公司安排什麼就作什麼、學什麼，缺少主動意識。	能完成公司安排的任務，有時候還會超預期完成，同時在工做之餘會利用時間學習。	不只能經常超預期完成公司的任務，同時還會主動思考團隊、產品現有的問題或能夠改進的地方並給本身安排任務
思考維度	單1、點狀的。只關注任務自己，只考慮如何完成任務	線性、縱向的。會思考任務背後的目標，以及怎樣才能更好的達目標而不只是完成任務	網狀，全局的。切換身份思考，讓任務成果對組織產生最大價值