該如何解決這種情況？

什麼都沒有，您只呆了幾個月，這不是您的角色，而且您沒有權力

您的上級有很多資源，但是已經有7年沒有使用它們了，所以在這一點上，您只是在第二次猜測他們的原因，然後分析一位同事專注於自己的職責和任務。

僱用您所能找到的兩個或三個最聰明的開發人員。將所有代碼交給他們。讓他們驗證他們確實擁有所有代碼，以及運行該軟件所需的一切。讓他們學習代碼的功能，對其進行記錄，對其進行重構，直到他們到達可以比A先生更快解決問題的地步。所有這些顯然都不需要A的知識。

到那時，您確保您完全從公司所有資源中關閉A先生，將工作轉移給新的開發人員，並通知A先生他的工作已經完成。

我認為，用A先生的開發方法，他的代碼所做的工作量實際上比通常需要七年的開發時間要少得多，而且代碼被混淆了，但實際上並不困難，這使新手的工作容易得多。

PS。由於一些評論，我想再次強調一下：問題不僅是金錢，問題在於軟件的開發不夠完善，因為A專注於使其難以開發，而不是在改進軟件方面。軟件。

簡短回答：您的組織目前正處於公交因素的嚴重危險中。知識。這是巨大的風險。如果此人決定退出，或者被公共汽車撞倒，會發生什麼？如果情況恰如您所願，那麼整個公司都將消失。您需要將此問題標記為經理，這是組織風險，而不是人力資源問題。

開始讓其他人了解整個代碼，不管有沒有A先生。最好不要，因為您已經將他確定為

請記住，如果A先生不能幫助您減輕組織的風險，那麼他本人對組織是危險的，因此需要進行管理。釋放他的力量，這樣，如果他真的被公交車撞到了，那麼你們都不會無路可走。

其他答案非常好，但是我還要考慮另外一件事：

我的個人建議是考慮開始尋找其他工作場所...如果管理層沒有採取了7年的任何行動，我不確定這是您長期想要的工作場所。對我來說，這是對公司其他類型問題的警告標誌。

他反复做出了錯誤的決定，目的是使軟件產品不穩定，難以維護和排除故障

所以您的團隊為什麼要讓這些“錯誤的決定”越過設計審查還是代碼審查？如果您沒有代碼審查流程，甚至沒有設計審查流程，請長期倡導。

但是在那之前，您需要了解的所有信息都在Joel on Software博客文章中： 當你只是一個咕unt的時候就把事情做好

並且他有一個特別的標註來處理bozos：文件錯誤。按照Spolsky的說法：

作為咕gr，您的目標是將損害最小化，也就是遏制。在某個時候，這些天才之一將花費兩週的時間來編寫一些令人難以置信的糟糕到永遠無法工作的代碼。您很想花15分鐘的時間從頭開始正確地重寫內容。抵制誘惑。您有一個絕好的機會來消除這種白痴，持續了幾個月。只需根據他們的代碼報告錯誤即可。他們別無選擇，只能繼續努力幾個月，直到找不到更多錯誤為止。在那幾個月裡，他們無法在其他任何地方造成任何損害。

否則，作為團隊的新員工，您的目標應該是建立自己的卓越聲譽。 >

要比目前的答案說得更清楚...

您的問題：

沒人知道如何解決它。

您的解決方案：

• 了解如何自行修復。

有，現在公司不再需要其他人了。

將其張貼在牆上：（您必須更改一些名稱和位置）。

幾年前，我花了一周時間在在美國中西部的一家製造公司。在星期五的下午，一切都結束了。 DP經理已經安排了該課程，並用預算支付了這筆費用，他請我進入他的辦公室。 “你怎麼看？”他問。他要我告訴他我對他的工作和他的員工的印象。 “很好。”我說。 “那裡有一些好人。”程序設計課程是艱苦的工作；我很疲憊;員工評估諮詢會額外收費。無論如何，我知道他真的很想告訴我他自己的想法。

“你對弗雷德有什麼看法？”他問。我們都認為弗雷德很棒。” “他很聰明，”我說。 “他對方法不是很熱情，但是他對編程了解很多。” “是的，” DP經理說。他在椅子上轉過身來面對牆上那張巨大的流程圖：大約五張大號行式打印機紙，也許是200個符號，數百條連接線。 “弗雷德做到了。這是我們每週薪水總額的總和。除了弗雷德，其他人都聽不懂。”他的聲音沉靜地靜下來。 “弗雷德告訴我他不確定自己是否理解。”

