如何面對混亂的 Coding Guideline

不知道大家的團隊都是怎麼訂定 Coding Guideline 或 Team Convention 呢？
而它們是一進公司就已經存在的？還是在過程中慢慢打造出來的呢？

如果當已經存在的規範造成現在維護高成本、未來還可能創造混亂，你又會怎麼做呢？

我還不知道你怎麼想，不過接下來的故事是關於我如何做的。

混亂的規範與模糊的風格#

在過去，我有過從 0 到 1 打造團隊合作文化的經驗，也參與過調整既有規範的過程。
但沒有一次比這次讓我更刻骨銘心。為什麼呢？先讓我說點故事吧。

Onboarding 的流程結束後，身為工程師通常希望盡快展現自己的即戰力吧？
我也不例外。前幾次交付雖然順利，但在把 core logic 寫完後要 fit in coding guideline 時，卻讓我一頭霧水。

我不確定該怎麼切 boundary，也不知道怎麼讀文件才是明確的。
相近時期的 codebase 居然有不同寫作方式，讓我陷入混亂。

當你遇到這樣的狀況，你會怎麼做？

我一開始的心情是 A，後來進到 B，最後選擇了 C。
本章完。

並不是，讓我細細說明吧。

起初對 Coding Guideline 所提及的方向雖然不理解原因，但我需要展現專業能力並獲得信用，於是先接受現況。

接著，我逐步進行同事訪談，嘗試理解為什麼：

為什麼我們的 codebase 在同一個時期有不同的寫作風格？
是因為需求，還是因為修改前的 codebase 就長得太不一樣了呢？
如果遇到這樣的事，我們是否應該能分出一份心力在後續重構或是本身在實作擴充的階段就可以調整呢？

也問了為什麼我們的寫作風格是這樣呢？
背後的考量是以什麼為最高的指導原則呢？如果答案是擴充性，那麼在過去這部分是最重要的，那我們現在是否一樣這樣覺得應該以它為主呢？

在這個過程中，我發現其實團隊的大家都對於這些問題有自己的想法。有很好的討論曾在 review phase 提出，但沒有提高到團隊層級確認方向，還有一些有趣的團隊討論藏在過去的紀錄卻沒有定論。而這兩種情況之於我，都是一樣的。

因為：
review 只限於 reviewer 和 author，未參與的成員不會知道方向是否改變
沒有結論的團隊討論就像逛夜市，交流過後卻沒統整，沒有定錨

而對我來說，沒有共識，就是沒有產生可被執行的行為準則。
團隊因此無法有效共同打造我們想要的 codebase。

得出這個想法後，我找上 R（我的 Engineer Manager）確認目前團隊是否技術討論多但結論少。
當他確認這是現況後，我表示希望透過一次提案，示範我想要的流程與合作方式。

我選擇了一個簡單的提案做開場：恢復一個小的寫作風格規則。
我邀請大家回應並確認，統整意見後，設定了兩個 action items：

完成後，這個提案才算結束。

在提案順利完成後，我開了一個「提案的提案」討論，定義了四個階段：

提案：發現問題的背景、問題本身的研究、提案的方向及相關的 Sample Code
討論：常規的 RFC 流程，邀請團隊的所有成員參與討論，同意的話就直接 marked，不同意或是有建議的資訊則接續討論，提案人需要回應跟討論出能夠彼此同意的結論。
結論：提案人統整結論及 action items 後與團隊成員做最後確認，如果有異議則在這裡做覆核討論直到弭平。
行動：提案人需要為 action items 負責，也可以找有興趣的同事一起協作，是追蹤項目則由提案人負責。需要調整人力的話則再跟 EM 討論，行動完成後提案才能算完成。

看起來雖然有點繁瑣，但是意外的是當時的團隊大家也在後續提案時使用這樣的結構，讓每次的討論都能有的放矢，轉化成對公司跟團隊都健康的方式。

沒錯，我也還是不知道，因為探勘問題本身的研究、思考如何釐清問題的想法及透過流程化解決問題的方式，未來會成為我最主要的招牌特長，變成我踏上 Staff Engineer 前累積許多改變的原因。