前端工程優化之路

本文首發於歐雷流《前端工程優化之路》

在我加入「買好車」後第一次把項目代碼從遠程倉庫拉取到本地時——「這是什麼玩意？！」——個人心裏是震驚並詫異的。

爲何我會有如此反應？

「買好車」是一傢俱備阿里基因的公司，創始人和員工不少來自阿里。衆所周知，阿里的技術是很不錯的，基本每一年都會主辦一些技術會議，有些技術書籍也是阿里人著做或翻譯的。所以，心理上會對他們在技術方面有較高的預期。然而，呈如今眼前的現實將我從幻想中拉了出來……

代碼維護

不像大部分團隊那樣先後端代碼放在一塊兒維護，咱們的項目代碼是分開管理、維護的，即先後端代碼不在同一個 Git 倉庫當中。前端代碼只有一個倉庫，存放了公用資源、活動頁、主站等不一樣業務線的代碼，每一個項目是一個目錄；後端代碼以項目爲單位分爲幾個不一樣的倉庫存放。部署上線也是分開進行。

這種作法美其名曰「先後端分離」，實際究竟是不是，值得思考。

Git 的使用

團隊在使用 Git 時主要存在兩方面問題：分支管理策略和代碼提交準則。

分支管理策略

每次打開 SourceTree，首先映入眼簾的就是五光十色的「彩虹線」——

和好些過時的分支——

.
└─┬─ origin
  ├─── dev_frontend
  ├─── dev_general
  ├─── dev_inquiry
  ├─── dev_maiche
  ├─── pub_20160111
  ├─── pub_20160112
  ├─── pub_20160113
  ├─── pub_20160114
  ├─── pub_20160128
  ├─── pub_20160202
  └─── ...

看得我簡直是頭暈目眩，不知從何「編」起啊！

形成這種狀況的最直接的緣由就是，沒有一個好的分支管理策略。這裏的分支管理策略是這樣的：

每週有兩個固定的發佈日，在每一個發佈日以前某個管理髮布的測試工程師（是的，咱們沒有運維工程師）會基於 master 分支建立前綴爲 pub_ 的發佈分支，在發佈以前會將要發佈的內容都彙總在這個分支上進行測試，經過後再合併到 master 分支上進行發佈。然而，發佈完不會馬上將那個分支刪掉，而是要保留幾個星期以免出問題。這樣就會像上圖中那樣有好多過時的分支留在那裏。

有些不是馬上發佈的內容，後端工程師們就會本身基於 master 分支建立出 dev_ 爲前綴的分支來開發新內容。

雖然他們在建立分支時都是有必定的規則，但這種作法產生了一些「垃圾」分支，以及使 master 分支看起來不那麼穩定，像定時炸彈同樣隨時會「嘭」！

我以爲團隊中應該採用 Git Flow 來管理分支，這是一個不知通過多少團隊驗證的分支模型，我有信心它可以應對咱們團隊所遇到的各類場景。

代碼提交準則

咱們團隊的 Git 提交記錄很「簡單」，要麼寫着幾個簡單的字母或詞語，要麼就是合併分支時生成的節點，一眼望去根本不知道那些人到底作了什麼。這若是是想查找某個功能點的更改記錄，得逐個節點去分析。

在使用 Git 時應該遵照一個基本原則——使提交記錄儘量簡潔詳細，看它就像讀一本書。要達到這種效果，只需牢記幾點：

• 控制提交粒度；

• 填好提交信息；

• 調節推送頻率；

• 多衍合少合併。

要使每一個提交都具備意義，粒度最好控制爲一個小 feature 或者一個 bug fix，這樣進行恢復等操做時可以將「誤傷」減到最低。

一個好的提交信息是，用一句簡練的話寫在第一行，而後空一行略微詳細地闡述該提交所增長或修改的地方：

Redirect user to the requested page after login

https://trello.com/path/to/relevant/card

Users were being redirected to the home page after login, which is less
useful than redirecting to the page they had originally requested before
being redirected to the login form.

* Store requested path in a session variable
* Redirect to the stored location after successfully logging in the user

不要每提交一次就推送一次，多積攢幾個提交後一次性推送，這樣能夠避免前一個提交後發現代碼中還有小錯誤，這時能夠經過衍合進行提交的合併或者信息修改。

爲了保持圖表清晰和代碼完整性，要掌握好提交和推送操做的時機——

尚未推送到遠程倉庫時，如無必要則只提交不要推送，只在須要與他人配合開發時再推送。當所在分支已經完成職責時，需將父級分支的代碼衍合到當前分支（得先保證父級分支在本地是最新的），而後合併至父級分支並刪除當前分支。理想狀況是，這個分支的整個生命週期沒有進行過一次推送操做。

當已經推送到遠程倉庫時，先積累幾個提交的內容而不去作提交操做，等到要推送時先拉取代碼到本地，而後按照上述粒度作幾回提交，再推送到遠程服務器。這種操做流程可以有效避免因代碼衝突而形成的提交丟失等意想不到的問題，以及減小因合併產生的提交節點。

擴展閱讀

• A successful Git branching model

• 5 Useful Tips For A Better Commit Message

• How to Write a Git Commit Message

前端工程

與整個技術團隊相比，前端團隊中所存在的問題更多更爲嚴重！基本能夠歸納爲如下幾點：

• Git 倉庫混雜了不少不一樣的業務；

• 源代碼複用性低；

• 沒有合理使用構建工具；

• 靜態資源文件的發佈流程繁瑣；

• 活動頁面的編寫方式麻煩，而且對搜索引擎不友好。

我做爲一名前端工程師，雖然暫時沒法去對整個技術團隊作些什麼，可是做爲前端團隊的一員，卻能夠在前端團隊中作些力所能及的事情。在我看來，「有問題」就表明着「機遇」，該是我大展拳腳的時候了！想起來都以爲腎上腺素大量分泌，熱血沸騰！

那麼，我該作些什麼呢？

我所想到的可以提升前端團隊工做效率和生產力的手段有：

1. 制定編碼及文件存放等的規範和約定；

2. 選擇高效的語言編寫源碼；

3. 選擇合適的自動化工具；

4. 保證以上幾條順利執行的措施。

爲了提升前端團隊的總體素質和實力，須要作的事情還有不少。想要完成這些不是一朝一夕的事情，前端工程優化之路任重而道遠啊……

想在已有的項目上進行改造會存在着很大的阻力，幸虧這時公司業務拓展要開發新項目。決定從這新的項目着手，小試牛刀，總結出一套方案後推行整改到其餘項目。

以本文爲引，日後會寫幾篇關於咱們前端團隊建設的文章，敬請期待！