for 好處 out 下一個 回顧 綠色 選項 some lam

英文原文地址：https://spin.atomicobject.com/2017/06/01/how-to-read-code/?utm_source=wanqu.co&utm_campaign=Wanqu+Daily&utm_medium=website 作者：WILLIAM SHAWN “我討厭閱讀別人的代碼”在所有經驗層次的程序員中都普遍存在著這個問題。然而，這又是一個必備技能，特別是程序員直接使用現成代碼時，如果你以正確的角度和正確的工具來處理，那將是一場很享受和有啟發的經歷。 我們討厭讀別人代碼的原因是代碼不是我們自己寫的。那並不是說我們都悄悄地堅信我們才是這個星球最好的coder並且沒有人能寫出像我們一樣的好代碼。那是因為在寫代碼的時候會有一個積極的思維過程， 被動的閱讀者沒有獲得這種親身體驗的好處。 你再屏幕上讀的代碼可能出自多人之手。可能涉及到討論和合作。可能一個版本花費了數周的時間才敲定，裏面還包含了原作者一些未文檔化的約束條件–但是你卻不知道。 作為一個reader，你所能看到的都是完成品，並且，除非你一點點深挖，否則你看到的就是屏幕上別人的單詞。 1.學會深挖

當你一頭紮入一個成熟的代碼庫時，你會覺得你不想是一個開發者，更像是考古學家、私家偵探、或者聖經學者。很好，因為你有一大堆事要處理。 如果你足夠幸運接觸到一開始就用版本控制的代碼庫，慶祝吧。你接觸到很多元數據將使你的理解不局限與代碼，還有上下文，那將容易很多。我將假定你使用了Git，如果用了SVN也一樣。 git blame 你可以使用git blame命令來獲取作者名字，最後修改時間和每一行提交的哈希值。熟悉這些開發者。如果你運氣好，作者可能只有幾個，而且一部分還在和你一起工作，那他們可以作為你的資源。運氣不好的話，那就可能是一大堆你不認識的開發者了。 不管怎樣，盡量去了解主要開發者。如果你遇到一個解決不了的奇怪問題，通過git blame找出作者直接去問他吧。 git log 使用git log功能來查看所有的歷史提交記錄。這個命令能打印信息，如果你想查詢一些commit信息，別忘了用這個功能。git log | grep someFunction -c 3(-c 3可以顯示匹配的3行內容) git log也可以顯示單個文件的提交記錄：git log -p index.js.註意誰最近在一直修改他，出問題的時候就可以直接找出來了。 2.適時回顧 你可以通過check out查詢任何一次commit，讓他完全就像是最近提交的一樣。當你遇到一個很難追蹤到的bug時，你可以通過查詢最後一次正確提交開始追蹤，或者你僅僅覺得無聊想看看你來之前，幾年前的歷史信息。 如果你的項目托管到了Github或類似的網站上，你可以通過查看問題、pull請求和code review來獲取大量信息。留意那些大量討論的問題。那些可能就是你最終會遇到的痛點，提前了解該怎麽解決。 3.看規範

規範是新的註解。看單元規範，理解那些功能和模塊該怎麽做，邊界情況該怎麽解決。查看集成文檔了解用戶在你的程序中是怎麽進行交互的並且你的程序支持哪種工作流。 4.把評論當做提示 如果你偶遇一個很困惑的功能並且看了相關評論後更困惑了，考慮下這個評論是不是已經過時了沒有被維護。程序員的眼睛要有跳過這種綠色文本行的功能，這種評論可能是在描述一個這幾個月（幾年）都不存在的功能。 5.找到主要的 這可能看起來明顯，但你要確保你知道代碼是從哪裏開始運行的並且是怎麽設置的。看看文件包含的地方，被實例化的類，和被設置的控制選項。 你可能在代碼庫的其他地方都見過他們。一些模塊可能經常被用到並且從代碼庫中解耦出來。他們代表著更小更容易被消化的功能，你應該在處理更大的應用程序之前熟悉他們。 運行git blame功能看看最近哪些地方改變了。近期大量的代碼改變可能會指引你進入到最近幾周團隊面臨的挑戰中去。可能他們做好了一個新的庫，可能他們繼續在努力配置一個運行不怎麽好的庫，又或許他們只是更新了一個需要被定期更新的模板文件。 試著從其他源文件中找到這些模塊看看他們是怎麽使用的。你能從直觀概念中感覺到他們是怎麽運行的。 6.註意代碼風格
你學習這個應用程序的原因是你最終要編寫他，因此要註意代碼風格。當然，這些東西包括命名約定，空格約定，和大括號約定，但也包括代碼約定。 他一般抽象了多少層級呢?如果代碼抽象了很多層，你就應該編寫同樣抽象層級的代碼。 如果你深挖了足夠多的歷史代碼，你可以精確的找到哪個地方的代碼已經抽象出來了。這段代碼過去是什麽樣，並且以後又會是什麽樣？當你自己寫的時候盡量跟隨同樣的約定。 從更細的層面上講，別的團隊成員的代碼是什麽樣的呢？如果他們傾向於使用for循環來遍歷map，那你最好同樣傾向於用for循環。 如果你不喜歡一個約定，那就告訴你的團隊以後要修改的地方，但別在同一個文件中混入大量不同風格的代碼。一個文件越像一個人寫的就越好。風格保持一直比寫的漂亮更重要。 7.期待找到垃圾代碼
你也許會發現從沒用到的功能，或者從沒用到的文件。你可能會發現幾年都沒碰一下的註釋掉的代碼(git blame).別猶豫，不用花太多時間去想它，並且不要害怕把他去掉。 如果代碼在這有他存在的原因，會有人在code review的時候打上一個flag的。你的行為將為下一個閱讀者減少腦力開銷。 8.不要迷失
記住，當你發現自己身處荒地時不要覺得不舒服。不要指望他是一個線性的前進過程，不要指望把他了解到100%。專註於你要解決的事並且知道該怎麽深挖出你要的答案，你將會發現你會理解的非常快。

如何閱讀代碼（譯）