我建議您將問題提交給團隊討論。在下次團隊會議上提出您的問題，並詢問他們對此的看法。

由於它們聽起來像是有效的顧慮，我想您會從其他開發人員那裡獲得支持。

請確保討論保持專業性並保持開放的態度。關注使用X如何影響團隊的其他成員。這樣，開發人員將不太可能具有防禦性，當他意識到X的使用如何影響團隊的其他成員時，他將很難簡單地消除他們的擔憂。

如何處理X提出的項目風險？

為解決這個問題，我將使用您自己的話：

它正在快速發展/不穩定-在記錄一些舊代碼時，他發現一些基本功能已被刪除，無法在較新版本中進行編譯，因此花了幾天的時間重新實現它

AND

儘管有幾個月的接觸時間，其他開發人員顯然對X感到不舒服。當他不在時，我已經看到了部署損壞代碼的現場站點問題。是的，需要圍繞測試進行對話，但是他們無法發現X中的topstopper錯誤是一個危險信號

該語言顯然不是很成熟。在流沙上建立帝國並不是一個好計劃，我想您知道這一點。作為經理，您有責任管理風險並設置標準。

X本身是否真的是問題所在？

我認為問題可能在於您的組中沒有未設置任何標準。我建議您和您的團隊就將要使用的語言達成共識，然後繼續前進。

在生產中使用任何新技術之前，應先向團隊提出。。當提出一項新技術時，團隊將對該技術的有效性進行投票。這樣，X不會被一個壞人否決。

這對您來說確實很重要：開發人員離開時，您必須能夠支持代碼。如果您允許，那麼對您來說將變得更加困難。您可能還希望對這種語言的流行性和進行一些研究，以確保您可以在需要的時候僱用新的幫助。

我對此非常非常擔心。

如果他明天被公共汽車撞中，或決定明天離開，那麼您目前有：

• 在X上尋找專家替代他會浪費大量的時間和金錢；
• 一個不了解他編寫的任何代碼的團隊；
• 一個團隊甚至無法可靠地部署他編寫的任何代碼；
• 該代碼可能僅適用於特定的未知版本X，然後中斷將來的版本。

然後，您的上級會像一大堆磚頭一樣落在您身上，問為什麼首先要發生這種情況。 p>

您說他是一個好人-太熱情了，所以我會把這些問題交給他，以及整個團隊。詢問他們對解決方案的想法。強調這不是一種懲罰，也不是他們做錯了任何事情，只是所有人都需要解決的潛在問題。強調這不是語言驅動的問題，而是業務驅動的問題。如果您對以上幾點的理解不正確，請確保您可以公開批評；否則，您需要站在自己的立場上，以確保：

• 不編寫任何新代碼X；
• 最好是有一個較長期的計劃，將他用X編寫的現有代碼遷移到另一種語言。

這並不是說他不應該有助於選擇另一種，可以使用更合適的語言，但這並不是說他需要完全放棄X。也許您可以開設工作坊或演示文稿，在其中他演示X中的新模式/範例以及如何將其應用於（工作場所的相關語言。）也許他可以搜索另一種更為主流的語言，但具有X的更多特性。

但是，如果我是團隊的負責人，我當然不會同意在業務關鍵環境中使用這種語言。

沒有。

將寵物語言甚至是過多的語言引入項目後，從長遠來看將使其完全無法維護。當開發人員離開時，無論他們處於何種狀態，您都將最終以他們的寵物語言編寫代碼，並在其他組件中進行大量變通，以完成工作而不必更改沒人能理解的代碼。我是從發生這種情況的項目中總結經驗的。

絕對不是！整個公司之所以死亡，是因為他們選擇了錯誤的語言編寫代碼庫。如果該語言死亡，變得不受歡迎或導致棘手的可伸縮性問題，則代碼也將死亡。您可以負擔得起它的重寫費用嗎？

當您需要完全用另一種語言來重寫某個軟件時，您將是一個坐騎，因為您必須等到重寫方法功能才能發布新產品。與舊產品平價。 如果有可能避免重寫，則應該這樣做！。

