對於每一個開發者而言,如果能擁有貢獻開放原始碼的經驗,具有許多面向的意義,像是基於工作需求、能力象徵、代表作品等,想從事這類活動,並沒有什麼形式上的規定,就算只是個簡單的寵物專案(可參考先前專欄〈你有寵物專案嗎?〉),或者是用個人自我想像的笨方式寫出的程式庫(參考〈笨方法寫程式庫〉),都是一種對開放原始碼的貢獻。

對開放原始碼做出貢獻,其實也是個逐步累積自信心的過程,而從某個時間點開始,你可能會想對著名的開放原始碼做出貢獻,雖然著名的開放原始碼專案,往往具有一定的規模,想要切入時,往往令人生畏,然而貢獻可以有多個方向,官方有時也會明列可協助的項目,最基本的或許是回報臭蟲、撰寫文件、協助翻譯,這也是累積自信心的另一個開始。

從plugin認識官方程式庫

如果開放原始碼程式庫,提供了plugin的方式來擴充功能,那麼,根據自身需求來撰寫plugin,會是個不錯的貢獻方向!

畢竟plugin開發可以從個人的專案開始,為了解決自身需求而存在,不用考慮太多的通用性,只要能與官方程式庫銜接,想要怎麼寫都可以,自由度相當高。

而且為了撰寫plugin,你必須更詳細地閱讀官方文件,或者探索官方原始碼,這會逐步加深對官方程式庫的認識,明白其架構及運作原理,知道有哪些專供開發時使用的API,在這過程中往往會發現,實現某個plugin需要的技巧,就藏在官方文件或原始碼之中。

現代開發者常會說「不要重新打造輪子」,然而,這並不表示不需要具備打造輪子的能力,也不表示不用去認識輪子的構造與原理,而開發plugin是個認識官方提供哪些輪子,以及熟練使用這些輪子的過程。

畢竟,的確不需要重新打造官方已經有的輪子,但是,你的plugin是新輪子,對於官方既有的輪子如果能夠有越多的認識,新輪子才能更適切地融入。

維護plugin專案

寫plugin本身是件很自由的事,可以是簡單寫寫,只要自己在使用上沒有問題就可以了;然而,隨著時間過去,你的plugin功能逐漸豐富、程式碼逐漸增長,在維護上開始出現些負擔,也許你的plugin公開了,使用者越來越多。

又或許從一開始,你就打算基於領域上的經驗,建構一個實用且完整的plugin專案,像是這類情況,我們就可以試著去架構專案,令其變得更易於使用及維護。

首先要做的第一件事是,為plugin寫文件。這不單只是寫篇README就好了,你的專案中應該要有個docs目錄,將不同功能寫在對應的各個文件檔;而且,寫文件除了告訴其他人如何使用plugin之外,也是重構程式碼前的依據;儘量為API寫些範例,如果你還沒為專案撰寫測試,這些範例是使用案例也是測試案例,是一種最低程度的測試,在我的經驗中,往往就是在撰寫文件的過程中找到臭蟲。

下一步是寫測試,可以自動化的那種程式碼。如果不知道怎麼開始,想想文件中的那些範例,如何能自動化地執行並確定結果正確與否,有時候這並不容易,特別是那些與畫面有關的範例。例如,我們畫出了一個模型,憑藉肉眼可以看出正確與否,那麼,若改成自動化處理時,要如何確定呢?也許取頂點、或者是邊、面數,甚至是角度等,不用想測試到多麼盡善盡美,而且,日後也還是需要維護測試程式的,或許到時還會有新的想法,現在先有基本測試最重要。

在你寫文件或測試的過程中,應該會產生一些想法,例如,為了更好闡述這個方法怎麼使用,最好是改一下名稱、調整一下參數;為了說明某個範例如何實現,最好是拆分某個函式,或整合某些API;為了能易於測試某些資料,某些流程抽取為函式,以便取得傳回值;為了將相近的功能組織在同一個測試流程中,或許,這些功能應該歸屬在同一模組或類別。

也就是說,重構需要有動機,而製作文件或測試程式是引發動機的一種方式,因為已經有了文件及測試作為後盾,就比較有信心進行重構,每次的重構,記得調整相對應的文件與測試,並且別忘了對專案進行版本控制,文件、測試、重構是不斷迭代進行的過程,在這個過程中,專案本身功能沒有任何新增,是常見的事情,這時要有耐心,畢竟這是你的個人專案,若是調整到可以往下個新功能發展時,再前進吧!

模仿官方專案

作為一個開放原始碼專案,其實,有個很重要的地方,那就是選擇一個合適的授權,這會讓人更放心地使用你的專案。

如果你從沒考量過這點,建議你認識一下基本的開放原始碼授權(可參考先前專欄〈多看一眼授權〉),如果真的不知道該選哪個,或沒有偏好哪個授權,那麼,就來看看官方程式庫會採用哪個授權吧!

寫plugin的好處之一就是這個,除了授權,官方程式庫還有許多可模仿的對象,例如,在文件方面,如果不知道該怎麼陳列API,那就看看官方怎麼陳列,文件中使用的字眼、行文風格等都可以模仿,這也可以認識官方程式庫的一些相關慣例。

從閱讀官方程式庫原始碼的過程中,除了能夠認識既有輪子的構造與原理之外,另一個好處就是,我們可以模仿函式、參數命名、程式碼流程的排版、註解的方式、類別或模組的組織方式,甚至是一些特別的做法。

例如,最近我忙著為CadQuery寫一個plugin,而CadQuery使用Python,其專案原始碼非常認真地使用了型態提示(Type hinting),為此我的plugin決定比照辦理,在公開API的原始碼函式簽署部份,全部加上了型態提示,有些時候不知道該如何標註型態時,官方原始碼總是能提供很好的參考。

雖說實作plugin很自由,不過,若是以模仿官方專案為目標,還有一個重要的部份,那就是遵從其典範,特別是領域相關的做法。

例如,CadQuery在模型的表示上,採用BREP(Boundary Representation),以點、線、面等作為基礎,其相互間的關係來描述模型;OpenSCAD則是基於CSG(Constructive Solid Geometry),模型是立方體、圓柱體、球點等基本物體布林操作後的結果。因此,如果想為CadQuery寫個plugin,仿造OpenSCAD風格,基本上是做得到的,不過,在風格上會完全迥異,效能上也不會有好的表現。

逐步累積信心與經驗

從事開放原始碼的貢獻,某些程度上就是個逐步累積信心與經驗的過程,簡單的寵物專案是個不錯的開始,如果目標是能對著名專案做出貢獻,那麼,plugin會是個很好的切入點,因為能有許多能學習、模仿的對象。

或許我在這方面比較笨拙一些,像是有時心裡會想這樣做可以嗎?然後看到官方也是類似做法時,自己實作起來就會比較有信心。

也許哪天plugin能獲得官方認可,或將某功能發PR給官方而被接受的話,那就是令人再高興也不過的一件事了!

專欄作者

熱門新聞

Advertisement