作為一個資深的諮詢師、程式設計師，GitHub 是我用過的最好工具，因為 Google 並非總是那麼用。GitHub 是一個寶藏庫，可沒有藏寶圖，GitHub 一1億的倉庫也和你沒有關係。這麼一些年下來，也算是掌握了一定的技巧，寫篇文章記錄一下，也就順其自然了。

總結一句話便是：GitHub 來搜尋 Google 搜尋不到的。它們可以 work 的原因，都是因為我們想做的事情，已經有人已經走過。如果你走的是一條新的路，那麼這篇文章對你來說，意義可能沒有那麼大。

GitHub 尋寶指南

尋找 Demo 節省時間

在工作上使用新的技術，和自己平時的練習，終究差得有些遠。工作的時候，我們偏向於目標程式設計，對於速度和時間的要求，要比自己業餘時間要高得多。一旦有了這種壓力，便會在 GitHub 上尋找相應的 Demo，瞭解原理、稍微嘗試，再引入到專案中。

這時，便會按技術棧的關鍵字搜尋，並按更新時間進行排序，以查詢是否有合適的 Demo。

生命有限，如若是每次我們嘗試一個新的技術，總得自己編寫一個個 Demo。編寫多個 Demo，都得花去個半天八小時的時間。如此一算，能花費在其它事情上的時間便更少了。若只是試用官方的 Demo，往往是比較容易的。可我們編寫應用的時候，總得結合到當前的場合來。這時整合並不是一個輕鬆的工作，依賴衝突、引入第三方依賴等。

溫馨提醒：對於簡單的專案來說，自己直接寫 Demo 會更加方便。嘗試專案需要成本，若是需要嘗試使用多個專案，那麼有可能就浪費時間。

尋找腳手架：加快前期開發

無論是後端的微服務架構，還是前端應用，應用的架構正在變得複雜。後端微服務，需要結合一個個的框架，哪怕是 Spring Initializr 這樣的工具，也只能幫助我們搭建專案。我們還需要配合其它工具，一起搭建出一個基本的系統。對於前端應用也是類似的，若是 Angular 這樣大而全的框架，時間花費倒也是不多。如 React 這種需要組合的、小而美的框架，使用官方的 create-react-app 也很難做出我們想要的東西，尋找一個合適的腳手架是一個更好的選擇。

這時，我們大抵可以，直接使用技術棧 + boilerplate 又或者是 starter 等關鍵詞進行搜尋，如 react boilerplate。如果其中找到的組合技術棧，不符合自己的要求，那麼再加上相應技術棧的關鍵字，如 react redux boilerplate 即可。有意思的是，在這時使用 Google 會比 GitHub 方便一些。

溫馨提醒：我們需要衡量：修改腳手架的成本，是否比自己重頭寫快。

尋找 awesome-xxx：探索可能性

練習新的框架，我總習慣於，編寫一系列相關的 DEMO 專案，然後使用 awesome-xxx 探索可能性。

Awesome-xxx 系列，是 GitHub 上最容易賺 star 的型別。但凡是有一定知識度的領域、語言、框架等，都有自己的 awesome-xxx 系列的專案，如 awesome-python, awesome-iot, awesome-react 等等。在這樣的專案裡，都以一定的知識體系整理出來的，從索引和查閱上相應的方便。如果你想進入一個新的領域，會嘗試新的東西就搜尋 awesome xxx 吧。

溫馨提醒：awesome-xxx 只意味著它們包含儘可能多的資料，並不代表它們擁有所有相關的庫。

模仿輪子的輪子

大學時，我在練習寫嵌入式作業系統，uC/OS-II 對於初學者的我來說，太複雜了——有太多無關的程式碼。便在網上找尋相關的實現，也便是找到了一些，在那的基礎上一點點完善作業系統。

學習一個成熟的框架，直接閱讀現有原始碼的成本太高，畢竟也不經濟。最好的方式，就是去造輪子。從模仿輪子之上，再去造輪子，是最省力氣的方式。再配合《造輪子與從Github生成輪子》一文，怕是能寫一系列的框架。而造一個相似輪子的想法，往往很多人都有。尤其是一個成熟的框架，往往有很多仿製品。

於是，當你想了解一個框架，造個輪子，不妨試試搜尋 xxx-like 或者 xxx-like framework，中文便是 仿 react 框架 或者 類 react。如我們在 Google 上搜尋 react-like 就會搜尋到 inferno。不過，按 GitHub 的尿性，要搜尋到這樣的框架，並不是一件容易的事。這時 Google 往往比 GitHub 搜尋好用。

所以建議：平時上班休息時，搜尋相關的輪子，回家就可以造輪子了。

學習資源

GitHub 上擁有大量的學習資源，從各類的文章到筆記，還有各式各樣的電子書。如：

只需要搜尋： 型別 + 筆記，如 作業系統筆記 就能找到一些作業系統相關的筆記。
只需要搜尋： 書名 就能找到一些和這本書相關的資源，如 重構改善既有程式碼的設計。

與此同時，GitHub 上還會搜尋到各種 未經授權英文書籍的翻譯，又或者是各種電子書的 PDF 版。作為多本書的作譯者，當然不鼓勵 GitHub 上找到一些盜版書。

而在 GitHub 上又有一些庫，可以提供相應的學習資源，如 free-programming-books-zh_CN，即免費的程式設計中文書籍索引。

建議：請尊重版權，哈哈哈。

金鑰/密碼

GitHub 上有太多這樣的東西，儘管我沒有能趕上個好時候，找到一個合適的金鑰。有相關多的資料洩漏和資料庫被扒，和 GitHub 上存在的金鑰和密碼有關。

不過，好在 GitHub 已經在著手解決這個問題：自動刪除相關的提交、程式碼警告等等。

私有、商用的 SDK 或程式碼

總有人，會將一些商用的程式碼，或者公司內部的程式碼，提交到 GitHub 上。如果你偶爾看到這樣的程式碼，除了每一時間告訴作者，還可以偷偷 Clone 一下程式碼——雖然這樣做不對，但是我還是想看。

如在 ThoughtWorks 的面試流程裡，有一個步驟是程式碼程式設計的作業，個人的實現是不能公開出來的。接到一份作業的時候，總會去 GitHub 搜尋相應的程式碼是否被提交了。提交了，倒是也得提醒一下相應的候選人。

過去，我在使用 Phaser 編寫應用的時候，對應的粒子系統是收費的。由於我只是嘗試這個粒子系統，便沒有購買的想法。我一想 GitHub 上可能有，於是搜尋了對應的 particle-storm.js，然後就中獎了。就便愉愉快快地去寫我的 Hello, World，最後發現它太耗費資源了，便放棄了。

建議：一旦你在 GitHub 上拿到別人的商用程式碼，請僅用於學習，並時刻保持低調。稍有不慎，有牢獄之災。

資料及資料製作工具

當我們需要資料的時候，就會考慮寫爬蟲。於是 GitHub 上充滿了各各樣的式爬蟲，除此還有得同學把爬蟲資料都放在上面了。某次，當我在玩 ElasticSearch 搜尋引擎的時候，突然需要一些真實的資料用來測試。便得找爬蟲，就在 GitHub 上，找到了大眾點評的一些爬蟲。

這個關鍵詞，就是： scrapy dianping.com，得來不費功夫。

除此，在 AI 相當流行的今天也是如此，也可以搜尋到其它同學訓練好的模型。

結論

試試你的 GitHub 搜尋功能吧。