面試經：GitHub

GitHub 愈來愈有名，不少同窗都把它做爲一個關鍵字加入本身的簡歷當中。不過我在面試中，問到如何使用 GitHub，對方一般會答覆：上去看源碼呀！這個答案徹底沒法讓我滿意，具體的緣由，一方面能夠參考我以前的一篇文章《談學習：讀源碼》，源碼不是小說，直接看源碼收穫過小。另外一方面，看源碼是一個太直接的邏輯推斷——上面有源碼因此我去看源碼——我不認爲這是一個細心耕耘慢慢養成的習慣。

接下來我想簡單談一下，我認爲應該如何使用 GitHub。

Issues 和 PR

一個 GitHub 倉庫可不只僅是一份源代碼那麼簡單。GitHub 是開發者社交平臺，因此每一個項目在代碼以外，都會有兩個很是重要的模塊：

1. Issues 問題，包括 Bug，和其它使用者但願有的功能

2. Pull Requests（PR） 其餘的開發者在這個項目上作出了一些改進，或者修復了一些 Bug，但願可以合併到 master 當中，就會發起 PR

完美的代碼是不存在的，越是用的人多的庫，存在的問題，或者說被發現的問題可能就越多。閱讀其餘人提的問題，不少時候能夠得到不小的收穫，好比，你們開發時都遇到了什麼問題？有沒有與我相似的狀況？他們是怎麼解決的？你們最想要的新功能是什麼？有哪些值得關注？我能作什麼？等等。

以及，多是更重要的，咱們應該怎麼樣經過 Issues 與倉庫的原做者進行交流。

畢竟咱們每一個人的時間都是有限的，對於大部分開源的類庫來講，瞭解怎麼用、有哪些問題、怎麼避免踩坑，一般會比你知道它某個函數是怎麼寫的更有價值。

看文檔

好的開源類庫一般還會有一個作得很是到位的地方，即是它們的文檔，作得一般詳盡有價值。經過閱讀文檔，能夠很快的瞭解這個倉庫是幹嗎用的，應該怎麼用，能解決哪些問題，以及接下來，它的發展方向是怎樣的。

據我觀察，文檔一般分佈在三個地方：

1. README.md，也就是打開倉庫頁面，默認渲染在文件列表下面的那塊

2. 官方網站，一般在導航下方，倉庫簡介那裏

3. wiki，經過導航連接能夠到達

觀察提交頻率

並非全部的倉庫，都有開發者在進行積極地開發和維護。若是搜索到幾年前的文章，被導引到一些比較古老的倉庫，可能出於某種緣由，已經沒人對它進行維護了，這個時候，該放棄就要放棄。

人生苦短，時間有限，總會有更具價值的倉庫供咱們學習。

GitHub 熱門趨勢

GitHub 還有一個熱門趨勢頁面，從中你能夠了解到全世界的開發者都在關注哪些倉庫，你能夠把本身感興趣的那些加星標記一下，未來不定時的翻一翻看一看它的 Issue、PR 和文檔，一般都會有不小的收穫。

GitHub Pages

GitHub 還提供給咱們一個很是好的靜態網站空間，徹底免費，全世界都有 CDN，不用白不用。即是傳說中的 GitHub Pages。

咱們能夠用它寫博客，作筆記，重點是內容徹底能夠進行版本管理。

具體作法請自行 Google。

不要放棄提交本身的倉庫，也應積極向別的開發者提出 Issue 和發起 PR

我以爲這件事和寫博客同樣，若是你只是在紙上記筆記給本身看，那多半會不求甚解；可是你想到寫成博客總會有人看到，那多半仍是會把要寫的內容搞清楚，寫全面，邏輯清晰可自洽。因此寫博客是比記筆記更好的學習方法。以此類推，把本身的倉庫推到 GitHub，也理應也是比在本地練習更好的學習方式。

這裏毫不鼓勵你們亂來，相反，我但願你們對本身的行爲負責，重視 Issue 和 PR，畢竟都是提給其餘開發者的，或多或少都會對別人形成影響。因此在提以前，十分有必要閱讀倉庫主人的提交須知，按照對方的代碼規範書寫代碼，寫好相關測試，而後再提交。作到言之有物，切不可亂來畫貓。

---

總結

這篇文章不是傳授你們應聘技巧的，而是但願分享本身的一些經驗，讓你們可以經過 GitHub 這個世界上最大的代碼託管平臺，正確的學習開發技巧。

若是您有相關的經驗技巧，歡迎交流。

---

人肉與 個人博客 同步。