您現在比任何人都更了解該軟件。

因此，在進行演示時，請專注於運行良好（或至少應按要求運行）的部分。當前無法正常運行的任何其他功能都可以標記為“進行中”或“原型”。使用這些來討論如何改進這些功能（或者更好的是，讓他們告訴您這些並不重要）。可以，什麼不可以。另外，請查看與他人的任何文檔/談話，並了解應該應該做什麼以及如何工作。展示知識並表現出對系統的信心將使您和您的言論充滿信心。

這是在您和經理之間的，您如何擔任此職務—即，如果您告訴他們原始開發人員已經離開項目並且您已經必須收拾the繩。人們確實比不誠實更尊重誠實，並且掩蓋以前的開發人員的嘗試總是被視為掩蓋（人們不喜歡這樣）。允許重新調整項目的重點（以前的開發人員可能還是帶領該項目走了一條不必要的路線）。

在這種情況下，您需要遮住背部。始終以書面形式了解問題所在，尤其是經理們的反應是忽略這些問題並添加功能。就像發送電子郵件一樣簡單。

'您好，老闆，在我們進行進一步交談時，請您澄清一下我應該優先考慮的事項。 X中有很多錯誤，或者我應該只使用新功能。另外我還必須做一些數字功夫來解決W中的錯誤，可以嗎？'

如果您的後背被遮蓋了，沒關係，經理就在其中，而不是您，您只是在完成工作。

這種情況並不像您想的那樣罕見。肯定會感到快要死了。這就是為什麼他們只分配了一名初級開發人員給它的原因。

在軟件為某人解決問題之前，他們願意為此付費，但該軟件毫無價值。如果它需要一些功能使其進入現階段，那麼那是投資該軟件的最佳場所。花時間修復沒人願意付錢的東西並不是對資源的良好分配。不存在。這可能會導致銷售損失，這完全是您的錯。您不知道所有這些決定的原因，因此請堅持下去。負責整個系統。

設置為失敗的可能性很小（儘管並非不可能）。企業更有可能嘗試從當前的死角中賺錢。

因此，您可以做些什麼來幫助演示順利進行。從一開始，您就已經清楚了代碼的狀態，並已從管理層獲得了優先級。如果演示不能順利進行，那不是因為您的工作做得不好。

如果您的公司具有合理的文化，那應該沒事。

如果公司有一種怪罪的文化，儘管您向管理層提出了所有建議，但您因演示或代碼狀態而受到指責，那麼下次您就可以更具防禦性。以書面形式獲得一切，對修復錯誤要更加固執。如果您對此有所呼籲，請指出您過去曾因不這樣做而感到厭煩。在這種文化中工作並不好，您需要留心（如果可以另謀高就，那就找一份工作吧）。

但是我建議給您的公司一個機會。盡您所能，並接受公司的共同努力。

這種代碼庫經常出奇地存在，而且我們許多人都在類似的代碼上工作。 （已經指出，代碼庫反映了產生代碼庫的組織結構，或者確實反映了組織的編年史）。這是我學到的一種實用的方法：

• 管理人員不知道代碼庫（實際上既是優點也是缺點），完全不關心錯誤，並且僅受激勵添加新功能。因此，出售您正在開發後者而不是前者的產品絕對容易。因此，他們很容易在內部將其出售給客戶。
• 因此，當項目開始時，超級快速地對最嚴重的錯誤進行分類，或者添加失敗的測試用例，或者至少記錄下該錯誤。錯誤跟踪系統中的場景。在時間允許的情況下，或者相對於所開發功能的bug的明顯存在或嚴重性，斷斷續續地重新進行檢查。對應該固定的東西進行分類非常困難，但是時間不允許。但是，以一些未知的白天時間和預算可能會神奇到達的態度來編寫錯誤報告並擴大範圍。
• 然後，當您增加範圍的功能時，所有相關的重構和錯誤修復都會成為該功能的依賴，包括在工作中，時間估算，測試方案。您將如何定義和報告工作情況。只有您知道如何克服它們。只要執行摘要中說“實施功能X”，他們就不會在意。
• 通過在幾週前進行內部演練來演示演示，以向他們展示“我們為X實現了代碼，但是具有必須修復的錯誤A，B，C”。實際上，安排時間表向您的管理層進行內部演示，無論客戶是否要求。逐漸使他們習慣於將x％的時間用於估算中的錯誤修復和測試，或者相反，在期望工作代碼之前進行第一個演示週。
• “在他們的世界中工作，而不是你的世界”

