技術主管的瑞士軍刀

　　作為一名技術主管的工作是令人非常振奮的，你每天都需要應對新的挑戰，要解決新的問題，以此獲得很大的滿足感。但有些時候，為了改進你的團隊，讓它變得更強大，你還需要一些提示。有許多種技術可以保證我們所生產的產品質量，但其中最重要也是最強大的一點毫無疑問是反饋迴圈。如你所知，開發新軟體比起科學研究更依賴於經驗，這也是我們需要衡量指標以及小型的、但增量式的改進的原因，只有這樣才能夠滿足使用者或客戶的需求。反饋迴圈是一種非常基礎的、但又是非常強大的方法，它能夠幫助我們和我們的團隊通過每天的努力工作最終取得成功。通過反饋迴圈，你可以保證獲得反饋以及衡量指標，讓它們幫助你進一步改進你的產品。此外，多虧了反饋迴圈的存在，你可以將這些資料指標展現給經理層或技術架構師，以調整產品的技術決策，併為他們展示專案的進展情況，以及在開發流程中你的團隊所遇到的問題。

　　下面這些技術中的大多數也許已經存在於你的組織中了，但你或許希望能夠獲得不同的指標，或縮短反饋迴圈，以便通過更多的資訊來決定要採取哪種最佳的策略。

　　在本文中，我將樂於分享一些方法，以幫助你實現作為一名技術主管的最終目標，那當然就是打造一個強壯的技術環境，讓開發者們可以依賴這個環境，並使他們每天都能夠發揮出最高的水平，讓他們感到安全，並且清楚地掌握程式碼的質量。

　結對程式設計與程式碼複審

　　有兩種技術能夠為你帶來第一時間的反饋以及益處，它們當然就是結對程式設計與程式碼複審。

　　讓我們首先從結對程式設計開始。

　　當我們考慮這項技術的時候，首先要向經理證明，讓兩個人同時編寫同一份程式碼的做法是否值得。如果你對結對程式設計已經有了足夠的經驗，那麼你應該能夠將生產力的下降控制在15%之內，同時做到增加程式碼的質量，並且促進團隊成員之間共享知識，這種方式還能夠幫助你在開發過程中儘早地發現bug。最後一點看起來只是個很小的改進，但儘早發現bug有助於減少修復bug所消耗的精力，而如果你之後才發現這個bug，那麼公司可能會為此付出更大的代價，因為要理解一個“陳舊的”實現方式可能要付出兩倍、甚至更多的精力。在進行結對程式設計的過程中，你需要記住兩件事。首先，你應當鼓勵團隊每天進行幾個小時的結對，並且每30分鐘變換一次角色。其次，你應當建立一種適合結對程式設計的工作環境，開發者們唯一要做的就是為了實現這個軟體而編寫程式碼，因此不要安裝郵件客戶端或聊天工具，只要滿足在這個專案上工作的最小化配置就足夠了。

　　現在讓我們來看一看程式碼複審。

　　我經常看到由於時間已經接近某個迭代的結束，甚至是接近最終的交付期限，而選擇忽略程式碼複審這個實踐的情況。程式碼複審對於將程式碼知識傳遞給所有團隊成員、維護程式碼的一致性以及從技術角度改善專案來說是十分重要的。在我看來，主要問題在於程式碼複審往往是在程式碼完成幾天之後才進行的，而如果你沒有采取適當的做法，很可能會失去這一實踐所帶來的所有益處。如果你想從這個實踐從獲得最大的益處，我建議的做法是，當你在版本控制系統中籤入程式碼之後，在同一天之內請你的同事幫助你檢查你的程式碼。可以安排在一天之中專門抽出一些時間用於檢查其他開發者的程式碼。記住，如果程式碼複審做好了，它將會成為一種非常強大與有效的手段。

　增量式設計

