如果不是原始編碼人員（如果他們記得他們做了什麼，為什麼這麼做）之外的任何人都無法維護的話，那不是“ Genius”編碼。

這裡的含義是這些天才已經進入了代碼-base，添加他們的更改，對它們進行單元測試，而不必考慮他們的天才是否干擾了另一個傢伙的天才並完全破壞了它。我猜（從gung-ho的角度來看），沒有更改的文檔或更新的功能文檔，因此現在沒人知道進行了哪些更改，由誰，出於什麼目的或由誰簽署了這些更改。

這是您要管理的那條線

這可能是天才，但無法維持。

您現在所能做的就是以某種方式使其在截止日期之前工作，然後分析其中的問題並使其可逐步維護。

如果確實如此不能在生產前投入使用，然後由您決定是否發布並說明原因。希望管理層能夠理解並推遲推出。

無視政治-這是您經理的職責。只要告訴他事實，讓他處理後果。

作為一般規則，管理“希望解決方案，而不是問題”。因此，說“代碼中存在硬編碼的機密”是一個問題，而“解決硬編碼的機密管理失敗：0.5天”是一個解決方案。

我要花幾個小時來正確評估代碼，並記錄所有要更改/修復的內容，以使其成為“最低限度的可行產品”。如果有任何客觀的靜態分析工具可以為您提供幫助，那麼更好-編碼氣候中的100個安全問題或比您的專業意見更難爭論的問題。但是，您的意見在這裡很重要，您正在嘗試進行誠實的評估。

“最小可行產品”（MVP）是一個有點主觀的術語。實際上，您的收入足以在Production中運行，並讓部分或所有建議的用戶進行了解。系統管理員可能每小時執行一次滾動重啟，並且可能在所有代碼中都進行了硬編碼的配置和機密信息，但是只要它不會向錯誤的人顯示您的銀行帳戶詳細信息，就可以使用了。稍後，您將修復所有錯誤和問題以及不良做法。

現在，您有了一個列表（待辦事項列表），您需要對其進行優先排序。估算很困難，但是請嘗試量化每個項目可能要完成的工作量。確保將所有這些都標記為估計值而不是承諾。

把所有這些都記錄下來-從問題和解決方案的一兩段摘要開始。然後是完整的“待辦事項”（帶紅線，下面是您投入生產後可以做的工作）。最後，附有靜態代碼分析或其他內容的附錄。

接下來，與您的老闆和任何其他真正相關的人（包括足夠的人，但沒有一個不是100％的人在這裡）預定一些時間。在會議邀請中將報告作為“預讀”。提出您的發現（摘要-談話時間不超過10-15分鐘），然後等待問題。盡可能多地參考您的報告。

最後，等待決定。管理層的回應方式非常重要。如果他們決定投資於您提出的解決方案，那麼您就很好。如果他們選擇不這樣做，因為他們打算用其他東西代替解決方案，那就可以了。如果他們試圖讓您以比建議的價格“便宜”或“更快”地做某事，那麼您應該仔細考慮自己的位置，因為他們要求的是不切實際的事情，並且不准備為他們提供合適的資源兩種-通常這表明一旦代碼在生產環境中，他們也不會突然決定投資。

從實際的角度來看：

您的管理層對代碼一無所知。這是做事情的魔術盒。他們被答應了這件事，他們可能看到了關於這件事的介紹。事情是真實的。他們想要它。他們為此付出了代價，現在它必須工作。

我遇到過您必須圍繞“管理”工作，而不是將它們納入項目或決策中。他們不了解您的問題，需求或良好實踐。
通常情況下，只要事情有效，他們都不在乎。只要表面上看起來像東西，整個東西都可以重寫。

我建議您將其視為一個新項目。

• 分析事物的目的是什麼。
• 看看是否可以用乾淨的代碼創建事物。
• 僅使用不良代碼作為參考，以收集有關該問題的討論以及它在理論上應如何起作用。
• 保存可用的代碼，將其重構為實用的代碼。
• 在兩個月內對代碼進行乾淨的編碼。
• 對管理層說完了，事情就解決了。
• 在否情況下，您會“廢棄”舊代碼。只是說您重構了它以使其符合規格。