分配了一個沒有註釋，沒有文檔，沒有培訓或指導者的混亂項目。我是唯一從事此項目的人，沒人知道或根本沒有看過代碼。

第1步：您碰到的所有東西都要首先編寫單元測試，以驗證它已經做了它應該做的事情（或表明它沒有做），並且表明您並沒有使它變得更糟。您將此因素考慮在內。這也構成了代碼的文檔，使人們可以從測試中理解它。

現在已經過去了幾個月了，現在是時候顯示程序了

Step 2：確保您定期與客戶進行演示/預覽，以設定期望並確保您做正確的事/優先事項。

由於時間的限制，重構從來都不是一種選擇約束和經理的意願

第3步：在進行此類討論時，請將其記錄在電子郵件中以進行確認。這樣，您就可以確保臟棍在開始髮指責時指向正確的方向。

因為我不得不做一些奇怪的事情來繞過錯誤

從不隱藏錯誤，提出錯誤，將它們添加到錯誤跟踪器並做出判斷呼籲對其進行修復（見上文）

當我被告知要開發更多功能而不是進行錯誤修復時，如何避免因為繼承的已經存在錯誤的項目而受到懲罰？ p>

請在進行項目時進行盡職調查，而不是在每個人都將發現項目已經南移時進行。

每個開發人員都認為他們繼承的每個項目都是一個爛攤子，這是很自然的反應，而且我理解想要重構所有內容的本能，就像您想像的那樣。 p>

但是，如果代碼已經在起作用並且可以滿足其目的，並且企業需要添加新功能，那麼您應該專注於添加新功能。

這並不意味著您不能隨便重構。

添加新功能時，您可能會使用已經存在的代碼，這樣做時，請整理並添加測試，並確保

Brownfield開發（即使用和改進現有的 crappy 代碼庫）本身就是一項技能，您不能僅僅重寫您遇到的該類別中的每個代碼庫。

如果您真正地努力與and合作，而不僅僅是找到新工作，那麼您作為開發人員的價值就更高了。改善您的代碼庫

冒著浮躁的風險，世界對程序員來說是飢餓的。有些組織可能會破產，那麼，尋找新工作。

其他張貼者正確地指出，繼承的混亂是很普遍的，甚至是不可避免的。對於大型，長期運行的項目。公司有責任將精力用於修復或改進它，而不是您（除非您擁有股權）。如果是時候進行重寫了，那麼就由他們來決定（您只能建議）。

在這種情況下請當心。

我已經進行了30多年的編程，一段時間之後，您真的注意到周圍的基礎架構對您做好工作至關重要。 您有權嘗試做得很好。

如果操作不好，請盡可能在工作時開始尋找。請注意您如何向準新雇主表述，抱怨上一份工作的糟糕程度為您贏得很少的布朗尼積分。

恐怕您為時已晚，無法對即將發生的問題真正做好很多事情。您不能責怪您的前任，因為他已經走了-您可以在第一個月左右擁有（通過電子郵件發送），但現在不可以。

如果將來發生這種情況您要做的是：-

• 快速評估您繼承的內容。
• 通過電子郵件通知您的經理，並建議採取適當的補救措施，而不是針對一些錯誤進行修復在繼續之前的幾週內。
• 將所有拒絕/堅持使用新功能的內容拒之門外（打印出來並保存在工作中和在家中的文件中，以備後用。）
• 輕推任何對新功能的請求，說您受到驚嚇可能會破壞脆弱的代碼庫。像上面那樣，向經理提出最終決定。
• 為添加的所有內容編寫單元測試。
• 將為新功能給出的每個估算值填充除了之外，還添加了單元測試（有人怎麼會與您的估計相抵觸，他們不知道代碼？）。
  然後，使用您的“額外”時間：