　　這一點絕對是我最喜愛的反饋迴圈方式，如你所知，對任何專案進行過度的前期設計通常會導致錯誤的假設和誤解，並且在技術方面會進行過多的猜測。從架構的角度來說，開發一個專案最好的方式是在每個專案開始時建立剛好足夠的架構，只要它能夠滿足你和你的團隊著手開發就好。然後在每個迭代剛開始的30分鐘至2小時之內對架構與設計進行增量式的複審，專注於這個新迭代必須完成的任務。通過這種方式，你將建立出一種合理的架構，它能夠完美地涵蓋你的客戶或公司的需求，並促進新特性的實現或進行重構。你將看到，在專案的開始階段，你會在架構上投入較多的時間，但等到幾個迭代結束之後，你會發現在架構上的投入時間減少了，你的架構的穩定性與高質量將會為你帶來很大的益處。設計架構的最佳方式是使用一塊白板，這樣就能夠從其他成員那裡獲得第一時間的反饋，並且你可以在白板上快速地新增、修改或是刪除任意元素。記住，如果架構文件不能保持更新，在公司中就起不了任何作用。既然程式碼本身就能夠解釋各種設計決策，何必還要使用各種昂貴的建模軟體呢？

　　我個人在這方面的建議是，建立一個高階別的架構圖，讓它反映出系統中的主要元件是如何互動的，這樣就能夠了解你的架構是否可行，或者是需要繼續改善。在這種情況下，很容易就能夠生成這樣一份架構文件，並且修改它也不需要花費很大的精力。

　靜態分析

　　每一位技術主管都應當掌握靜態分析技術，因為它能夠為你提供實用的指標，幫助你指出專案中的潛在問題，並著重指出需要改進的地方。在最常見的一些技術中，例如Java、C#或JavaScript都提供了豐富的工具，以幫助你獲取有關程式碼的資訊，例如程式碼圈複雜度（cyclomatic complexity）或是為你展現專案的架構。在伺服器上安裝類似於SonarQube這樣的工具同樣能夠幫助你實現這一目標。對於你的團隊中所使用的任何一種技術，你都應當設定相應的規則讓程式碼符合公司的規範。請記住定義這些必須遵循的規則，並對流程進行自動化，以促進你的團隊去檢查這些反饋資料，並通過資料瞭解到當前的問題。因為衡量指標能夠幫助你改善現狀，否則你很難了解某個變更是否改善了你的軟體。

　版本控制

　　作為技術主管，你應當成為整個公司的程式碼監護人。如果你的程式碼一團糟，那麼在幾年、甚至只是幾個月之後，整個公司或某個團隊就無法繼續維護這個專案，或者是在實現新特性或分析如何解決bug時痛苦萬分。

　　關於這一點，我建議你牢記一點，並且提醒你的同事，那就是“童子軍規則”：

　　“永遠保持離開時的露營地比你發現它時更整潔”

　　目前最佳的方案是使用GIT或Mercurial。GIT的知名度更高，並且有許多公司都在使用它，因此也意味著關於它的資源與文件更多，這也是我推薦你使用GIT作為版本控制系統的原因。但很常見的一種狀況是，某個公司雖然在使用GIT，但沒有采取任何分支策略，這導致每個專案都處於無組織狀態。你應當通過實現一種GIT流或GitHub流策略以避免出現這種情形。你會發現，實現這兩種策略之一會提高你的開發者的生產力，並且能夠避免在合併不同的分支時經常出現的衝突問題。所有開發者都應記得的另一點是在提交程式碼時適當地使用tag，並且提供有意義的註釋。尤其是當你開發的軟體準備公開發行或是建立某些類庫時，在建立分發包之前對你的每個穩定版本的程式碼進行tag是必須的。最後，但並非最不重要的一點是，在開發者提交程式碼時，要求他們準確地描述他們改變了哪些內容，並且如果可能的話，儘量做到頻繁地提交，這樣能夠讓他們更容易撤消程式碼或是處理程式碼中的衝突。

　自動化

　　如果在公司級別上還沒有定義自動化的目標，那麼在每個專案的開始階段就應當進行定義。在專案開發過程中必須有一種可複製的、並且可部署的解決方案，可以在開發過程中不斷地重複應用。這樣才能夠保證最終所交付的產品是正確的，並且避免接近專案交付日期時才發現的各種問題。通常來說，你應該實現以下功能的自動化：

• 對專案的各種突變測試、整合測試、驗收測試、迴歸測試與功能測試進行自動化，儘可能將你的版本控制方案與你使用的自動化工具結合在一起，讓它測試每次程式碼提交，或是每次對development或master分支進行合併時執行測試。
• 在每次構建之前進行靜態分析能夠幫助你確保程式碼標準以及產品的質量
• 對每次tag操作或釋出進行tag流程及版本控制管理
• 將專案部署到測試環境中，以便QA人員進行測試
• 將專案部署到生產環境

