前言
只要是軟體工程師這個領域內的職業都一定需要經營自己的side project
side project等於自己的職涯作品集，應徵時絕對會需要拿出來展示的項目
以前寫過一篇關於生物資訊工程師要經營side project可以往哪些方向
其中一個方向就是Pull request
生物資訊的side project其實 side project 做到後來會感受到除非自己是大神或寫的專案有發表
不然就只是做爽的，根本不會有人用你的工具
還不如去那些 Star 很多的專案，看可以增加功能或是修復 bug
作者 merge 你的 commit 的話以後跟面試官提你在這個專案有貢獻對於應徵還比較有幫助
你的知名度也會寄生在作者下曝光
看來當時的我就覺得自己寫side project一定有極限
如今我更感受到極限差不多已經到來了
自己在那邊想有趣的主題自己寫，到最後確實也都是自爽而已
不如就追星還比較有意義
這篇就來分享我的Pull request(PR)經驗與心得
適合PR的專案
要PR首先要找到合適的專案貢獻吧
我自己看下來整理了以下大原則
專案主要的程式語言是自己熟悉的
以我自己的經歷來說，熟悉的領域的二三代定序資料分析
最熟悉的程式語言是Python，所以就找是用Python為主開發的生資工具
常用的工具且自己又熟悉的舉幾個例子有Flye, DFAST, eggnog-mapper, rgi
不知道要找哪個專案可以到Github Explore探索
e.g. https://github.com/topics/bioinformatics?l=python&o=desc&s=updated作者的最近commit是三個月內
這指標是評估該專案的團隊發表之後還有沒有繼續維護，
太久都沒有commit表示這個工具已經完美或是荒廢，不管是哪種都沒有貢獻的意義了
像是Prokka在2020年之後就沒在commit，
2014年發表過了6年的確是近乎完美，不需要再更新了
- 有merge過外人PR的案例
不一定開源專案的團隊就會接受外人的PR，所以即使看到有PR的案例也要看接受PR的人是不是他們自己人
不然自己花心力提交PR他們也不會接受的
如何PR
要PR首先得要找issue，就跟規劃軟體開發項目一樣
我就不說明PR的操作流程了，網路上一堆，fork -> commit -> PR …
看issues別人提出的bug或許願的feature
通常都會從issue trackers看別人有提出哪些issue
bug類的通常比較容易，而且提交修復bug的PR被作者同意merge的機會也比較高
新增功能的PR，如果作者不想要這種功能或有其他擔憂就會不merge了自己使用後想改善的程式碼
這種的話就是自己本身就是該工具的常用使用者吧
有種恨鐵不成鋼的情感，為什麼會沒有這種功能?某個bug一直不修復!
最近親身的案例是RGI的使用經驗
RGI是比對抗藥基因的工具，但rgi bwt (mapping reads to CARD)的平行化處理都會卡很久
問題也不是很難但就是一直沒有優化，所以我就提交改善的程式碼 (https://github.com/arpcard/rgi/pull/254)
PR相較自己寫side project可以學到什麼
總結來說是可以學習將心比心，為他人著想
了解別人的程式碼撰寫邏輯與架構
要提交程式碼前需要先了解該團隊的撰寫風格和程式碼架構
在寫PR的程式碼時應該要遵循團隊的習慣
像是函式都是用snake_case還是CamelCase，先看過人家寫的程式碼再撰寫
盡量跟他們一致commit一次處理一件事
只有自己寫程式，版控時的commit可能都是寫了一堆功能然後一次commit
commit的message可能還都寫的很隨性，像是bugfix，然後就沒有了
應該要一個PR盡量只處理一件事情，這樣作者在code review時也比較好判讀
或是他可以接受你的一個commit但另一個不接受
雖然不是不能只merge其中一個commit，但就是要多花心力去幫你修改
更慘的是如果是多個功能寫在同個commit時就更麻煩
最簡單的情況應該是一個commit就是一個PR解釋自己程式碼
PR時都會需要寫一段敘述解釋自己為何要提交這個PR
如果可以的話最好附上測試的資料與結果
以上面提到的RGI的例子來說，我解釋我是怎麽解決程式會卡住的問題
解決方案為更換平行化的套件和預先存取檔案至dictionary，避免反覆讀取
並附上測試的資料集，且說明改善前後的執行時間大幅縮短
結語
以前精進自己的策略是對什麼技術感興趣就針對該技術想一個side project，然後實踐出來
但技術是學不完的，作出一堆side project，雖然可以讓自己學到更多技術
不過對於生物資訊的貢獻其實近乎為零
不如多多去PR厲害的團隊開發的工具還更有貢獻
這些的前提是在某些領域需要足夠精通才行，否則應該連bug都找不到在哪呢
因此最近的我想改變精進自己的策略，開始實踐Pull Request這個另類的side project
