接管別人的代碼

Question

我正在接管別人的代碼。什麼是一些很好的方法來儘可能快地瞭解程序員做了什麼？我一直在運行它，逐步瀏覽並查看調用堆棧。我還可以做些什麼？

對不起，我忘了提及，但有一點文件，我一直在試圖解決簡單的問題。謝謝！

Answer 1

通常最好的方法是開始處理修復小錯誤的代碼。你花更多的時間來學習代碼庫是唯一的方法。沒有什麼神奇的方法來學習代碼庫。這將需要數週，數月甚至數年，具體取決於複雜程度。然而，對於大多數通用業務系統而言，加速時間大約是6個月的代碼知識，6個月的時間將行業知識分開以真正理解全部。

Answer 2

設置日誌記錄以觀察事件發生的順序。

這裏閱讀：Hired as a developer to maintain and update current code base, no docs!

Answer 3

在它修正了一個簡單的問題。

編輯： 然後解決更大的問題，並開始編寫文檔和單元測試，瞭解您理解的領域。建立在這些領域上，有一天你可能會理解整個系統。

Answer 4

文檔？讀取代碼本身，而無需在調試器中運行？

除此之外，你正在做我會做的。

Answer 5

我發現我不會完全學習代碼，直到我開始修復錯誤/修改它。如果原來的程序員仍然在那裏，那麼在實現它們之前討論這些變化會有所幫助。

Answer 6

日誌很好地看到代碼的作用。

如果您有版本控制系統，您可以查看程序員對哪些代碼段做了哪些更改，瀏覽一些歷史記錄。

我發現它有時候會嘗試理解程序員的代碼風格，這有助於我理解他如何思考問題並解決問題。

Answer 7

開始編寫單元測試，因爲這會讓你使用他的類/方法，並且你會做兩件事，學習它，或者找出錯誤或準備工具以防出現錯誤。

Answer 8

我要做的第一件事就是看看最簡單的對話框及其代碼，主要是分析編碼風格，並看看開發者是如何安排代碼的。一旦你知道了編碼風格，並且粗略地知道文件中所有東西都存在的地方（或者如果東西是隨機放置的 - 即使這有助於知道），它也會更容易地完成其他任何事情。

Answer 9

如何快速理解其他人的代碼沒有銀彈。特別是如果它充滿黑客並且沒有文檔可用。

您應該嘗試瞭解類結構，並使用調試器幫助執行軟件的正常流程。

不要跳過太多的代碼段「哦，我想我知道這個部分做什麼」。不，你沒有。您會驚訝於我們可能在代碼中找到哪些「創新」。

Answer 10

如果可以的話，與其他人的代碼的用戶交談（最終用戶或其他需要使用他的代碼的開發人員）。這會讓你對其他人的代碼質量有所感知 - 它只是發佈了幾個bug，還是需要6個月的修改才能正確使用？開發人員是否注意製作精美的應用程序，還是一團糟？這應該給你一些想法，你是否需要稍微調整代碼或者開始替換大塊代碼。

Answer 11

我喜歡開始添加測試代碼的方法，如果他們不在那裏。弄清楚如何覆蓋代碼可以讓你深入瞭解代碼路徑，期望的輸出應該是什麼，等等......

Answer 12

其他人都說過的一切都是在學習編碼器所做的準確的事情。

看着它的另一種方法是學習程序本身。像用戶一樣深入地玩這個應用程序，並理解程序本身的功能。一旦你徹底理解了最終的系統，就會更容易地弄清楚它是如何以及爲什麼寫的。

Answer 13

記下你對班級，職能等等的瞭解並不會傷害到下一個人（或另一個被僱用來工作的人）。另外，當我這樣做之前，我發現在嘗試理解代碼之前最好使用該程序。可能聽起來很明顯，但更多的你看到之後會有意義的。正如其他人所說，單元測試也可能以同樣的方式提供幫助。 （當你對重構有足夠的自信時，也很有幫助。）

Answer 14

有一件事可以幫助我更快地學習系統，我自己編寫文檔。

• 我得到一個概述
• 我會看到很多的錯誤/壞的設計決策。這使得它們更容易訂購。 （而不是選擇一個不相關的錯誤並解決它，我會修復那些真正重要的）
• 我後來有一個文檔。
• 文檔會更容易證明重構/重寫衣服的

Answer 15

我想知道的代碼做什麼，這是寫在一個較高水平，解決問題是一個良好的開端。然後，那個人可以在心理上，在高水平上嘗試設想如何使用所使用的類型工具來解決這樣的問題。

從那時起，查看代碼將具有一些意義，它將有助於使其遵循原始開發人員的想法。另外，當你迷路時，你會很快發現。

我也相信代碼應該記錄下自己，因爲大部分時間都是代碼以外的文檔與代碼不同步，可能會產生誤導。所以在這裏和那裏的一些評論，類頭，方法評論應該也有幫助。

我第一次繼承他人的代碼，兩天後我有偏頭痛，我是一場噩夢。

所以玩得開心。

Answer 16

我開始的第一個地方是數據庫。

根據我的經驗，理解數據模型是您在瀏覽代碼時給出上下文的關鍵。 （這裏假定數據模型不是一個通用的鍵值通用實體表）

Answer 17

我在去年的大部分時間都在處理從其他人那裏繼承的代碼。沒有任何文件和大量的系統意圖要做的事情不是在任何地方寫下來，而是在客戶頭上。對我來說，關鍵在於儘可能多地提問，並從各種可用來源收集信息。我會建議您隨時編譯自己的文檔。

許多人可能會說不重寫代碼，但如果代碼評論不好或編碼不好（通常不是自我記錄），這可能通常是最好的方法。對於我所苦苦掙扎的代碼，往往是最好的解決方案。

在開始之前，另一個有用的東西是某種標準文檔。標準文檔將幫助您破譯代碼或使代碼達到規格並使其更易於理解。