案例研究：

• Twitter經常遭受“失敗的鯨魚”之苦，最終改寫了他們的Ruby on Rails服務器。
• WordPerfect被Microsoft Word壓垮了。儘管有很多商業原因導致它們崩潰，但部分問題是許多代碼都是用彙編語言編寫的，這使得移植到Windows變得很困難。發明了Tcl語言的人創立了 Ajuba Solutions，該公司的軟件主要用Tcl編寫。儘管Tcl在技術上並沒有真正的問題，但它並沒有那麼流行。他的公司有一些才華橫溢且敬業的Tcl開發人員，但很難聘用。最終，公司被收購了，代碼庫被放棄了，大多數開發人員在收購後對工作失去了興趣。

沒有一種編程語言可以勝任所有工作，而您確實希望開發人員以便為工作選擇合適的工具。就是說，在將語言引入公司代碼庫時必須有一些限制。需要考慮的一些標準：

• 您的團隊必須足夠精通該語言，以便可以進行代碼審查和多個維護者。
• 您必須能夠僱用願意在該語言及其生態系統中工作的程序員。 （而且您必須能夠容忍傾向於使用這些語言的開發人員。）
• 該語言應具有足夠的通用性，以使投資值得。
• 您應認識到並接受與該語言相關的風險（例如，頻繁出現不兼容的更改，頻繁出現的安全漏洞，標準庫的質量，可伸縮性） ，內存安全性，可讀性，錯誤處理策略，不直觀的行為等）。

有時，可能存在一些緩解因素，使人們選擇更加晦澀難懂的語言。例如，一種語言可能與Java虛擬機或Microsoft的公共語言運行時上的其他語言互操作。或者該語言（例如Swift）可能被設計為與另一種語言（Objective-C）互操作。互操作性至少為您提供了一個遷移路徑，不會使您在重寫期間陷入困境。

您可能會考慮為一次性代碼或原型代碼提供更大的靈活性。有時，原型製作的能力會迅速超過上述長期關注的問題。不過請注意，原型可能會發展成為永久性解決方案。

在您的特定情況下，您說您有一個基於微服務的網站，其中的一部分用另一種語言實現。即使您沒有將公司的未來押在語言 X 上，但不必要地混合使用實現語言也不利於構建具有凝聚力的體系結構。 （一個開發人員對項目的一部分擁有完全的自由支配的事實使您的公司缺乏建築設計的危險。）學習語言不是唯一的障礙；它還增加了用於開發，構建，靜態分析，測試和部署的工具的複雜性。然後，將來還需要修補更多的庫。您還提到，該語言有時會引入不兼容的更改，這表明它是實驗質量而不是生產質量的軟件。如果整個團隊僅出於一個開發人員的個人意願承擔這些費用，那麼每個人都會秘密或公開地怨恨該開發人員。

通常，編程語言的選擇（或就此而言，編程框架）必須是團隊決策，並且不應由任何一位孤獨的狼或搖滾明星開發人員來製定。聽起來您的團隊對 X 語言不滿意，並且團體情緒應該是要求特立獨行的開發人員停止使用它的一個很好的理由。

這是我認為經理應該放下腳步而不屈服的少數事情之一。從長遠來看，開發人員的工作會對公司造成傷害。 X是什麼也沒關係-重要的是，您的公司在X方面沒有很多專業知識，很難吸引到X方面的專業知識。

您的開發人員是錯誤的X是正確的解決方案。並非因為這是項目的錯誤語言，而是公司的錯誤語言。

告訴您的開發人員，他的行為不是高級開發人員的行為，甚至不對普通開發人員的期望。明確指出，他的行為不會在下一次績效評估中很好地反映出來，如果他繼續這樣做，是否會影響他晉升和獎金的機會。