管理部門看了黑匣子，然後說呼拉。

如果您說代碼是垃圾，那麼您的管理層有兩種選擇：信任您，或開除您。不信任您並使您繼續參與項目不是一個合理的選擇。

如果您因為太聰明而無法理解代碼（我見過我不想理解的代碼，但是沒有我無法理解的代碼），那麼該代碼就需要刪除。

該抽空您的技術寫作技能了。創建一個報告。簡要說明一下，您將無法在2個月內使該產品可行。然後在您的報告中提出一個或多個解決方案，並估計時間以及這些方法的利弊。例如：

'選項1：完全重寫。我最初的估計是，這將花費11個月的時間，但這將使我們擁有一個健壯，功能強大且可維護的代碼庫。” （順便說一句，祝您好運，因為獲得批准，世界上每個開發人員都希望進行新的重寫）

'選項2：將更多的開發人員投入到這個問題上。我們將需要X個開發人員才能在2個月內將其發布。這將花費更多，並且我們將在其他項目上浪費開發時間，但我們（可能）將其發佈出去。”。

“選項3，我盡最大的努力，並嘗試獲得盡可能多地做。我不相信我可以完成整個產品，但是這是我相信我可以做到的MVP示例。

依次類推。

然後，作為附錄，簡要描述一下（在外行的術語）您向我們描述的問題，並考慮提供參考，以便您的論點有一定的信譽。

該想法是立即提出解決方案，以便您的經理可以優先考慮此產品。他們可以等待更長的時間嗎？還是他們需要投入更多的資源。要合理且專業。

根據以下註釋，編輯後的重點更多地放在提供解決方案而不是批評代碼上。

您必須降低神奇魔咒的聲望。

您不能告訴他們這很糟糕，因為那樣的話他們會感到愚蠢，他們會決定您是愚蠢的，這樣他們就可以回到聰明的狀態。

如果您已經將其編譯，則可以跳過。這是一個機會，可以解決神奇的問題，但是現在您已經解決了它，您不想抱怨它。

我將從硬編碼的，加密的密碼。將他們帶到管理層，並指出這有可能引起很多問題。修改密碼，然後繼續。

未調用的函數和亂碼API可能會等待。如果他們實際上什麼也沒做，那麼他們可能也破壞。我將轉到IP地址或庫。

當您發現神奇的問題時，請務必告知管理層，然後告訴他們如何解決。隨著時間的流逝，您將成為他們的魔咒，這將是一件很棒的事。

將您所看到的問題整理成與其實際業務影響相關的結構化形式，將為您提供很多幫助：

仔細思考可以找到的問題和證據，並以此方式進行分組：

