摘要： 本文將會討論如何協調公司內各個工程師團隊之間的合作，從而高效地保持系統的彈性和靈活性，以滿足敏捷開發的需求。本文選自《Node.js微服務》。

　　如果一個公司採用微服務來構建軟體系統，那麼每個干係人都需要參與決策。
　　微服務是一次重大的正規化轉換。通常，大型組織傾向於使用相當傳統的方式來構建軟體系統。每個重大發布需要經歷數月的研發週期，之後需要一個完備的質量保證階段以及數小時的部署階段。
　　當一個公司選擇使用面向微服務的架構時，方法論就會發生完全的改變：每個小團隊負責各自的小功能點，包括它們的構建、測試和部署。每個團隊各司其職，並且能夠處理好各自負責的單一事項（一個微服務，或更確切地說是數個微服務），每個團隊成員將熟練掌握構建軟體系統的相關技術與領域知識。
　　這通常被稱為跨職能團隊。這是一個由少數人組成的工作單元，他們都具備了構建高質量軟體元件的能力。
　　有一點值得注意的是，團隊成員應當掌握必要的領域知識來理解業務需求。
　　在我的職業生涯中，大多數導致公司失敗的主要問題不外乎以下這點（就我個人觀點而言）。首先，有一種觀點認為開發者是“堆磚器”，即可以在沒有提前溝通的情況下卻依然能神奇地理解業務流。而且，還有觀點認為，如果一個開發者一週可以完成X 量級的工作，那麼10 個開發者一週就可以交付10X 量級的產量。這些觀點都是錯誤的。
　　為了保持高效以及考慮到康威定律在改變業務流程方面對系統的影響，構建微服務的跨職能團隊中的成員必須熟練掌握（不僅僅是瞭解）相關領域知識。
　　每當談及微服務的組織架構適配時，自治才是關鍵因素。為了保證構建微服務的敏捷性，每個團隊都必須保持自治，這也意味著要確保技術的自主選擇權，如下所示：

• 使用的語言。
• 程式碼規範。
• 解決問題的模式。
• 各類工具的選擇，比如軟體的構建、測試、除錯及部署工具。

這是非常重要的部分，因為這是我們需要定義公司如何構建軟體，並且可能會引入工程問題的部分。
　　舉個例子，我們來看看程式碼規範問題，如下所示：

• 我們需要在所有團隊內都保持統一的程式碼規範嗎？
• 我們應該讓每個團隊都有各自的程式碼規範嗎？

一般來說，我偏好於“80%準則”：80%的完美度已經足以涵蓋100%的使用場景。這意味著放寬程式碼規範（也適用於其他領域），以及允許一定程度的不完美或者個性化，都有助於減少團隊間的摩擦，也能讓工程師能夠儘快關注到那些極少數的重要準則，比如日誌策略以及異常處理。
　　如果你的程式碼規範過於複雜，那麼在某個團隊想要向其他團隊的微服務提交程式碼時就會遇到很多阻力（切記，一個團隊擁有自己的服務，但是其他團隊的成員也可以對這個服務做出貢獻）。
　　

　　想及時獲得更多精彩文章，可在微信中搜索“博文視點”或者掃描下方二維碼並關注。