[雜談] 程式專案的一人負責與多人協作

之前的工作模式偏向個人負責一個專案或一個完整的功能，跟別人的互動主要是確認需求、處理反饋。現在的工作參與專案的規模則大上許多，一個元件或功能會由不同人接手，模式跟以往大不相同。這兩個月因為專案上線，所以從系統架構的工作轉去支援功能的維護。這段時間體驗到許多觀念衝擊，就在思考為什麼會如此適應不良。

差別

我想這兩者最大的差別就是需不需要去改變自己的工作模式。跟不同領域的人合作時（如企劃與美術），主要專注在功能的規格上，至於要如何在程式上實現，則可以依自己習慣的方式去完成。但如果是跟同是程式的人合作的話，尤其參與時專案已經進行一陣子了，就得要依循既有的工作模式了。

自己做可以不受限制，但多人協作就得配合他人了

如果有特別規定，則還可以依循規定去調整工作模式，像是縮排用 tab 還是 space、類別框架、分支命名等。但如果沒有的話，就得要照著前人的 coding style 去撰寫，配合這些「潛規則」。像是覺得用 switch-case 做條件判定比較好，但如果前人已經用一連串的 if-else 來判定，就只能再加新的 else 上去。或是因為習慣用垂直分割一次看兩份程式碼，因此設定在 80 字元後會換行，但原本程式碼在 120 字元才換行，甚至一行寫到底的話，較短的換行就會顯得突兀。

不同的 coding style 會讓程式碼不協調

如果為了 coding style 去改別人的程式碼，則可能會讓責任到自己身上。因為功能出錯時，會先找最近一次的 commit 者是誰。而且專案已經運作一陣子的話，改動功能正常的地方，可能會有風險。

溝通

但也不是就此束手無策，還是可以透過溝通來改善這樣的情況。像是推薦工具外掛來改善程式碼排版，例如可以在存檔時把行尾空白去除的 Trailing Whitespace Visualizer，還有顯示換行字元位置的 Editor Guidelines，最後設定換行區間在 80 到 120 字元。再進一步的話，也可以導入 lint 工具跟 git hook，來統一 coding style。

雖然現在還處在適應轉換期，確實因為觀點不同帶來蠻大的低潮，而且要習慣不同的 coding style 還要一段時間。但也趁著這次機會，來嘗試推薦自己認為比較好的寫法，也希望可以進一步改善專案的品質。