• 添加
• 修復損壞的測試。
• 重構舊代碼。

您的Bug。每個新功能都會改善這種情況。

您所處的專業背景是0，並且被要求對一個錯誤的代碼庫進行工作，並告知您無法修復錯誤或重構。

但是-1.您不知道代碼庫是好/壞/典型。您沒有現有技術可以將其與2。沒有人在審查您所做的工作，這意味著即使您在進行重構，也無法知道您是否正在使代碼基礎變得更好……您再也沒有經驗。3。沒有人關注代碼庫，因此您實際上可以根據需要執行盡可能多的錯誤修復和重構，因為您的經理無法分辨出差異。

我知道每個人都有不同的情況，但是找到一個擁有一對知道自己在做什麼並且健康的代碼審查過程的環境，對您的職業而言，比在這家公司工作10年所賺的錢更有價值。所以-我不會擔心即將到來的演示（不會因為您的過錯而失敗，而是您的經理完全在這裡過錯）...我將專注於讓自己處於更好的狀況，這是否意味著

（另一些經驗豐富的人可能會適應這些情況，如其他答案所述。但是，剛從大學畢業您的頭等大事必須是學習做您的工作，而現在您還沒有做。）

很多人都同意我的觀點，但是我認為還有一點需要提及：這對您來說是一個巨大的機會。

考慮一下。您是剛從大學畢業的初級程序員，並且完全沒有經驗，是唯一被分配從事軟件應用程序工作的人員。這告訴我，該軟件的管理優先級很低。他們已經有效地註銷了；在他們看來，該軟件已經失敗了（從您所說的來看，不難看出他們為什麼得出了這一結論）。

這意味著您不會失敗；您只能成功。

我的建議是信任您的管理層，添加功能並按照Pete在其答案中列出的方式進行演示。如果您的管理層很聰明，他們會嘗試通過應用程序提供的功能來銷售客戶端，這與銷售應用程序本身是不一樣的。我猜想，如果客戶叮咬，他們會商定一個價格，其中包括修復（甚至重寫）代碼的錯誤部分。碰巧的是，您將在那部分工作中處於領先地位。如果不是這樣，那麼您的管理人員就不會損失什麼，除了一個非常初級的（即便宜的）程序員要花幾個月的時間。

這種思維方式有兩個含義。主要的問題是，除了已經在做的事情之外，您還應該開始考慮修復代碼需要花費的時間和精力。開始考慮計劃和時間表，以便為管理人員提供一些選擇。如果他們沒有買家，他們將不會有興趣。但是，如果有潛在的買家，那麼當他們開始就價格進行談判時，這類信息對他們來說至關重要。

希望您不僅告訴了他，還以書面形式告訴他有關混亂的情況。這樣，他便從一開始就了解情況，不會對您負責。

根據我的經驗，在這種情況下，經理常常像開發人員一樣樂於責怪開發人員。離開公司！

這可能對您跟踪發現的每個錯誤並將其保存在經理可以輕鬆看到的地方很有幫助（請注意，不要以被動攻擊的方式-告訴他您的意思）在做）。即使您的公司沒有錯誤跟踪軟件，即使它位於共享的“已知問題”電子表格中也是如此。如果政治和後勤許可，則可能鼓勵用戶執行相同的操作（在同一文檔中）。您甚至可以讓您的經理來評估嚴重性並為每個嚴重性分配一個優先級（關於要求您添加的新功能）

我猜您沒有擁有一個功能完善的質量檢查部門，或者沒有那麼遠的地方，但是如果您這樣做，他們在這裡的投入將非常有益。

這不僅表明您正在積極地清理混亂，而且如果出現問題，他可能會怪你，也可以掩蓋自己。

讓老闆支持你。確保您的老闆確信存在嚴重問題，以便他可以從高級管理層那裡獲得時間和同意。然後，請公司中最好的架構師來幫助您重新設計，重構或重寫項目。與您的經理和架構師一起創建明顯更好的程序。在過去的六個月中，這發生在我身上。