“棒極了。”我恭敬地喃喃自語。我清楚地知道了照片。弗雷德（Fred）作為科學怪人（Frankenstein），弗雷德（Fred）是無法控制的怪物流程圖的傑出創造者。 “但是簡呢？”我說。 “我認為簡非常出色。她很快就掌握了程序設計思想。”

“是的，” DP經理說。簡（Jane）以很高的聲譽來到我們這裡。我們以為她會像弗雷德一樣出色。但是她還沒有真正證明自己。我們給了她一些我們認為很難解決的問題，但是當她說完這些問題時，這些問題一點也不難。大多數結果都非常簡單。她還沒有真正證明自己-如果您明白我的意思了？”

“我明白他的意思了。”

—從書中摘錄軟件要求&規範— Michel Jackson（值得一讀）。

答案很簡單：解僱他。您可能需要在短期內支付一筆不小的數目的金錢來修復他所造成的混亂，但是A先生並不比世界上任何人都聰明-別人會能夠在短期內維護軟件，並在長期內使其變得更好。

有一個需要考慮的觀點。

公司喜歡這種方式。如果他們沒有7年，那麼很長一段時間才能讓它持續下去。

作為開發人員，我們往往會忘記，編寫好的或精巧的代碼不是我們的工作。將產品變為現實是我們的工作。編寫好的代碼只會使過程變得更好，但是您可以使用完全廢話的代碼來製作一款很棒的產品。

公司支持他的決定，甚至僱用了他。他們“喜歡”他和他的做事方式。即使您設法以某種方式將他解僱，也不太可能更改此設置。他們可能會選一個新的人來當“傢伙”，然後整個過程重新開始。

經營公司不是您的工作。該公司已做出選擇。你需要做你的。向那個傢伙學習（他已經做過7年，必須做正確的事情）或繼續前進。

無論好壞，沒有或沒有人是不可替代的。 （有些可能比其他更多，但仍然有）如果人們知道解決方案，則可以開始對其進行逆向工程。

過去，我在您的鞋子上穿了兩次以上。在與您最相似的情況下，“ A先生”早已不復存在，但是，我有一個整體解決方案在電纜公司的後端工作，那裡我沒有本地開發庫的源代碼，如果沒有的話我當時是該行業的新秀。

我幾乎以一種模塊化的方法來攻擊它，看看現有的代碼，缺少它的逆向工程，並編寫具有更好功能和速度的模塊，這些模塊可以依次替換核心任務。在進入下一個模塊之前，我已經完善了每個模塊。幾個月後，我殺死了以前的應用程序。

不可替代的想法被誇大了。

處理遺留物也不是一件容易的事，也許您的同事是出於慣性或因為他不知道該怎麼做。

從業務的角度來看，基本上有兩種解決方案：

1. 以增量方式進行過渡，換句話說，只需使用一小部分功能，然後將其重新實現為高標準，然後將它在生產中，然後繼續逐步進行，直到舊系統完全停用為止。
2. 完全構建一個新系統，然後一次或逐步過渡到新系統，例如在上面開始新的客戶，然後逐漸將舊客戶轉移到它。新系統不必像最初那樣具有舊系統的功能。它的賣點可以是更低的價格，更快的支持等。
ol>

選擇1的優點在於，它不需要大量的前期投資，新代碼經過了實地測試逐漸而不是一次全部地花錢，並且您開始及早看到收益（因為企業花費更少的時間和金錢來維護舊系統中不再活動的部分）。

但是，缺點是新系統的結構可能會受到舊系統結構的強烈影響，在某些情況下，要替換非常混亂的系統的某些部分確實很困難。有時需要一些創造力-如果其他所有方法都失敗了，則新代碼可以模擬舊系統上的按鍵和按鈕點擊！但是與舊系統的接口可能會產生大量工作，因此最好只使用選項2。

無論哪種方式，都有 可以完成。問題是，它將花費多少，並且將節省多少？嘗試估算上述每個選項將有助於確定選擇哪個選項（如果有）。這將取決於功能要求，現有系統的結構以及企業是否願意花錢/預先使用信貸來節省未來。

作為軟件團隊的成員，您的工作不是管理公司及其員工。

您的工作是編寫優秀的軟件。因此，您可以擔心軟件而不是人員。