告訴他，您希望開發人員能夠表現出對公司最有利的一面，並且您正在開發一種產品，這種產品有望長期開發和維護，而不僅僅是他。每個現在和將來的開發人員都應該能夠使用該產品，而無需首先學習其他語言。告訴他，您希望好的開發人員考慮明年，五年零十年後的情況。而今天做出的決定將影響未來。

換句話說，告訴他讓自己的驕傲落在門外，成為團隊合作者。

X 本身就是問題嗎？

否。

X 並不是問題……對於每個 X

值，這是一個管理問題。作為新經理，您遇到了一個艱難的人。

您的問題是，您

1. 有一個非常熱情的程序員，您想
   重定向成為生產力更高的員工。
2. 您懷疑如果您告訴他他不能使用 X ，您將不得不替換他，因為他會離開
   他是在向非技術人員介紹X。您是對的（對他來說，目前這是宗教）
ol>

解釋世界的運作方式：

作為新經理我喜歡讓人們使用他們熱衷的東西。您的情況是 X 。

問題是當事情中斷時我們的評分很差。 在整個團隊中反映不佳。
當您不在這裡時，幾次構建失敗。我正在嘗試學習 X ，以便我可以加入你們。雖然很有趣，但是我現在不能花足夠的時間。

我們如何保持 X 而不會使每個人看起來都不好？

因為沒有一套既定的最佳做法對於我們所做的事情，我們無法在X之類的新語言上進行標準化。這就是為什麼即使您是專家，我們也遇到了問題。

所以...我們該如何解決這個問題在短期內？
是否可以使用更穩定的版本？我們如何確保什麼都不會中斷並且沒有其他人必須停止他們正在做的事情來學習 X ？

更改“ 構建已損壞”來解決由 X 存在引起的最明顯的問題。

請給他時間來答复。如果他沒有太多回應，請讓他回到辦公桌前（在他去讓他專注於“如何”之前重複這個問題）。

正如其他人所說，這種情況不應繼續下去。確實的確，基本答案將是“不，抱歉，您不能使用X”的形式。而且，您完全可以這樣說。最糟糕的情況是該開發人員不高興並退出。那樣會很難過，但是他的想法太過激進了，您的答案應該仍然是“ No X”。

以及已經發現的問題，一個開發人員獨自使用了寵物語言

• 使得不可能進行有效的代碼審查
• 使得與其他開發人員的工作難以互操作
• 要求X和not-X使用的所有常用實用程序都需要代碼重複（

也許是一個更有幫助的回應，尤其是那些在X標準庫中未定義的東西。

• 減少團隊的凝聚力，尤其是在X和非X派系之間。
  • 問一問，特別希望X有什麼用呢？如果是正版，請調查是否可以以更標準的語言使用其中的某些優勢。 （您會驚訝於有許多新潮的功能加入了C ++和Java之類的舊語言的新版本中，或者至少獲得了第三方庫的支持）
  • 邀請相關開發者擔任領導（ （儘管並非沒有監督）），以開發可以從X中學到的有用經驗並將其轉移到Y最佳實踐中。
  • 整理一些數據以捍衛自己的觀點。例如。它可能有助於說出“我們已經花了_％的開發時間來解決X的不穩定性，而_％花費了_Y來更新對Y的更改”，或者“集成和調試X代碼降低了X的性能。整個團隊的_％。
  • 請考慮是否存在除了語言首選項之外的其他根本原因。例如，如果這揭示了孤立開發人員從事孤立功能的一般團隊文化，請對此進行一些處理。例如，引入結對編程可能有助於解決問題的根源而不是症狀。

  ---

  順便說一句，正確的答案可能是“是的”。 ，讓我們全部過渡到使用X。”這裡不是這種情況，這非常引人注目，因為X很小，晦澀難懂，不穩定並且不適合該問題。但是，例如，假設您是一家Android商店，並且有一個開發人員正在奮力從Java遷移到Kotlin，因為 Google 建議從Java遷移到Kotlin，並承諾今後會更好地支持Kotlin比Java。最終，他們說得很對。

  有許多相同的問題。您將需要擔心培訓，代碼兼容性，團隊成員的響應方式，甚至可能擔心其中一位開發人員如此不喜歡她決定退出的變更的風險。同時，許多相同的緩解措施將適用：授權投資人帶頭進行投資，整理有關為何做出決定的數據，聽取各種利益相關者的意見，等等。

