我的實習任務是重新編碼8年前由公司現任高級開發人員用另一種語言編寫的整個軟件。
唯一的麻煩是，我將軟件的組織結構從從下到上。例如，我改用了MVC，而不是“全部存儲在文件中”模式。
如何向他展示我當前的工作，而不會聽起來像“您以前的工作很爛，這就是為什麼我的與眾不同”的原因？
除非該開發人員已給您有關該項目的地域指示或通常令人難以置信的驕傲/傲慢/一無所知，否則您無需擔心。
我的代碼8年前寫的很爛。如果我在8週內（更不用說8年）看一下，我上週編寫的代碼將很糟糕。
讓上級領導帶動對話/審閱。不要戳熊，開始詳細解釋為什麼使用這個或那個技術細節，而不是以前的內容。如果被問到為什麼，您可以解釋，但盡最大可能不要貶低以前的內容。
年長者可能會看一下他的舊代碼，不寒而栗，然後正確指出所有不可避免地存在錯誤，錯誤，遺漏的情況等（因為編寫代碼確實非常非常難於實現）。
我如何向他展示我當前的工作，而聽起來卻不像“您以前的工作太爛了，這就是為什麼我的與眾不同”嗎？
稱呼它2.0。或3.0或4.0或其他任何值。只要確保您已經增加了主版本號，就可以清楚地看出該版本與其先前版本有很大不同。這樣，就不像您要糾正以前的代碼中的缺陷，而是要對整個項目進行重新設計以達到新的目標。
列出改進清單。
簡而言之，關注於什麼對新版本有好處，而對先前版本則不太好。列出實質性好處的時間越長，就越難辯稱這些變化不是改善。不過，請避免列出諸如漏洞修復之類的較小更改，因為您可能無需大量重寫就可以在現有代碼中進行更改，因此較小的更改將破壞您的論點。
請做好接受批評的準備。 即使該代碼是8年前編寫的，原始作者仍可能是該主題的公司主題專家之一，並且他/她可能會注意到一些其他人沒有的細節。以積極的態度接受批評。做筆記，以便您記住解決討論中提出的所有問題。
為任何反應做好準備。很有可能原始作者會很高興這個舊項目已被重寫，不再需要他們回答任何問題。或者，他們可能會感到有些連接到他們的早期項目之一，並傷心地看到它的手下敗將。只是要坦誠相待，盡力回答問題，傾聽他們告訴您的內容，並且不要太個人接受負面評論。
好的，您被要求將軟件切換到另一種語言。僅此一項就可以用來證明設計變更的合理性。討論為什麼該設計適合新語言（忽略它是否也適合舊語言），為什麼要做出選擇，以及在完成設計之前如何批准設計概念。這是面子大招。您之所以這樣做，是因為新語言是正確的選擇，而不是因為他的代碼很糟糕。 ，表明您作為項目的一部分基於新要求進行了這些更改。具體詢問他，他是否能想到您在功能方面一路上錯過的任何內容。這吸引了他在當前系統上的技術專長，並顯示出對他專業能力的尊重。
如果適用，請參考您特別需要解決的一些問題，並指出這些問題是選擇設計的原因。有時，當我們進行原始設計時會出現一些問題，這些問題要等到以後才會出現，並且這些問題可以完全證明改變工作方式是合理的。
根據項目的難度，確認他的原始代碼對您設計新語言版本有多大幫助，並且比從頭開始更容易。請注意不要將其放置在太厚的地方，但是承認他的版本很有幫助，可以使他解除武裝。
就您自己而言，記住8年對於軟件開發來說是很長的時間，您現在可能做了一些他當時無法使用的事情。如果您使用了其中一些較新的內容並將它們用作不同設計的部分理由，那麼它也會有所幫助。
最重要的是，尊重他，並承認他對系統應該如何工作的深入了解。如果您不認為自己的工作是垃圾，那您會發現與他一起工作更容易。
在討論更改時，請避免使用“您的舊方法”或“您的舊代碼”。加入開發團隊後，將其視為“我們的代碼”。
每個開發人員都知道，在幾年的時間裡，可能會出現新的框架，開發實踐等，從而使代碼段的工作更清潔，更快。無論是來自實習生還是資深的編程經驗豐富的老手，只要您聽起來不像是在挑剔他/她，還是拒絕承認對他/她的批評，您的高級開發人員同事都應該有一個開放的心態來公平地檢查您的工作。你自己的工作。
除了此處的其他出色答案之外，您還需要牢記創建解決方案時需要使用的所有變量（無雙關語）。最初的開發人員可能在8年前就編寫了很棒的創新代碼。 （請記住，ASP.NET MVC剛剛在8年前發布了版本1， https://en.wikipedia.org/wiki/ASP.NET_MVC，即使這樣，仍然需要一些版本洋蔥架構範例最早於在2008年7月發佈在Jeffrey Palermo的博客上（我對此很感興趣。）
您今天的代碼可能只是平庸。它可能仍然比舊代碼更好，但這是因為我們擁有新技術，多達5個較新版本的MVC，通過Nuget進行的第三方MVC支持/擴展等。
您還有一個有效的產品，因此您可能需要花費很多時間來重寫它；公司沒有必須立即切換到您的版本。以前的開發人員的時間表是什麼？他們是在緊要關頭讓事情盡快運行以支持新產品或新產品嗎？
您認為自己的好壞並不重要。重要的是您與他人的合作程度。如果其他開發人員檢查了您的代碼並說了諸如“我喜歡這個！比我做的更好。” ，那麼您可以輕拍一下。僅僅假設您的代碼更好將使您成為敵人。
最好的方法是請其他開發人員查看您的代碼和最終產品。 “我被要求做x。看起來怎麼樣？” 是一個足夠體面的問題，可邀請開發人員查看新代碼。
如果重寫確實是按順序進行的，則在開發過程中共享知識是向其他開發者逐步展示新功能的另一種好方法：“嘿！看看我發現的這個很棒的東西！” “我不知道此[語言，框架等]功能！想看看嗎？” 。在整個開發階段都沒有反饋很可能是一個問題，因為在整個應用程序中緊緊抓住潛在問題之前就已經發現了它們。
另一種防止開發過程中出現問題的方法，可以合併以前的開發人員，問一些看起來很奇怪的事情。並不是所有的代碼都被註釋掉，並且經過8年的開發和維護，事物的構建方式和/或工作方式仍存在潛在的原因。如果您問這些“為什麼？” 問題，您可能會失去功能或將錯誤引入業務邏輯，除非您有新的待處理業務需求積壓。
在進行審查之前，請確保原始編碼者知道已經進行了完整的重新設計，以使代碼庫對於新要求更加靈活和可擴展。
如果您可以指出一些要求示例，在重寫之前，它本來就比較複雜，但現在已經變得微不足道了，它表明該重寫是出於客觀原因進行的。
有時人們會討厭被重寫的“他們的”代碼，因此請確保他事先了解原因。
這個人在8年前編寫代碼時是否是高級開發人員？
可能不是嗎-因此該代碼不是“高級開發人員素質”。
除非他們仍然以當時的方式編寫代碼，否則在顯示如何使用當前最佳實踐改進他們的工作時，您應該很少擔心。
要求查看您的代碼調整。表示您認為它在原始版本上有所改進，但希望確定並向正確的方向獲取更多反饋。如果是這樣的話，正確性就可以說明一切，在您尋求對方意見時，它會尊重對方。
唯一的麻煩是我從下到上更改了軟件的組織。
您的另一個問題顯然是您未討論或未獲得執行權限在完成之前，您做了什麼：因為他不希望您有多少更改。
如果我是高級開發人員，正在審查重寫，那麼我的擔憂之一可能是：“我怎麼知道重寫破壞了現有功能？“
您對這個問題有答案嗎，例如有沒有定義的系統測試或驗收測試，該軟件的新版本仍在通過？
如果是，則根據其表面外觀和結構，更容易根據其優點來審查新版本：
如果沒有，則需要通過代碼檢查確定功能是否已更改；如果要完全重寫，可能會很困難。
第一步是停止以這種方式查看工作：您沒有收到重寫錯誤代碼的任務，而是將其移植到新的語言。就是您所做的，僅此而已。在移植時，會有不同的選擇，此外，如果代碼庫很舊，那麼如果沒有人遵循這個斜率，那麼您就不必擔心有人會對您的更改做出判斷。
作為旁注，您可能並不完全了解背後的所有原因。 8年前做出的選擇導致產生了代碼：也許那是當時他們在工具，約束，規範等方面可以做的最好的事情。
如果您是用8年的舊代碼重寫了新的語言，同時又完全改變了結構：首先，我知道一個事實，即如果公司將2009年編寫的代碼改寫為其他語言，希望長期繼續開發它。而且我知道它需要進行重大更改，因為我知道2009年它的某些部分有望很快停止工作。
我的問題是：我期望對該代碼承擔多少責任？如果您同時更改語言和結構，那是很勇敢的舉動。而你自己。你想給我看你的作品嗎？實際上，我不感興趣。這是您的代碼。如果運作良好，請為此感到自豪。如果不起作用，那就是您的問題。我不會幫你的
我的意思是你太遲了。在重寫之前，您可能會來找我。我本可以告訴您代碼的哪些部分是好的，哪些部分是不好的，因為我從來沒有時間做得好，哪些部分是醜陋的，因為它們有時包含奇怪的解決方法，如果您“修復”它們，它們將使應用程序停止工作。醜陋的位。
您擔心聽起來像“您以前的作品很爛，這就是為什麼我的與眾不同”的原因。我不知道那名高級開發人員是八年前的實習生，還是那時的經驗豐富。在前一種情況下，他可能會認為“您的代碼是不同的，它吸收的內容甚至更多甚至更多”。如果那時他是高年級學生，他可能會想出一份您遇到的麻煩清單。