1. 觀察結果表明，如果將其投放市場，它將無法使用並產生強烈反響。無法編譯。代碼中存在邏輯錯誤。輸入未驗證。數據不會以確保不損壞的可能性很高的方式進行處理。安全方面沒有適當的位置，數據可能會被洩露/黑客入侵。不能保證鍵功能有充分的理由可以正常工作，或者您可以顯示已從所有鍵功能中檢出的幾個，但實際上並不能按預期運行。這類事情。
2. 觀察表明，可能存在一些問題不會在測試中顯示出來，但是如果投放市場，則存在很大的問題風險。像上面一樣，但是＃1是您發現的東西，這表明有重大的未發現問題是可以預期/預期/考慮到的重大風險。例如，如果您在某些數據驗證案例中已經解決了與錯誤處理相關的邊緣情況，那麼這表明可能存在其他案例並且尚不為人所知，這可能導致數據丟失/損壞。如果他們對一個問題使用已知的已棄用/可疑方法，則表明他們在其他問題上也做同樣的事情。如果數據庫在一個區域內受到競爭條件/非原子更新的約束，則表明這通常可能是代碼中的問題。而且，如果是多用戶，但服務器端處理不允許多用戶的輸入/過程以微妙的方式發生衝突，則表明它可能會在適當的負載下崩潰。
3. 觀察結果表明原始機組人員欺騙了管理層（故意或不可行，或者只是由於沒有用力而太容易被忽視/忽視：這可能是管理層的錯而不是他們的錯！）。現在，以前的工作人員是管理層的天賜禮物，因為他們已經交付了閃亮的產品。您對他們表示懷疑，因為即使產品很棒，您還是不滿意，無法使它工作，不了解它，等等。但是，如果您的觀察結果直接與他們所說的相矛盾，那麼您將成為誰知道發生了什麼，鞋子就對著他們了。這樣您的工作就變得容易了。例如，如果他們告訴管理層該項目具有適當的webUI安全性，並且您觀察到他們未驗證輸入/跨腳本/ SQL注入的地方，或者管理層認為該項目可以處理一些重要的事情，那麼您可以具體說明它可以永遠不可能做的，您可以向管理層表明他們被欺騙了。
4. 觀察表明，如果投入市場，通常的跟踪/期望/服務水平將不切實際/不可行，或者成本將大大超出預期。例如，如果代碼太差或缺少調試方面，那麼當客戶端遇到問題時，將沒有實際的方法來進行錯誤跟踪，而無論問題出在哪裡，補救都可能需要數周而不是數小時的時間。如果重複執行代碼，則意味著更改驗證或增強數據結構無法“僅在一個地方”完成。如果沒有文件證明或結構不完善，則對其進行增強或改進的嘗試將受到嚴重阻礙，因為沒有切實可行的方法來進行重大開發，並確保不會發生破裂，否則檢查破裂會花費很多時間以至於不經濟。如果情況很糟，那麼一旦出現問題，每次出現問題時，他們都會親自依靠您；因為您不能保證僅由於某個客戶的截止日期被錯誤擊中而不能保證在周末和晚上11點到那裡，否則您可能會坐公共汽車，他們將怎​​麼辦？如果可以推送數據但需要過多的手動注意，那麼在生產中，您的支持可能無法擴展以提供這種數據，或者無法保證數據可以保持足夠簡單，因此處理錯誤的風險可能更高。如果依賴於特定平台，並且代碼中沒有明確管理那些平台，則在通常或商業時間範圍內更改平台（Windows更新，瀏覽器版本，庫版本）可能不可行，或者修復可能中斷的情況可能很複雜，使客戶無法按預期維護或使用其平台。
5. 令人討厭的觀察。那是你的工作。如果它們不屬於上述類別，請在業餘時間盡可能地解決它們。管理層的問題是上面的前4個問題，不是這個。
ol>

這些將幫助您使技術和“動手”角度與他們的業務角度保持一致。如果您可以證明上面的前4個類別中存在問題，並且將它們明確列出，那麼您將可以很好地解決自己的問題-向他們顯示原因的根本原因，而不是您沒有問題

如果您將這樣的列表放在一起，看起來很吸引人，請進行演示，向他們展示，然後逐步解決示例問題-包括可以說明問題的特定代碼或數據流摘要。

您的演示文稿

要使其生效，