我認為您是從錯誤的觀點著手解決問題。

您正在用我們的寵物語言與他的寵物語言問題。語言只是工具，相當通用。因此，選擇語言是一個附帶問題。

真正的問題是，您在團隊中完全完全混亂。看起來每個人都可以做他想做的事情，選擇任何工具，甚至包括那些他並不真正熟悉的工具。這是您需要解決的問題。

團隊中只有一個人能夠支持項目的任何相關部分，簡直太瘋狂了。團隊中至少應有2個人應掌握X的知識，以允許進行維護，否則X必須離開。

您的X-pet開發人員不確定如何實現X中的關鍵方面之一，這意味著，即使他也不了解它的合理範圍。現在要說聲對不起，但是您的公司正在僱用人員來完成這項工作，而不是讓他們樂於學習新工具。

一個可行的解決方案可能是允許他在多達20％的時間內開發實驗工具/功能。如果您想讓這個人留在您的團隊中，則完全禁止X可能會適得其反（而且您很有可能會這樣做，因為在生產性應用程序中將5人團隊變成4人團隊肯定不會幫助維護該應用程序）。

不，語言 X 本身並不是問題。您在這裡所描述的是一個更深層次問題的症狀，該問題也會影響您的團隊生產的所有其他系統：該團隊並不是真正地作為一個團隊工作，而是作為一群相互聯繫的個人。

您的本能是“希望[您的]團隊保持自主和快樂，建立團隊，而不是關閉團隊”是正確的；您需要通過指導團隊解決此問題來解決。我將從嘗試清除使用語言 X 編寫的代碼為“他的”代碼時發生的明確代碼所有權開始。這是團隊的代碼，整個團隊需要負責維護和擴展它。

您可能會首先分配故事（或任何對等的東西）。理想情況下，團隊的所有成員應定期處理系統的所有部分，而不是“屬於”特定開發人員的系統特定部分。如果您有一些開發人員是特定技術或系統部分方面的專家，而其他方面則不是，那麼這很好，但是在您的系統中應該沒有至少兩個開發人員認為他們足夠了解這一部分的知識，成為任何主要故事的特定故事的技術負責人。

配對編程和僅尋求幫助是傳播知識的典型解決方案。 極端編程通過允許任何人挑選故事並成為故事的線索來處理這一問題，無論他們對故事了解多少，都依賴於開發人員不允許對要求的內容說“不”幫助該故事，使開發人員在得到幫助時可以學習完成該故事所需的所有細節。 （XP中的故事分配實際上是一項項目管理功能：為該迭代管理一個故事的開發人員負責確保其完成，並找到完成該任務所需的所有資源。這通常會導致開發人員具有相當深的技術知識。

所以請向您的團隊解釋您對使用語言很滿意> X 或其他任何東西，如果整個團隊都同意這是個好主意，並且同意如果有問題的開發人員被外星人綁架，那麼在沒有他的情況下團隊可以繼續工作。然後由開發人員在團隊中出售他的技術想法。需要說明的是，即使團隊不同意將 X 用作所有新功能的主要開發語言，這也不意味著它根本無法使用。也許可以在某些較小的區域中使用它，以便對其進行測試並獲得經驗。鼓勵定期檢查語言 X 的使用方式以及特定子系統（無論是否使用語言 X ）有關其工作狀況，功能的信息。通常會出現各種問題，以及如何解決這些問題。

在其他答案的基礎上，我同意在使用項目之前，團隊應積極選擇項目中要使用的語言/技術（可能的可行性是試驗或測試用例，沒有希望或關鍵路徑）在項目本身中使用）。

