編修 2020-09-05：將標題從「初探」改為「再探」

這篇原本是沒有在我的綱要裡，因為這段經歷其實不長，不過兩個月左右。但我想卻也是改變我很多的一段經歷，所以想起來後就決定今天寫出來。

轉換跑道

昨日提到我「轉向軟體工程領域深究」，會用「轉向」這個詞是因為我不是資工相關科系出身的，而且還是與工程無關的文學院科系——歷史系。所以我的軟體開發經驗是從高中社團一路累積過來的，從維護高中的 BBS 站、到為大學圖書館寫程式、再為社團去寫學生相關的網路應用程式。儘管我對於程式的自我要求高，會注重 Git 的提交訊息、程式碼的風格、追求簡潔。但對於合作這件事，正如昨日所言，是個初心者，什麼都不懂。

敏捷實踐

所以我大學畢業後，就去了一家做餐券與訂位的新創公司實習。憑藉當時對 PHP 的熟悉，我進到了這家公司開發後端程式的團隊。在這邊我想算是我的第一次敏捷開發實踐，當時可能不懂，但是回憶起來才發現團隊每天都有站立會議。每天某個時間，大家到一間玻璃牆組成的小會議室，站著講述昨天到今天做了什麼，並且互相交流。事實上我不確定這家公司當時有沒有導入什麼敏捷開發方法，畢竟身為實習生接觸的不多，但至少站立會議是有深刻印象的。

儘管有接觸到每日站會，但事實上這段經歷影響我最多的反而是在技術上的實踐，尤其是版本控制相關，尤其是出社會來到業界後，我才發現到這裡注重版本控制的難得。

專業版本控制的追求

每段程式碼的改動，都必須提出 Merge Request，並且由另一位同事 Code Review 後，才可以合併回主線。但是這裡不只檢視程式碼而已，連 Commit Log 都十分重視，會要求每個 MR 都透過 Git Rebase編修紀錄過，讓這份變動的 log 是易讀的。在確認程式碼都沒問題、且 log 都能呈現修改的部分時，最後才會留言「LGTM」(Look Good to Me）並將那份變動合併為主線。

這個標準至今仍深深焊在我的軟體開發原則中，我認為這是一種專業的展現，我透過編修程式碼紀錄，確保我知道每一次提交是為了什麼、我清楚知道我變動過哪部分的程式碼、也檢查過這些變動是和提交的訊息相關的、這些變動都和我這次要改動程式碼的目的相符、我也期望我的同事能直接透過這些 log 暸解我的變動。這是軟體開發工程師負責任的展現、是一種美。

而透過這樣 Code Review 的過程，也是一種同事之間對彼此程式碼暸解的交換。不只程式碼的理解程度，更重要是的在檢視時提出的建議或是直接指出瑕疵，都有助於彼此教學相長，而成為更好的程式設計師。在敏捷開發裡，我們期望團隊是 cross-functional 的，也期望不會有一份知識只有一個人知道、讓那個人成為瓶頸，所以這樣的知識交換是一個很重要的環節。

我也是在這間公司練就解 conflict 的勇氣與能力，對我來說解 conflict 就像是解謎、推理一樣，有耐心就可以把它糾纏在一起的繩結通通解開，是非常有成就感的事情，我也對自己能夠將程式碼的變動與記錄訊息保持整潔感到驕傲。

我自己會認為版本控制是 DevOps 在技術上的基礎，需要先有好的版本控制、才能有好的流程去觸發每一次的自動化、才能有一個穩定且流暢的 CI/CD。所以我十分注重現在主流版本控制工具 —— Git 的能力，我認為如果團隊的工程師對於 Git 都不熟悉，那就很難讓軟體開發這件事敏捷起來。

我想這也是這段經歷帶給我的深遠影響，我也是在之後不斷精進 Git 能力與對自己的標準，也樂於將這些知識分享給之後的工作環境。

初探 DevOps？

除了 Git 之外，其實在這間公司實習的後一個月的某種學習，也是影響深遠。那究竟是什麼呢？就讓我們明天分曉吧！