前言
前兩天,我和一個8年python作業經驗的老程式員吃了頓晚飯,然后他給我分享了幾個GitHub開源專案的Tips,后來經過查閱網上的資料,整理成此文,本文主要包括開源專案的精確搜索,github專案原始碼的在線閱讀的技巧,跟蹤github熱門專案的趨勢動態,以及如何原始碼閱讀和在開源專案中做出貢獻的建議,

文章目錄
- 前言
- 1.關于開源專案的精準搜索
- 2.關于github上開源專案在線閱讀的技巧
- 3.關于如何跟蹤github熱門專案的動態趨勢的建議
- 4.關于如何閱讀github專案原始碼的建議
- 5.關于如何在github開源專案中做出貢獻的建議
1.關于開源專案的精準搜索
關于開源專案的精準搜索,通過更加細化的搜索條件,能夠更加精準地找到我們“心儀”的專案原始碼,下面是用法的總結:
| 用法 | 解釋 |
|---|---|
in:name xx | 搜索倉庫名稱包含"xx"的倉庫 |
in:description xx | 搜索倉庫描述包含"xx"的倉庫 |
in:readme xx | 搜索倉庫readme檔案包含"xx"的倉庫 |
fork/stars: >=3000 xx | 搜索倉庫fork/star數大于等于3000且與"xx"相關的倉庫 |
size:>=5000 xx | 搜索倉庫磁盤占用空間大于等于5000kB=5MB且與"xx"相關的倉庫 |
pushed:>2019-01-03 xx | 搜索倉庫更新時間在2019-01-03之后且與"xx"相關的倉庫 |
license:apache-2.0 xx | 搜索倉庫使用apache-2.0協議且與"xx"相關的倉庫 |
language:java xx | 搜索倉庫使用java編程語言且與"xx"相關的倉庫 |
user:joshlong xx | 搜索倉庫的用戶名稱為joshlong且與"xx"相關的倉庫 |
點擊這里->參考鏈接:你真的知道如何在 GitHub 上高效搜索開源專案嗎?
2.關于github上開源專案在線閱讀的技巧
就在你想要在線閱讀的倉庫的域名后添加"1s",一鍵開啟新世界的大門:


3.關于如何跟蹤github熱門專案的動態趨勢的建議
這里推薦一個近乎于完美的 GitHub 中文排行榜,在這里,所有優秀的高分專案都有,而且做出了排行! 關于該專案,作者是 kon9chunkit,GitHub 中文排行榜,幫助你發現高分優秀中文專案、更高效地吸收國人的優秀經驗成果;榜單每周更新一次,敬請關注!

