如何閱讀代碼（譯）

英文原文地址： 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%。專一於你要解決的事而且知道該怎麼深挖出你要的答案，你將會發現你會理解的很是快。