如何正確地執行多元語言

您正在採用 Erlang；除非您是一個沒有現有程式碼庫的新公司，否則，這表示您打算成為一個多元語言組織。即使您的路線圖計畫完全替換所有現有程式碼，在轉換期間，您還是必須具備多元語言能力。因此，您應計畫適當地支援多元語言工作流程。

在本章中，我們將涵蓋常見的多元語言迷思和誤導性觀念，建議強制執行語言可行性的標準，並提出組織可能會經歷的一些具有挑戰性的重點。

多元語言迷思

當工程師開始討論將一個組織轉變為多元語言的想法時，就會出現許多信念和論點。讓我們看看常見的抱怨

• 隨著需要支援更多工具和建置鏈，建置工程變得更加複雜
• 需要稽核和維護更多依賴關係才能隨時保持最新狀態
• 隨著時間推移，某些語言變得不受歡迎，需要花費更多精力進行培訓、徵才或重寫
• 我們已經在進行多元語言，並且有一個元件沒有人願意碰，因為一位開發人員曾經使用沒有人知道的語言編寫它

建置工程是一個合法的考量，就像許多擁有專職 IT 部門的組織會為每個開發人員發出一種電腦以減少必須支援的組態數量一樣。話說回來，隨著普遍容器化的出現，這個問題變得不那麼普遍。Docker 影像和執行時期（例如 Kubernetes）已經提供了一種統一介面，從本地開發延伸到生產執行。在熟悉內部程式設計語言的人員的協助下維護建置影像，主要會隨著時間降低所有相關事物的複雜性。

除了使用會掃描和回報問題給您的工具之外，並沒有什麼好的方法可以解決依賴關係爆炸和監控，除了使用會掃描和回報問題給您的工具之外。依賴關係表面積主要是在管理複雜性方面出現的問題，而且不一定與您使用的語言數量有關。例如，我們看過一個單一的 Javascript 示範專案，其依賴關係樹大於一家公司整個部門所使用的已建立 Erlang 軟體。其他工具（例如依賴關係弱點掃描器）支援 Hex 套件也正變得越來越普遍。

如果你的公司有一個程序，每個依賴項都必須由安全團隊、法律部門（用於授權目的）和工程師（用於代碼品質）審核，你會發現實際上這並不太好。人們要么堅持使用預先批准的函式庫清單，要么只審核頂層依賴項。在某些情況下，他們永遠不會更新過時的函式庫，因為他們最好避免所有繁文縟節。在其他情況下，開發人員只會將依賴項寫入專案，以避免在他們覺得必須快速運送產品時，必須跨許多部門進行審查。這樣一來，你的代碼幾乎沒有經過任何審核，甚至可能品質不佳，因為他們可能已改寫已建立的函式庫。我們認為這是一個組織問題，而不是程式設計語言問題。

不受歡迎的語言或「難以聘用」的語言永遠都是一個問題。不幸的是，這是一個你無法真正解決的問題，因為沒有人知道未來。如果主程式語言突然不受歡迎，以致於整個堆疊都難以找到員工，會比只有堆疊的一半難以聘用嗎？對於像是 Python 之類的情況，從 2.x 遷移到 3.x 如此困難，函式庫和組件實質上都將它們視為不同的語言，你該怎麼辦？我們認為，沒有固執地採用單一種語言，而是習慣於在幾種語言之間切換的組織（而非採用很多語言），能夠訓練自己更好地適應程式語言市場的變化。

接著，我們會抱怨一個孤獨的開發人員不關心組織正在做什麼或知道什麼，而且開始採用沒人知道的語言運送產品。該開發人員可能是為了充實履歷而這麼做，然後在跳槽到新工作之後就把其他人丟下。即使你強制採用單一語言，也無法防止這種情況發生。見鬼，一個開發人員可以用你們公司的主要語言，但採用該語言或其函式庫之一所支援的新架構或新模式來做到同樣的事。單一不受支援的 Lambda 可能比在已知部署環境中的新語言更棘手。

我們大多將這種負面行為視為，讓這種工作完全孤立地進行是流程失敗，必須加以解決，而不是指責所使用的工具。

最後，有一個主要的論點需要反駁。人們普遍認為，使用多種語言會造成阻礙，而且如果使用一種語言和一種架構，在開發人員間移動會更容易。事實上，我們會將這稱之為反對多語言組織的最大迷思。

它之所以被誤導，是因為它假設開發人員就像機械零件一樣。只要介面相同，它們就可以互相替換。它忽略了所有與語言無關的事情。不同的團隊有不同的習慣和動力，你需要習慣。他們從事不同歷史和挑戰的專案，可能在不同的領域，具有不同的焦點，並在工程事物的方式上做出不同的妥協。除此之外，即使在單一語言中，也會產生遷移成本：不同的框架、函式庫、工具鏈或這些工具鏈的版本都需要進行一些調整。

我們認為，這些因素共同構成了一個挑戰，這個挑戰通常和學習一門新的程式語言同等重要（甚至更重要）。即使很重要，學習新語言的成本也比想像中低，主要原因是其中包含了所有這些基礎問題，而這些問題仍然可能存在於單一語言中。成本看起來很高 是因為 我們傳統上不提供任何有挑戰事物的支援，當切換生態系統或團隊時，必須從頭開始學習。

最小可行語言

根據前面提到的這些迷思和常見的抱怨，我們建議一種方法，直接解決這些基礎問題，而與所使用的程式語言無關。我們還提出了一個程式語言必須符合的最低標準，才能被採納。雖然起初可能會想建議將這些因素強制規定為硬性規則，但我們相信讓工程師參與它們的制定，將比其他替代方案提供更好的參與和自我約束。