• 找到他們信任的其他編碼人員-或請求允許其邀請一天的同事-並準備好支持您的人。這樣一來，您的發言並不是全部。您還有其他人可以說：“是的，他給我看了這段代碼，對不起，他沒有誇大其詞。”
• 期望有一點教育-簡要。他們不是編碼員，但是有常識。 “這就是為什麼我們使用結構化代碼的原因，正是這樣，我們只能執行一次任務，隔離各部分，並確保各部分之間如何交互。但是這些人卻沒有，請在此處，此處和此處。因此出現的問題是，在他們的代碼中，您看不到如何相互作用，或者存在邏輯錯誤或不一致，並且您不能確保獨立的部分確實是獨立的，或者如果需要更改某些東西甚至在現實世界的負載下會表現出所有其他需要更改的地方，就像我們在測試中所做的那樣。假設我們可以實際測試並在不到10年的10個團隊的全職工作中進行修復，這是可疑的。這正是專業人員仔細編碼的原因-因為我們知道否則，業務影響將是嚴重的。”
• 期望受到壓力或強迫，說它還不錯。 說白了。 “很抱歉，無論他們告訴過您什麼，顯然您認為情況並非如此。我感謝那是令人震驚的事情，但作為專業人士，事實也是如此。”告訴他們：“不，這不是高質量的工作，這是犯罪性的草率工作，一直以來都是您被騙的。” （是的，您可以說是為了強調，它不像您在說他們是罪犯！！）說“是的，對不起，但是我確定”。
• 詳細介紹。如果您只是說“ Ssh鍵是純文本格式”，那麼這對您所在級別的人來說非常有用，並且可以像您一樣看到它。對於承受壓力並相信其出色之處以及為何大驚小怪的管理人員，它過於具體。取而代之的是：“用於防止遠程用戶使用客戶端配置面板的加密密鑰被不安全地存儲，以至於有些人不知道該怎麼做，就會說是在犯罪性上草率行事。不像你說他們是罪犯！）。如果你在這裡 看（好吧，他們不能遵循代碼，反而會拉出代碼並指向那一點） ，為了獲得信譽），您會看到密鑰以開放格式存儲。他們甚至都沒有進行1990年代的基本加密。將其置於網上，一旦有人認為它值得10英鎊，客戶端/用戶數據就會被黑客入侵。幾分鐘。”向他們顯示“在此處，此處和此處”中，您會看到一個例行系統調用[API]，該調用在各種情況下可能會中斷，也可能不會中斷，因為為該呼叫提供了錯誤的數據。”告訴他們“這些是基本的基本錯誤。到處都是這樣。”向他們顯示“在 this 模塊中，他們使用 this 庫，但在此處中，他們使用 that 庫。但是製造商明確指出這兩個庫實際上並不兼容，它們應該永遠不要使用在同一代碼中使用，因為它們可能會使數據不正確/可能損壞數據/因為其中一個的輸出將是如果交給對方，則處理錯誤/損壞/處理不當。”這樣，他們可以理解它並了解它的重要性。告訴他們“我可以解決它嗎？好吧，換句話說，如果這是如此可怕，您認為在不到6個月的時間內為該項目重做整個安全基礎架構有多現實？”這種方法。讓他們看到它。
• 採用預先考慮的解決方案。你會在他們的鞋子裡做什麼？實際上，請使用3種解決方案，並對這些方案的優缺點進行粗略估計。 永遠不要忘記“不執行任何操作”或“無論如何都要前進” ，也將其（及其優缺點/風險）也包括在您的列表中。
• 給他們時間感到震驚，沮喪，否認和責備模式。這是人類，他們也有壓力。期望發生這種情況，要么坐下來，接受他們的震驚，引導他們過去，然後輕輕地提醒他們指責搜查和屍檢可以等待；他們實際上並不能解決公司的問題。成為他們的顧問。
• 如果需要，過一會兒再說一遍，“我有一些建議的解決方案。沒有一個是理想的-理想的情況是這種混亂不存在。但是它們是可行的。會議。我們要花10分鐘/短暫的咖啡休息後我們可以再見面/午餐後/我要開會之後，讓我們見面，集中精力解決問題，並採取措施解決此問題。” 在一次精神上的“改變景象”之後（甚至只是喝咖啡休息的另一端）參加一次單獨的會議，將大有幫助。
• 說您有解決方案通常會稍等片刻，直到第一次爆炸發生，因為在早期階段，人類的反應通常是無視或拒絕需求。只有他們消除了一些不安（如果是那種類型的話）才值得一提，因為在這麼多的人中，如果有人說他們仍然處在憤怒的尷尬怪狀模式下，他們就不會聽到。如果那不是問題，那麼在解釋了影響的嚴重性/風險後，如果您認為他們在聽，那就直接解決。

