如何給開源專案做貢獻

Super-Ps發表於2019-08-14

為什麼我會參與開源專案

從事測試工作以來,熟悉目前主流的 JavaScript 系,Python 系,以及 Java 系的各類測試框架,在實際專案落地過程中發現只是語法不一樣,提供的 API 的功能都大同小異,對於自定義的功能都有著同樣的侷限,需要擴充套件。隨著現在產品功能迭代加快對測試的快速驗證能力越來越高,從而需要有對測試框架有擴充套件功能和對整個持續交付,部署整合的能力。

正好我在公司負責落地不同維度的自動化實施,對比單元,介面而言 UI 的落地具有特殊性。因為我們的產品是基於 Electron 封裝的跨平臺應用,於是順手研究 Electron 並做了 Demo 發現本質上也是基於 Chrome 的,那當然是可以採用業界主流 SE 加上各種不同的測試驅動框架來完成,於是把當前能做 Electron 測試的找了個遍,只發現 Macaca 有這樣的功能,眼前一亮,一頓操作之後發現並不支援路勁引數,也就是調不起來應用,查閱了一下 Electron 官網在測試和除錯找到了 Spectron,WebDriverJs,WebdriverIO 三種不同的做法,其中就有 SE 支援的驅動庫 WebDriverJs,於是就開始做了....

技術棧與公司保持一致 (node),第一次嘗試:採用了 Mocha +Selenium-webdriver,除了依賴的驅動版本需要手動指定以外其他正常使用,相信使用過 SE 的同學都有個心煩的事,就是下載的驅動版本與 Chrome 的版本對不上,然後要去手動找版本,如果你本地更新了又得找版本,Macaca 也有同樣的問題,所以這是 1 個問題。雖然折騰 1 下也能用,但是發現用了測試框架那麼多種,在實際落地之後會發現為了滿足多端跨平臺的需求導致了測試框架種類多,形態各異,一聽就知道維護是個大問題,且對於新手來說學習成本較高,所以開始了第二次嘗試採用 Macaca 實現。但是之前也說過 Macaca 對 electron 應用支援不徹底,要是徹底支援 ElectronApp 就完美的解決了 UI 的全平臺支援了,而且隨著 JavaScript 各個端的發展 Electron 成為桌面解決方案的主流,當遇到基於 ElectronApp 的應用時,相信會有更多的測試同學跟我面臨一樣得問題。

所以,如果希望 Macaca 全面的支援 Electron,需要解決如下問題:1.將現有的 selenium-webdriver 整合在 Macaca 的依賴中,像安裝移動端,Web 端那樣簡單,不用再到處找解決方案,使得他們變成 1 個整體;2.解決自動下載對應的驅動版本,且支援不同平臺。明白了要做什麼之後剩下的就是解決問題,開始幹!

提起 pr 的過程描述

以 macaca-chromedriver 專案舉例:

  1. 先確認此專案還有人維護,不然浪費自己精力

  2. 檢查已經存在的 issues 和 pull requests,確保不要做別人已經在做的事情

  3. 找到專案 macaca-chromedriver 點選 Fork,在你的 Github 主頁也會存在此專案的複製,一定要先 Fork!我忽略了這一步,然後在坑裡蹲了一會...

  4. 將 macaca-chromedriver Fork 的專案本地 Clone; 我的是git clone https://github.com/Super-Ps/macaca-chromedriver.git

  5. 進入剛才 Clone 的 Macaca-chromedriver 專案,建立本地倉庫跟原始專案的的連結:git remote add upstream https://github.com/macacajs/macaca-chromedriver.git這樣可以隨時從原始專案 pull 最新的內容

  6. 檢視遠端倉庫列表此時應該有 2 個倉庫,一個你 Frok 的專案,一個原始的專案,我的是這樣的:

$ git remote -v
origin https://github.com/Super-Ps/macaca-chromedriver.git (fetch)
origin https://github.com/Super-Ps/macaca-chromedriver.git (push)
upstream https://github.com/macacajs/macaca-chromedriver.git (fetch)
upstream https://github.com/macacajs/macaca-chromedriver.git (push)

  1. 想好要修改檔案之前,先建立一個分支,且切換在該分支上 git checkout -b BRANCH_NAME

  2. 現在可以修改專案了,要清楚現在是在你自己 Fork 的專案上操作的,跟原始的專案沒暫時沒關係,所以自己 push 到 Fork 專案之前,要從原始專案拉 1 次最新程式碼,比如我這裡的遠端 upstream 倉庫 pull 最新的修改。

  3. 修改並提交完成之後,推送 git push origin BRANCH_NAME,這個分支名 是你 Fork 專案時建立的分支,現在是往 Forx 上 push,不是原始的倉庫。

  4. 現在可以 pull request 了,開啟你的 github Fork 的 macaca-chromedriver 專案 ,點選 new pull request ,可以檢視原始專案和你 Fork 專案的不同分支,檢視對比你修改的部分,如果你確定你的提交是沒有問題的,點選確定,等待作者的反饋

  5. 收尾工作,如果貢獻程式碼被採用合併了,或者被拒絕了,就可以刪除本地分支了: git branch -D BRANCH_NAME ,刪除 GitHub 上的分支: git push origin --delete BRANCH_NAME ,如果需要同步源專案程式碼到 Fork 專案 ,先把程式碼從源專案更新到最新 git pull upstream master 合併git merge upstream/master 再 push 到 Fork 專案上 git push origin master

總結

在 PR 過程中頻頻被拒絕的幾個問題以及反思:

問題 1

程式碼邏輯混亂,有雞肋,因為怕改動原有邏輯導致擴充套件寫的複雜且重複; 反思:需要深刻梳理你所修改的功能的整體性,保持程式碼簡潔,不能只顧實現而修修補補。

問題 2

let const var 不規範使用; 反思:加深對 JavaScript 規範不斷的熟悉。

問題 3

本地測試一頓提交,長如葫蘆串,還沒實際意義;反思:需要提交時做到有意義的提交,一個功能一個提交,便於其他維護者檢視。

當別人在看你寫的程式碼並給你指出問題的時候,總有那麼點不好意思或者很慌張,但是我們都知道這是一種成長,何況還是大神看你的程式碼,且先收起畏懼,並謙虛的接受並改正,勇敢的面對自己的不足。我跟很多人剛開始心態一樣,我們就用用別人的東西就好了,開源專案還看要看原始碼好難,麻煩,沒時間,沒決心,其實當你勇敢的前進第一步可能會信心倍增!激增你的興趣,學習了別人的思路,也提高了程式碼質量,拉開了與其他只會調 api 測試的距離,更重要的是幫助了更多的人。

接下來的計劃

目前只是完善了問題 2 的版本問題,還剩餘對 LIUNX ,WIN 的支援,還需要將 macaca-chromedriver 作為依賴 做成 1 個支援 Electron 的驅動。

完成 Electron App 方案的開發,給開源社群貢獻的同時能給有基於同樣需求的同學收益,希望有更多有開源精神的同學加入!

相關文章