閱讀源代碼

Question

如果您閱讀其他人的源代碼，您如何處理代碼？你在尋找什麼模式（數據類型，循環，控制流的使用......）？多久可以閱讀其他人的代碼而不感到厭倦？到目前爲止發現的最令人興奮的模式是什麼？

Answer 1

除了一般的做法明顯的「從上而下的工作」，這取決於爲什麼我讀它：代碼審查，試圖瞭解一點avaialable代碼爲我所用適應，試圖學習新技術等。

它也很大程度上依賴於語言。如果是OOPL，我可能會這樣做：

1. 首先查看主要班級關係，並嘗試瞭解每個班級的主要職責。
2. 看看類之間的交互，看看它們如何協作。
3. 看看關鍵類的接口，看看他們爲他們的合作者提供了什麼「服務」。
4. 看不平凡的方法中，如果重要的是要了解如何他們正在代替什麼他們負責。

Answer 2

這一切都取決於你正在閱讀什麼類型的代碼。它是一個Web應用程序，一項服務，一個桌面應用程序？當我開始閱讀其他代碼時，我通常會開始尋找使用的設計模式。或者針對框架特定的事情。但是，這又是如果你正在做一個評論。如果您爲了自己的興趣閱讀並學習某些東西，那麼實際上沒有答案 - 您應該仔細閱讀並理解代碼。

Answer 3

謝謝，如果我理解正確，第一步是確定上下文，第二步確定API的位置，並將API放在上下文中。我只是意識到它有點像看着建築物或藝術品，你可以專注於使用的材料或零件的功能，嘗試不同的視角，判斷零件如何適合整體......有一個很好的作品的發現過程：here - how mathematicans think

Answer 4

起初，我忽略了改變代碼的衝動。這有時很難做到。但先理解後再改變可以爲你自己節省很多討厭的「學習經驗」。

接下來如果格式不好，請重新格式化。如果有的話，請使用代碼格式化程序。這是因爲你傾向於看縮進，如果這樣做不好，你對代碼的理解也是有問題的。

然後，如果有複雜的數據結構，我喜歡畫一個小圖。這裏面臨的挑戰是保持儘可能簡單。大圖在牆上很有趣，但大多數情況下，它們都很麻煩。所以這是浪費時間。

如果您終於明白了一段代碼的作用，請發表評論。這是至關重要的，否則下次你來這裏時你不會理解它。

以下步驟是創建單元測試。現在，您不僅可以測試代碼，還可以測試您對代碼的理解。

最後，如果您瞭解它，並且您知道它可以（並且需要更好），請更改它。但一定要運行測試。除非你是由每個解決的錯誤支付。

Answer 5

這是一個髖關節新術語是Code Spelunking。

Answer 6

選擇您在最終產品中理解的項目，並瞭解它是如何組合在一起的。如果你有單元測試，那麼他們是一個很好的幫助。