您看到了軟件的問題，從您的問題中看來，您似乎有解決問題的想法。將這些想法帶給您的經理並為之奮鬥。可以簡化測試的模式。”

現在，很可能是：

A。這是公司不願投資的一項大任務，因為他們沒有看到需要。

B。 A先生會反對這些東西，因為他年紀更大，所以會被傾聽。

如果發生這種情況，那麼您會盡力做好工作並被扼殺。是時候尋找新工作了。

如果工作順利，他們會聽你的話，那麼你就簽了很多工作。

您不能在這種情況背後隱含意圖。

故意遠離現代軟件開發框架

他可能最適應什麼他最了解嗎？

我在一些大公司工作，這些公司的流水線是古老的和全新的代碼的拼湊而成，並且某些代碼段“有效”並且從未被使用過。長期以來，沒有人真正了解他們的工作方式，因此他們只是添加了新功能來適應不斷變化的需求。他們的管道始終處於活動狀態，因此任何重大部署都可能帶來災難性的後果（即非常昂貴的工作和交貨中斷），因此他們迴避了

這是個壞習慣，會導致基礎設施未優化，但實際上卻有其優點。

您可以做些什麼，特別是如果您需要做很多工作或全部代碼：如果沒有適當的文檔，則建議創建一個（如果您知道自己是精打細算並有時間）或詢問是否應該採取某種措施來加快工作進度。

機會是，沒有上層人士會看到在這方面花費資源的好處，而您的嘗試可能看起來像是啊，新人認為可以改變世界，

不幸的是，公司結構會抵制突然的變化，而現代化則是逐步消除阻力或逐步實施阻力的問題，除非您能證明自己的“革命性變革將帶來

即使他惡意地這樣做是為了保住工作，我也不認為你有責任擺脫困境，尤其是當你的直接上司是知道了。

你會怎麼做？

看到您的經理決定不追究他可能不想與您或不與您同上司進行交談的事情時，是與您的經理交談還是與他的經理交談，或者不與他的高層管理人員交談，還是與有問題的同事交談？

如果您在沒有他的情況下與他的上司談話，您就有疏遠他的風險。

與同事交談最肯定會帶來非常糟糕的工作之後，他肯定會否認任何指控。

解決此問題的唯一方法是取消控制權先生。

首先獲得管理層批准。

製作全新的git。

1. 導入商品，並商定起點。

2. 從此處開始，然後將代碼提交。

3. 根本不給Mr. A訪問權限（甚至不告訴他它存在）

4. Port Mr A.更改為您自己的存儲庫，或重寫。

5. 讓A先生為他的回購交易做任何他想做的事，因為你不會使用它。

6. 製作偽造的代碼更改使它看起來好像有必要（如果有必要的話）向他隱藏您的新回購協議。 li> ol>

   您需要做出一個關鍵的決定，以保留或放棄模塊策略。模塊不一定是不好的模塊，您需要使它們保持同步並保持正常運行。

   這將是很多工作，因為您必須重新編寫許多現有代碼。

   另一個好處是，代碼最終將產生足夠大的差異，以致他將無法再聲明其代碼。對他來說完全陌生。

@MightyPizza-您正在浪費時間。去另一家擁有光明和美好未來的公司工作。僅當這家公司是您的最後一站時，您才應該花很多精力解決這個問題。

這是您絕對可以獲得的最佳答案。

“我要使軟件現代化，可維護和穩定。”

做到這一點的最佳方法是在第一天，第一行代碼，不能和別人的垃圾堆在一起。

請注意，作為非經理，這並不一定要解決您的問題（除了按照說明進行操作（作為解決方案的一部分已決定）之外）。

還，切勿盲目地將“我們希望問題XY解決”解釋為“ ...因為問題XY”。

也請注意，一旦您採取任何主動行動（即使獲得批准）來改變情況，您正在參與公司政治。在公司政治中，沒有“沒有個人議程的無辜創新者，我們不能為意料之外的後果負責”的事情。

如果這樣做，請 / em>個人議程，並以任一種方式承擔後果。

要讓他在該職位上停留很長時間，就表明企業正在有意識或無意識地使用 Hanlon的剃須刀：

從不將惡意歸因於惡意

聽起來很難找到實際的惡意案例，只是隨著時間的流逝，事情變得不太順利。實際上，看起來A先生已經讓人們嘗試更改某些東西，然後在出現問題時英勇地將其修復。