我擔心這樣做還沒有完成，現在嘗試將這個話題提出來與團隊討論將導致沒有人願意麵對流氓程序員並說“不”（根據事實甚至經理目前都害怕採取此步驟）。

請考慮以下解決方案：召開“重置”會議，團隊將共同選擇/批准要在項目中使用和支持的技術。表現得好像該項目是新啟動的，迄今為止尚未選擇任何語言，而您是從空白開始。現在，舉證責任是要對新語言（應該是）使用“是”，而不是對“新”（目前似乎是這樣）。

對於上級和團隊來說， X處於當前狀態是一個問題，應該顯而易見，因為顯然目前尚無這種情況。告訴所有人，團隊至少需要兩名X專家，以防其中一位叫病假。要求整個團隊使用X進行培訓。每當項目由於X更新不兼容而中斷，或者由於測試人員不熟悉X而沒有發現一個小錯誤時，就開始討論如何防止將來發生此類事故。

公司將決定放棄X，或者他們決定全力以赴以使X被廣泛採用。無論哪種情況，X都是“寵物語言”的問題都會消失。

也不要責怪開發人員“將X帶給我們”。平易近人且熱情洋溢的開發人員是公司的資產和同事。在沒有評估風險的情況下，管理層認為採用X的想法並不是他們的錯。

我認為您需要與團隊就這種語言進行討論。讓開發人員首先介紹該語言，聽聽該語言可以提供的優勢以及該語言具有的劣勢。提出有關穩定性，兼容性等方面的問題。查看誰開發了該語言（例如，眾所周知，Microsoft會在宣布終止之前不久終止他們正在推廣的技術）（請參閱Windows Phone，Silverlight的多次迭代）等））鼓勵其他開發人員提供自己的想法。

如果討論反對X，而您真的不想完全關閉該開發人員，否則您甚至可以決定將該語言保留為一個單獨的項目，然後看該如何處理。項目完成後再進行第二輪（老實說，這是我無論如何都會做的（除非X是完整的垃圾箱）：讓一個小的項目用該語言完全完成，然後進行第二輪）

PS：有時，某些真正“奇怪”且不常見的語言可以在某些項目中發揮巨大的優勢： http://www.paulgraham.com/avg.html（文章已有20年的歷史了，因此您可以忽略技術和語言，但可以多考慮一個概念）

最重要的答案

我認為問題在於信心。

您的開發人員有信心使用 X ，並且害怕使用其他任何東西他不太擅長的語言。

可能對您的 Y 語言的能力進行了培訓，可能使他對使用 Y

請考慮您的開發人員（真正喜歡X的開發人員）是否處於自閉症譜系中，或者至少具有自閉症特徵。執著地專注於一件事，一直在談論它，可能表明這個人有某種狀況，這使他很難客觀地解決問題。

我的老闆付錢給我編寫銷售給客戶的軟件。他們不付我錢去做我喜歡做的事。例如，我喜歡玩視頻遊戲，但這並沒有帶來任何收入。

類似地，像X這樣的未建立語言似乎引起的問題比解決的問題還多。這意味著整個團隊的生產力和績效受到威脅，因為一個人想以不同的方式做事。

如果使用X可以證明對生產力和績效產生了淨的積極影響，留著它。否則，請向您的開發人員明確說明，他需要將業餘愛好（他對X的迷戀）與工作（支付工資的工作）分開。在我的部門中，基本上有兩個主要的軟件，它們是很久以前編寫的，尚未真正更新。貧血的對像模型，不良的編碼做法，老式的技術和框架...等等。

雖然我有經驗和知識來介紹新概念，例如域驅動設計，服務和單頁應用程序，我還需要考慮其他開發人員將需要時間來趕上。這是一個微妙的平衡，需要實現。

但是最後，您需要關注整個團隊的福祉，而不是單個成員的福祉。你不能使每個人都快樂。這是一家公司，而不是民主國家。傾聽人們的意見是當務之急，但做出決定並確保每個人都堅持下去同樣同樣重要。否則，不要成為團隊負責人。