在決定什麼代表 最小可行語言 (MVL) 時要記住的第一個觀點是，你會想要幫助你的組織成為一個學習型組織，在這裡你的開發人員互相訓練以持續適應。目標是引導學習，並提供一個技術成熟度層級的界線，以考量是否值得進行評估。

爲了做到這一點，我們建議使長期支援的成本顯而易見。只要你的開發人員可以為這種支援提供合理的進展路徑，就不會阻止使用那種語言。例如，要求回答以下問題

• 如何部署它？
• 如何提供它的可觀察性？有哪些指標、記錄和追蹤支援，以及如何將它們新增到專案中？
• 哪些建置工具將會讓人員使用，而開發人員又應如何設定他們的開發環境？
• 提供了哪些測試框架，以及如何將它們與你的整體測試標準進行調整？
• 如何為它撰寫文件？
• 我們將來會向誰問它相關的問題？我們有當地的專家和倡導者嗎？有幾個，如果我們低於特定門檻，我們要怎麼做？
• 如果您執行 RPC、訊息傳遞、資料序列化以及使用特定資料庫，應該選用哪些函式庫？是否有必要編寫這些函式庫？
• 在使用該程式語言時，您如何處理結構化編寫、撰寫以及除錯程式碼？是否有應該提供的基本指南或工具？
• 您如何聘用這些開發人員？您如何訓練那些不了解該程式語言的人員？
• 我們是否有任何基本的整合文件，可以幫助人們開始使用上述任何要素？

根據您的觀點，新增或移除問題。您可以將某些問題情境化，例如記憶體使用量、前端語言需求、行動開發、後端語言、桌上型軟體等等。提出一個您認為工程師必須提供的基線。在不考慮任何程式語言的情況下，以抽象方式回答這些問題。將這些項目分類為「必要」、「不錯」等等。您可能會想出類似下方的表格

建立一個基本標準，並找出必要項目，沒有這些項目就無法採用該程式語言，等等。將其轉換成一個相當客觀的評分卡，供您確認決策。否則，首席技術長或架構師將會大力推動他們所喜歡的技術，而不考慮實際支援。組織的預設反應往往是找到高層喜歡的東西，並努力推動，讓組織中的其他人來適應這些喜好。評分卡（可以簡單或複雜，由您決定）的目標是讓大家了解採用或變更技術的成本，以及作為清單，列出他們需要提供哪些內容以協助彼此使用。

依你想要採用的程式語言執行評分表，並檢視你是否確實能夠成功地採用，或者要如何做才能做好；依你已經採用的程式語言執行評分表，並檢視它們是否及格。如果不合格，請先修正差距。建立由工程師們的感覺所引導的知識庫，他們會覺得需要這個知識庫才能更有效率地執行工作。專門化並調整公司某些領域的要求，並檢視這會將你引領到何處。

即使是在一間強制使用單一語言的公司，你很可能會遺漏許多「有必要」或者以上的重點；當我們選擇讓社群來處理這種支援時，我們最後也會低估內部支援。遺留程式碼庫就是這樣產生的。你可能會發現不同的團隊在其特定專業領域中判斷事情的方式非常不同。總是會與基礎架構元件溝通的人員可能會提出與從事最終使用者功能的團隊非常不同的要求。你可以開始專門化評分表，或將與特定領域相關的元素納入其中。

一種生產語言

當你反覆檢視所有已確立的這些準則時，你應該記住一些最終目標。例如，你可能會想要以涵蓋下列事項為目標（請注意，這些事項有很多在本文中都有涵蓋，目的是讓更多 Erlang 使用者更容易了解）

• 如何安裝並設定你的開發環境，其中包含所有必要的版本
• 一個已經驗證且大多數專案都在使用的認可函式庫清單
• 啟動新專案的程序（設定測試、要使用的 linter、如何啟動 CI/CD、程式碼片段和範本等等）
• 你可以取得協助的位置（例如，內部電子郵件串列、聊天室或聯絡人員姓名）
• 學習資源庫，其中可以是書籍、教學課程、影片或你覺得有用的內部文件
• 安全性指引
• 讓服務或應用程式達到生產等級時要執行的待辦事項清單
• 如何對你的程式碼進行基準測試
• 如何對你的程式碼進行編製
• 架構和貢獻指引
• 常見問題的執行手冊和手冊
• 面試問題

不一定要在 wiki 中提供所有這些廣泛的教學課程；有些可以用成對的、午餐及學習、簡報等方式來達成。無論你選擇如何協助處理這些事項的新進人員，請注意你聘用的開發人員或轉調團隊的開發人員必須自己找出 所有這些，而且很多是在沒有明確支援的情況下找出的。這項無形的作業一直都在進行。目標是要讓它看得見。

在選擇支援多語言程式語言和定期推出團隊認為有助於工程師在不同專案之間切換（同時不會產生孤立技術）的功能時，相較僅備有一個不支援此功能的程式語言，您有可能讓團隊之間的切換變得更為容易。如果您真的希望將此類原則融入您的文化中，請展現您重視參與達成並改善標準實務，以及致力於將現有程式碼庫提升至所需卓越水準的團隊。要讓足夠多的人參與以逐步建構這些資源並讓它們持續運作，可能很棘手，因此最後一點非常重要。

簡而言之，我們應該致力於了解人們如何學習並協助他們學習，而不是假設他們已經知道所有知識。為領域知識準備入門指南。找出您目前並未提供充分服務、且您可能需要投資的領域。建立方法在社交層面使特定語言的知識和工具持續可用。並找出您原本不曉得哪些因素很重要，但後來發現這些因素對您的團隊執行工作至關緊要。