您還應該考慮A先生可能正在遭受 Dunning –克魯格效應，因為他看不到自己在做什麼，這是錯誤的。

可能是他曾經很好，但是停止學習並停止嘗試。誰知道。首先要考慮的是，無論他多么生氣，您都必須像對待他一樣不是惡意代理。

您的問題似乎是假設他只是為了工作安全，並拒絕更新內容以嵌入此內容。您可能是正確的，但您不能以此為基礎與他打交道。

我敢肯定，您的一些好主意是因為“我們嘗試過一次，由於X而無法正常工作”。從業務角度來看，這是有道理的，他們冒著無法解決的風險，所以為什麼要再次嘗試。

您說的是您的目標。

我想使軟件現代化，可維護和穩定。

讓我們分解一下這個問題根據業務需要

1。現代

現代沒有隱含的業務價值。無論如何，這都是有爭議的。您說Java 8，其他人則說Rust或Golag是現代的。只要支持系統，更新它就沒有很大的價值。

2。可維護

這也可能很難爭論。 A先生將堅持認為，這是可以維持的。您可能會爭辯說，維護成本將大幅度降低，以證明對框架進行全面更改是合理的。穩定

您說您想使系統成為HA，但您也說它

該軟件監視事件，對事件進行一些處理，然後然後採取適當的措施。

聽起來好像不需要HA。

那該怎麼辦？

您的系統聽起來像

大泥球 >

一個大泥漿球是一個隨意構造的，蔓延的，馬虎的，風管帶和捆紮線的意大利麵條代碼叢林。這些系統顯示出毫無節制的增長跡象，並且反復進行了適當的維修。

要解決這個問題，如果開發者不合作，則將非常沮喪，並且可能毫無結果。聽起來好像很多其他人都嘗試過並且失敗了。

您可以做的就是規避它：

• 如果您無法使系統HA，請使用消息總線系統或類似的方法，如果系統出現故障，您就可以通過這種方式捕獲消息，您不會丟失數據。
• 如果您不能編寫單元測試，請編寫系統測試。這些不那麼整潔，但是它們將允許在系統上進行測試
• 下一次需要執行某些操作時，它將開始將其構建到一個獨立的子系統中，該子系統可以偵聽消息總線並自行執行動作。
• 如果您可以開始影響某些下游影響（例如封裝所採取的動作），則將其置於子系統中。

有一些論點。在微服務上支持主觀整體，但是它假定整體是經過精心設計的。在您的情況下，該系統可以作為精心設計的整體使用，但是如果設計不當，則需要將其拆分。

這看起來像是一篇很好的文章，從以下內容開始：

更常見的方法是從整體開始，逐漸剝離邊緣的微服務。這種方法可以在微服務體系結構的核心部分保留大量的整體組件，但是隨著大多數新開發發生在微服務體系中，而整體組件則相對靜止。

與A先生一起，不要告訴他您正在更換系統，而是在“提高可靠性”或增加冗餘。如果您抨擊他所做的事情，他將使您更加難以實現目標。

您可能會覺得自己使系統變得更加複雜。的確如此，但如果要長期前進，這是必要的。

為什麼每個人都想解僱A先生？我認為他在這裡沒有做錯任何事情。軟件開發不是要使用很酷的工具或框架來製作新東西。這是使穩定的東西“起作用”。您的公司愛A先生，對他的工作感到滿意。

有意地遠離現代軟件開發框架

您的系統目前處於穩定狀態，那麼為什麼團隊甚至需要使用Scrum或敏捷之類的現代軟件開發框架？

用無法測試的語言編寫核心業務邏輯

是否要求必須自動測試核心業務邏輯？

將軟件組件重新架構為30個模塊，以增加複雜性和版本認證問題

此實現對您的公司造成了多少成本？

以不可擴展的方式對其進行設計，以確保沒有HA（高可用性）功能

仍然是同樣的問題-這種實施使您的公司付出了多少成本？

在我看來，您在此處寫下的所有內容只是對他的投訴。如果他做了很多“糟糕”的事情，系統本身在第一年就會崩潰，而他不可能在您的公司呆那麼久。

很簡單，企業必須向他提供豐厚的加薪，以記錄軟件的當前狀態以及所有未記錄的知識，然後解僱他。或者，他們僱用一家技術諮詢公司來記錄所有內容，他會在牆上看到這些文字，最後離開。