請謹慎避免任何可能暗示您正在成為完美主義者或正在做的事情。任何超出市場生存能力的最小值。在這一點上，除了基本要點外，什麼都不是優先事項。

預先考慮的解決方案和建議

對於預想的解決方案，我的將是額外的資源。如果他們不相信您，那麼這一切都已經死了（假設您是對的）。該軟件將被淘汰，您將被聯繫所困擾：從現在開始尋找新工作。但是，如果在您介紹之後，他們確實相信您，他們感到擔心，或者他們正在尋求您進行修復，那麼這對您有利。

因為您需要一個團隊。像這樣說：

“抱歉，但是1.5 G這樣的代碼，如果沒有基礎知識或文檔，則需要一年左右的時間才能理解，也許需要5年才能解決。也許會重寫是必需的，我們可以保存可重用的內容，也許只是GUI的一部分，基本數據流概念，而不必重新發明輪子，然後重做後端和其他所有內容。”

”我認為評估是第一要務。我可以看到它很糟糕，但是有多糟糕，確保生產安全的最低要求是什麼？” [反映出他們的最高關注度]

”“據我所知，我們需要知道在4至6週內-我會說3週，但這是一個主要問題任務本身需要進行，並且需要逐行審查。以3人為一組，在4至6週內，我們將知道損失有多嚴重。” [如果不能，或者太大，請替換任何明智的方法。

“然後，我們需要修復它。我可以燒蠟燭，弄清楚該怎麼辦，但我需要動手操作鍵盤。從4到6的任何東西，最長不能超過6個月。”

[如果相關，請添加：“而且我需要勝任的第二名。如果我也要瀏覽問題和解決方法，我將無法一手審查他們投入的所有內容。 ” ]

“那是很痛苦的事情，但這是事實，我們需要先挖坑，然後再責備和提起訴訟。為此，現在給我兩個人，並為我預算在大約4 -6個星期內再獲得2或4個，我會為您完成的，或者至少是最少可行的。” [同樣，如果不能，或者太大，則用任何明智的方法代替]

”“您可能還想問[他們知道的聯繫人姓名，誰是在某個合適的IT業務中擔任主管]，派人去看一天，在提交預算之前仔細檢查我的最初觀點，方法和時間安排，這將是很好並且令人放心的。會-然後我們需要快速行動，唯一可以節省上市時間的事情就是快速而大量地投入資源。“

”在我看來，這將是明智的解決方案我們不能按原樣使用它，而且由於延遲和損壞，我們所損失的比通過為承包商支付費用或撤離其他工作人員所節省的更多。“

”很抱歉給您帶來壞消息。好消息是，我們可以挖洞了。“

”問題？“

我將嘗試做的事情：

親自與經理（您的老闆，項目負責人，負責此代碼的人）開會。用漂亮但清晰的話告訴他/她該代碼不起作用，並且解決該問題將不需要幾週的時間。如果他/她不相信您，則建議將其展示給其他開發人員，以獲得第二意見。

您的想法與管理層的想法無關。他們有要交付的產品，而您有一堆繼承的代碼已經嘗試成為該產品。

在當前狀態下，它要么可以作為該產品正常運行，要么不能正常運行。如果沒有，那麼剩下的就是製定計劃來利用資產（您的時間和技能以及您繼承的代碼的任何有用組件）來生產該產品。這樣做並不能說明您繼承的代碼的不足之處，重要的是，您要製定一個計劃以將其轉化為預期的產品。

您的管理層希望這樣做在給定的時間範圍內發生。您可以管理自己的時間來實現該目標，或者不能。如果不能，則需要更多資源，並且需要讓他們知道。如果沒有更多資源可用，那麼必須犧牲最後期限。真的就是這麼簡單。他們從您那裡想要的是一個計劃-您需要弄清楚如何 。不能完全解釋為什麼不能做到這一點是沒有建設性的。就是這樣-您必須處理並向前邁進。

我將在這裡做兩件事：

1. 說明情況。這裡有一些危險信號，因此請不要說任何話來引導任何人或向他們保證事情會按時準備就緒，這一點至關重要。請記住，代碼庫的問題/狀況是以前工作過的人的結果，但是一旦您開始承擔責任，就由您來承擔。不要讓自己成為替罪羊。

2. 根據聲明的業務需求評估產品在當前狀態下的性能。您犯的錯誤是您過於關注代碼質量，這是主觀的（您現在無法承受這場戰鬥）。更高的人真的不會在乎這一點，他們會在乎它是否起作用。客觀地做到這一點。如果他們被告知某事有用，但那沒有用，則您需要能夠記錄和演示。從這裡您可以開始估計您實際需要多少時間，並以事實/實際工作項目作為備份。

ol>

總而言之：誠實，客觀，不要不要超出承諾，而是根據業務需求而不是代碼質量進行評估。您還希望被視為問題解決者，而不是問題創造者，因此請確保專注於解決方案和前進之路。

很抱歉成為憤世嫉俗的新聞的承載者，但是...

如果真是個天才，那麼除非他們認為這是天才，否則就不會在發布日期前2個月移交給您。您比以前的開發人員擁有更多或更多的天才。

這聽起來像是失敗的設置。管理層知道這是一團糟，但需要將責任推卸給一些毫無戒心的勤奮工作，以便一旦高層管理人員開始要求狀態更新，他們就可以將責任推卸到生產線上而不是自己身上。

作為一種替代方法，您可以建議另一位開發人員對此進行研究。 2、3或15個人說這行不通並且不會很快使管理層信服。

僅在有其他人不關心該項目且因此不必掩蓋事實的情況下有效。

如果您已按照我們的要求向管理人員介紹了此代碼的狀態，而他們仍然相信代碼處於完美的工作狀態，則只需兩個月即可交付...

無法改變主意-他們已經對此深信不疑。或更糟糕的是，他們意識到了問題並試圖發揮無知的作用，以便在失敗時將責任推卸給您。

這時您可以做的所有事情，如果您想繼續致力於該項目，那麼您可以做的就是放下腳步，盡一切力量使此代碼正常工作，甚至包括繼續工作隨著時間的推移。

最重要的是，我強烈建議您在代碼內和代碼外都通過文檔進行練習，以便將應用程序的失敗歸咎於您時，您可以至少表明您已經超越了責任召喚，盡了最大可能進行救助。

希望，管理層中的某個人將足夠聰明，可以認出一個努力工作的編碼人員，他們願意為修復其災難項目付出努力。

話雖如此-這個項目聽起來管理起來非常糟糕。我建議您花一些時間整理簡歷，或者尋找公司內部轉移到新項目的方法。因為從您所說的內容來看，事情不是看起來很不錯。

首先，不要以為代碼太糟糕了。

幾乎每次我看到一個新開發人員來一個項目時，無論如何，他們都會認為代碼不好。是好是壞，或者是誰寫的。我從事產品開發工作兩年後，他們僱用了一個新承包商，他告訴我的老闆，我的代碼是毫無價值的“意大利麵條”代碼，需要重寫。大約兩個月後，他因生產力不足而被解僱。

通常，您應該抵制重寫所有內容的衝動。

嘗試將更改限制在必要範圍之內。您不是要在此處創建“蒙娜麗莎”；開始做最少的事情來完成需要做的任何事情。如果您認為那意味著要重寫整個項目，那可能是問題所在，而不是代碼。

絕對沒有理由對老闆的代碼質量發表評論。您是在這裡添加功能，而不是成為電影評論家。保持自己的意見，直到您證明自己的價值為止。

我覺得我必須特別添加一個答案，因為您已經接受了。這不是完全錯誤，但是，IMO有點漏了點。

暫時忘了代碼。它不是您必須維護的第一個或最後一個p-o-s代碼。如建議的那樣，仔細研究它，直到您看起來可以正常工作的代碼庫為止，嘗試匹配截止日期，等等。

需要充分準備和照顧的部分是您自己的情況：正步入人生的關鍵階段，如果不專心的話，自己可能會去找狗。現在的樣子，根據您對自己情況的描述，你們所有人中的每個人都相信一切都很好，他們擁有一座金礦，而且確實沒有問題。

這幾句話您給出的似乎已經暗示他們不相信您，並且認為，對您並不完全不利，但至少是中立的。您似乎沒有與他們站在一起。代碼有多糟糕都沒有關係。如果到了最後期限仍無法解決問題，則 將是您的錯，僅是您的錯。您可以根據需要記錄盡可能多的文檔，但是您提供的引號似乎很清楚，因為它們對參數不感興趣，也不完全相信您。

問題不一定是它們是邪惡的或出去得到你。一個普遍的問題是，某個級別的人與另一個級別的人的想法大相徑庭。毫無疑問，但這是常有的事情。看到;他們經常聽到技術人員抱怨某些任務有多困難或某些應用程序有多壞，就像對他們來說是背景噪音。他們不想听。在他們心目中這不是一個有效的論點。而且他們是正確的-知道技術細節不是他們的工作（並且代碼質量是技術細節的一部分...）。他們需要知道的是您缺少什麼 來實現該目標。

因此，在最佳情況下，您將有足夠的影響力告訴他們“我需要3個人和XYZ專家才能完成此截止日期”。他們提供了您所要求的，您按時完成的任務，一切都很好。

不幸的是，我看不到您的帖子中有您的影響力。他們似乎預定您和您一個人來解決問題。當您錯過最後期限時（尤其是當您開始責怪守則時），那麼，取決於您的住所，這對您來說是新工作，或者至少您在該公司的職業可能已經結束。

所以：請一位經理擔任您的一職，也許是一支仍然紮根於技術方面的團隊負責人。在公司中尋找一位可以為您代言/與您交談的教練，並幫助您安排更多的工作人員。但更重要的是：為自己處於極端壓力的階段做準備，不是因為您必須加班，而是因為您可能會遇到一些討論，這些討論對您來說似乎非常不公平/有害，並且極具挑戰性和壓抑感。注意是否有倦怠，沮喪或其他壓力綜合症的徵兆（例如：不再有從事運動的精力；無法與家人正常交談等），並在遭受傷害之前拔掉電話。

好運！

（來源：BTDT）

這種情況是以下已發生的典型情況：

在A點的某個時間，雖然沒有正式記錄，但存在一組流程的業務規則並且已知該規則（或者後來錯誤地銷毀了文檔） ，請參閱D點。）

在B點的時間，這些業務規則將被實現為代碼，並與已知規則一起工作。代碼的存在是一種動機，它可以不記錄業務規則，而將其遺忘和/或停止關心它們未被遺忘。

在C點，代碼正在使用中，而且由於它可以工作，因此大多數時候不需要知道其背後的業務規則。該代碼現在是事實上的業務規則集。

在D點的時間點上，有一定數量的掌握A點知識的人離開了公司，或者忘記了業務規則，或者丟棄了現有文檔已過時。沒有人注意。

在E點，該代碼開始顯示由於環境變化而引起的缺陷，或者需要進行功能更改。解決這些需求而不是滿足這些需求，因為儘管可以在技術上完成任何代碼擴展或修正，但沒有簡便的方法對其進行測試，因為業務規則規定了哪些內容應視為有效輸入，哪些內容應視為有效輸出，完全或部分未知。

使這種情況惡化的是關於文檔的永恆謎題：保持陳舊，過時的文檔很重要-同時，不知道稍後是否您所擁有的文檔比已存在的文檔更加過時，因為沒人知道是否可能存在一個更新的版本，放錯了位置或被銷毀了。

請問您為什麼要在這里工作？您的項目是一個爛攤子，本身就是一個爛攤子，但有些人喜歡挑戰清理類似的東西。真正的問題是，顯然，一群程序員已經被允許在一個產品上工作幾個月（1.5gb的代碼，不管是不是壞的，不是幾個星期的工作），他們顯然也都離開了這個項目，並且到目前為止，管理人員已從項目中撤出，他們甚至不知道項目的當前狀態。
對我來說，這些都是巨大的危險信號。如果前一個小組無法做到，管理層將如何管理您並讓您有效地完成工作？為什麼以前的所有程序員都不見了？當他們顯然對代碼質量一無所知時，您將如何在這家公司成長和學習？但是也許最重要的問題是，出現問題時誰將成為您的首選？
就目前而言，您無法確定自己不會被拋棄下次利益相關者要求演示時，巴士。這是一個有害的環境，以前的程序員很可能因此而離開，現在管理層正在設法聲稱它是“精巧的代碼”和“已經投入生產”來掩蓋這一點，這一切都會分散您的注意力那是您繼承的項目。

您的高級計劃應如下：

1. 建築師的前進之路。 （*）
2. 估計實現您的“前進方向”將花費多長時間。
3. 與業務涉眾會面並傳達以下信息：
   1. 您無法編譯/運行當前代碼（如果仍然存在）。
   2. 將需要'X'天/週才能將代碼庫恢復為可編譯/可構建/可運行狀態。
   3. 除了使該代碼可編譯之外，還有其他工作，您必須做一些工作才能使代碼可支持和可擴展。
   4. 這將花費您X個月的時間實施前進的道路。然後解釋前進的方向。（**）
   ol>
ol>

-

（**）這是最重要的，因為您將需要勸說非技術性業務利益相關者您的計劃是可靠，可行且有價值的。

-

（*）這是我對前進道路的建議，可以開始

1. 創建自動化的單元測試。
   1. 單元測試將證明您理解代碼。
   2. 代碼覆蓋率統計信息將不斷提醒您您了解代碼庫的哪些部分以及仍然需要探究的部分。
   ol>
2. 不要讓任何人合併到主數據庫中分支，而沒有經過至少兩個人批准的請求請求。
   1. 請求請求將使您的團隊對代碼庫的不斷發展的理解成為可能。
   ol>
3. 在您的開發人員中，尤其是在當前困難時期，鼓勵一種支持性的文化。
   1. 盡量不要失去冷靜。其他開發人員會感覺到您的挫敗感，並可能對自己感到沮喪。
   2. 當開發人員在處理一些棘手的舊代碼時遇到困難時，鼓勵其他開發人員伸出援助之手，並一起解決困難的代碼，也許可以配對使用-編程。
   ol>
ol>

在此處輸入一些信息：

您對代碼的擔心充其量是半有效的：

具有相同的功能，相同作用域的相同變量名整個代碼庫中（使用不支持該語言的語言）。

如果該語言不支持它，那麼它的版本又如何呢？好像是您在這裡丟失了一些東西。

已定義但從未調用過函數。

這會產生什麼影響？也許因為從未實施過的東西而被淘汰了嗎？

亂序變量的使用和初始化。

這在maint下的代碼中很常見，但在您的情況下並不理想，這在舊代碼中也很常見。

使用的庫版本不兼容。

請參閱＃1，它是怎麼出現的？

硬編碼的URI和IP地址，沒有有關其用途的文檔。

不理想，但是再次對交付有什麼影響？

隨機請求的API路由，不返回任何內容或亂碼；

再次參見＃2

硬編碼，未加密的密碼和私密ssh密鑰。

再次查看＃5

現在，在解決了這些問題後，雖然很不方便，但是瑣碎，我很想知道您是否設置了任何方向，對不起，這就是行業發展的方向。我所看到的。

不過，我確實有一些建議：您需要一種不同的編碼環境，例如...一個代碼商店，因此請尋找一家電子或高科技公司，其中的編碼標準是比說金融或製造業更接近企業的生命線。

就將您的疑慮帶入管理方面而言……我喜歡Tschallacka的回答。只需解決它的問題，而無需告訴管理層，並把它當作職業經歷，然後您就可以在簡歷中列出項目。我想我知道您正在談論的管理方式（不包括個人意見），並且他們可以管理，而不是創新，因此，要想採取後者，解決這些問題是可行的。