點這里->GitHub中文排行榜
跟蹤優質的github開源專案的站點推薦ヽ(?ω?,)ノ,向下看↓,
| 站點名稱及鏈接 | 相關介紹 |
|---|---|
| GitHub Trending | 是來自于 GitHub 官方的專案趨勢串列,一些 Star 增長比較快的專案會在這里出現,開發者可以針對不同編程語言進行過濾篩選,是個挖掘優質專案的好渠道, |
| GitHub Topic | GitHub 正在慢慢優化專案的資訊分類,讓一些優質開源專案得到更有針對性的推送,早期大部分開發者都是 Trending 或關注的人的動態來了解一些開源專案,但這樣的曝光量顯然對一個新啟動的開源專案不太友好,因此后續 GitHub 應該會推出一些更為豐富的渠道,讓大家可以更好的挖掘一些優質的開源專案, |
| Hack News | 技術人常逛的一個網站,著名 YC 創始人 Paul Graham 搞的,也是不少優質開源專案的起源地,不少開發者會時常上去推薦自己的開源專案,說不定你現在在用的某個開源專案,可能一開始就是通過這個渠道被人知曉,然后慢慢發展壯大的, |
| Changelog | 這個渠道可能知道的人相對來說會少一些,但是質量卻很高,很多開源專案在不為人知的時候就已經有出現在這里了,Changelog 的 nightly 郵件我訂閱了多年,有時閑著無事我就會去挨個翻出來看一看, |
| 這里免不了還是要談到 Reddit 這個大雜燴網站,上面的 opensource 主題也有不少優秀的開源專案,但是因為 Reddit 上面主題繁多,其本身也不是針對開發者的垂直網站,因此更新的頻率會低一些, | |
| Git Hunt | 一個開源的 Chrome 插件,把你 Chrome 的 Tab 頁轉為 GitHub 開源專案的推薦頁,我是這個插件的重度用戶,裝了好幾年,從來沒卸載過,自認為是開發者必裝瀏覽器插件之一,有時候用 Chrome 搜東西的時候,?+T 常常會給我意向不到的驚喜, |
點這里->參考鏈接:我是如何發現優質開源項 目的?
4.關于如何閱讀github專案原始碼的建議
Tips—1:寫注解
寫注解是在閱讀代碼中最重要的一個步驟,在我們閱讀的源代碼一般來說是我們不熟悉的系統,閱讀別人的代碼一般會有幾個問題:
搞明白別人的編程思想不是一件很容易的事情,即使你知道這段程式的思路的時候也是一樣,閱讀代碼的時候代碼量一般會比較大,如果不及時寫注解往往會造成讀明白了后邊忘了前邊的 現象,閱讀代碼的時候難免會出現理解錯誤,如果沒有及時的寫注解很難及時的發現這些錯誤,不寫注解有時候你發生你很難確定一個函式你時候閱讀過,它的功能是什么,經常會發生重復閱讀、理解的現象,
寫注解的核心思想如下:
- 猜測的去寫,剛開始閱讀一個代碼的時候,你很難一下子就確定所有的函式的功能,不妨采用猜測的方法去寫注解, 根據函式的名字、位置寫一個大致的注解,隨著對專案原始碼的深入理解,不斷地調整注解,
- 在核心代碼段要寫較為詳細的注解,有一些函式或類在程式中起關鍵的作用,那么要寫比較詳細的注解,這樣對你理解代碼有很大的幫助,
Tips—2:學會重復閱讀
- 一次就可以將所有的代碼都閱讀明白的人是沒有的,至少我還沒有遇到過, 反復的去閱讀同一段代碼有助于得代碼的理解, 一般來說,
在第一次閱讀代碼的時候 你可以跳過很多一時不明白的代碼段,只寫一些簡單的注解,在以后的重復閱讀程序用,你對代碼的理解會比上一次理解的更深刻,這樣你可以修改那些注解錯誤的地方和上一次沒有理解的對方,一般來說,對代碼閱讀3,4次基本可以理解代碼的含義和作用,
Tips—3:運行并修改代碼
- 如果你的代碼是可運行的,那么先讓它運行起來,用單步跟蹤的方法來閱讀代碼,會提高你的代碼速度, 代碼通過看中間變數了解代碼的含義,而且對 以后的修改會提供很大的幫助,關于如何進行斷點除錯,請參考這篇博文:全網最實用的 Debug除錯技巧匯總,以及這篇博文:Pycharm教程–斷點除錯,
- 用自己的代碼代替原有代碼,驗證自己的猜想,但在之前要保留源代碼, 600行的一個函式,閱讀起來很困難,編程的人不是一個好的習慣,在閱讀這個代碼的時候將代碼進行修改,變成了14個函式(每一個大約是40-50 行左右),
點這里->參考鏈接:如何有效閱讀Github上開源專案代碼?
5.關于如何在github開源專案中做出貢獻的建議
如何找到那個你想貢獻的專案?
在面對開源專案時,先端正態度,
要參與到開源,就必須成為那個能發現或解決問題的人, 找到那個你感興趣的專案,從點滴小事做起,修復檔案的無效鏈接和錯別字是參與開源,發現問題并詳述、復現問題也是參與開源,
28% 的貢獻作業
來源于對專案檔案的優化,如更正錯別字、優化排版、提交翻譯,
當你這樣->
“這專案有個地方錯誤處理沒寫好,我看看代碼...嗯,就是個智障問題,順手PR一波…”
“這專案怎么連Xxx都不支持…我看看咋整…嗯,做出來了,順手PR一下…”
“你這專案怎么不開源?不開源就是原罪啊!所有專案都應該AGPLv3!所有人都應該加入FSF,給自由軟體打錢”
然后,繼續保持前面那種精神,再加上『不重復造輪子所以盡量用開源社區寫好的代碼』,多寫代碼,你應該就能變成一個優秀的貢獻者,
除此之外,你可以通過下面的這些渠道,來發現你感興趣開源專案,
- GitHub Explore
- Open Source Friday
- First Timers Only
- CodeTriage
- 24 Pull Requests
- Up For Grabs
- Contributor-ninja
- First Contributions
如何提交貢獻?
為了更加高效的溝通與合作,請確保在你進行提問或提交 PR 的時候,做到了以下幾點:
給定背景關系,別沒頭沒尾提前做好準備作業提前閱讀相關檔案與資料說話簡明扼要盡量讓溝通資訊公開透明提問時請保持耐心尊重社區的決定最重要的是,保持高雅
做到上面幾點后,你還需要搜索專案 issue、README、stackoverflow 等渠道,確保問題未被其它人修復,最好,通過以下幾種方式來提交貢獻:
GitHub issue - 發起提問,進行討論GitHub pull request - 提交解決方案其它渠道 - Stack Overflow、IRC、Slack
提問的時候,為了減少雙方溝通的時間,請使用最為高效直接的提問方式,推薦閱讀:點這里->參考鏈接:提問的智慧
在你參與貢獻之后
每個人在一開始參與貢獻時,內心都較為忐忑,一般在你參與貢獻后,會發生以下幾種情況:
1)沒有得到任何反饋
首先,確保你提前核對過專案的各種情況,具體可查看該 核對清單,
如果一切都正常,可在一周后嘗試聯系專案相關人員,詢問具體情況,
2)有人更改了你的貢獻
在你得到相關通知后,出于禮貌與高效溝通,請及時給出反饋,因為他人可能花了不少時間來審核你的問題 / 代碼,然后發起的更改提交,
如果你沒有時間處理他人提交的更改,也請提前告知提交者與專案維護人員,找到一個可以接手并處理該問題的人,
3)你的貢獻未被接受
這種情況很正常,一般作者也都會說明未被接受的具體原因,如果沒有,可以在專案的相關討論帖下詢問作者具體原因,
4)你的貢獻被接受了
恭喜你,你作出的貢獻真真切切幫到了其他人,希望后面接著堅持,請記住,千里之行始于足下,
點這里->參考鏈接:如何在GitHub上做一個優秀的貢獻者?
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/286233.html
標籤:其他
上一篇:不正經的摩爾莊園小游戲!
下一篇:爆肝!回呼函式的實用案例,建議收藏~(計算器改良,qsort快排函式應用實體,冒泡函式核心理解,模擬qsort函式)