　　當你在專案的開始階段定義了這些步驟之後，你將發現，當你不得不在某個專案上線幾個月或幾年之後對它進行重新編譯時能夠避免大部分的常見問題，你也能夠在程式碼一次次釋出的過程中調整它們的質量，保證一個很高的程式碼標準，並獲得所需的衡量指標，以計劃某種在你的團隊或整個公司之內進行改進的策略。

　敏捷方法

　　你需要維護的東西不僅僅是技術流，資訊流也是任何專案取得成功的關鍵所在。沒錯，你不是一位Scrum Master，但你應當幫助Scrum Master去促進資訊的流動，甚至幫助產品負責人定義使用者故事，並瞭解在適當的時機加入一些技術性的使用者故事以改善程式碼質量，通過指出潛在的技術問題幫助團隊調整使用者故事的規模等等。因此，出於這些以及其它多種原因，對於技術主管來說，充分地瞭解例如Scrum、Kanban和XP等最常用的框架是十分重要的。因為作為一名領導，你應當能夠通過示範的方式領導你的團隊，為他們展現，並鼓勵他們遵循敏捷的最佳實踐，並指導他們獲得成功。

　實踐社群（COP）

　　對於任何技術團隊來說，在每天的日常工作中分享經驗和知識，從而提升自己是必須做到的一件事。組織一種兩週一次或每月一次的實踐社群能夠有效地幫助我們實現這些目標。一般來說，COP是一次講座，技術團隊中的某些可以將他或她在目前所接手的專案中使用的某個優秀的方案，或是某種對整個團隊很實用的最新技術或方法論分享給大家。如果公司的規模足夠大，我建議可以按照技能種類劃分這些會議，某個COP專門針對QA，某個針對後端開發者，另一個針對前端開發者等等。這樣一來，會議的內容也會變得更垂直與更實用，而不是浪費時間討論一些大家在短期內或較長一段時間內不會用到的技術或方法學。一次出色的實踐社群活動應當在舉辦前7至10天開始準備，推舉出1至3個演講者，讓每個人進行20至30分鐘的演講。如果演講者只有一人，我建議讓他準備一個最多45分鐘的主題，然後將活動的第2部分用於問答與討論。

　　在會議中設立一位協調者是必須的，至少在第2階段，他可以鼓勵與會者分享他們對於演講內容的想法。保持整個會議環境更友好並且易於合作，這有助於團隊在表現它們的技巧時更為自信。這種方式也能夠產生一種共享的知識，通過它促進在整個組織中引入新技術和方法學的過程。作為技術主管，你應當有能力組織這種會議，促進大家的交流，並且找到讓整個部門或公司都感興趣的主題。有時候，為了打破每日工作的重複性，我建議可以一共觀看一些技術會議的視訊或是會議講座，或是邀請某些外部的演講者為團隊分享一些垂直的主題，然後對此進行開放式的討論。

　總結

　　以上所說的這些都是作為一個技術主管應當掌握的關鍵工作與技術，並且應當在他或她的每日工作中鼓勵同事也這麼做。

　　你必須保持靈活，並擁有足夠的技能，在任何情況下都採取正確的方式，讓它保持與你的業務需求一致，並且符合公司的戰略。

　　最後，但並非最不重要的是，我樂於為你分享我最喜愛的一條格言，以鼓勵你開始改進你的標準：“千里之行，始於足下” —— 老子。

　關於作者

　　Luca Mezzalira來自於義大利，他是一位熱情的技術主管，在前端技術，例如Javascript、HTML5、CSS、Actionscript、Haxe和Lua方面具有超過10年的經驗。Luca對於軟體架構方面體現出了極大的熱情，並且高度專注於為每個專案建立最好的解決方案，以實現專案的主要目標。他目前居住在倫敦，專注於研究JavaScript框架與庫，尤其是React和React Native，以及web和移動效能，當然還有敏捷技術。Luca也是一位國際性的演講者（在全球已經進行了超過60場演講）、是倫敦敏捷領導社群的共同組織者，也是Packt Publishing出版社的技術審查員。

　　英文原文： The Swiss Army Knife for Technical Leads