前兩天提到的是我在實習期間的故事，這兩天則要講講在就讀碩士兩年間的三個故事。實習結束後，就此展開了碩士生的實驗室生活。
俗話說的好：「程式設計師的美德就是懶惰。」因為懶惰就會把把重複性的工作給自動化，進而推動社會的進步（？）。
我認為這在喜愛敏捷文化與 DevOps 文化更應是如此，只有將重複性的事情自動化，我們才有額外的時間與精力去追求適應變化的能力；只有將整合與部署的流程自動化，我們才能持續的交付。
而我在實驗室所做的第一件事情，就是將實驗室軟體的安裝流程從手動複製檔案與改環境變數，透過 NSIS 腳本自動化，省去我們要舟車勞頓的去客戶辦公室、在沒有網際網路的環境下，協助因為安裝程序太複雜無法自行操作的客戶，用 USB 進行檔案複製與各種環境設定去安裝我們最新版本的應用程式。在有了自動安裝程式之後，只要透過 e-mail 就可以將新版安裝程式交付給客戶自己安裝，更快的得到他們對應用程式的回饋。
這樣降低交付耗損的時間，是 DevOps 所追求的；而快速得到回饋的節奏，也是敏捷文化所追求的。
實驗室在文化塑造最困難的地方在於，每一年多承接專案的人員就會進行一次交替；換個說法，就像是公司每年都一定會有 N 個最資深的員工離開，然後同時再來 N 個新員工進來。在這樣來來去去的環境中，文化是最難建立、也最容易遺失與稀釋的。
而開始承接實驗室專案後，我就感到實習時良好開發文化與實驗室開發文化強烈的反差對比。其中，我最難以接受的就是沒有一個共通的 Coding Stlye 以及沒有 Code Review 的文化。
沒有共通的 Coding Style，||除了強迫正如我會感到渾身渾身不對勁外，也|| 會造成程式碼可讀性降低，讓更改軟體本身的成本提高。而沒有 Code Review 的文化，就會讓許多劣質的程式碼合併進主線造成技術債、也會有造成專案建置失敗的提交讓開發進度停擺。這些缺陷都是降低從需求到交付的絆腳石。
另外，沒有 Code Review 更長遠的後果就是知識傳承的成本會不斷積累。正如前面所提到的，實驗室最大的困境就是人員更迭頻繁，所以知識的傳遞容易斷層。所以指導教授努力的想要研發更好的文件專寫方式與 IDE 相關輔助擴充套件。但是這些都是治標不治本。
但是會造成斷層的原因，更主要是專案的知識總是在人員要離開時才交接，而那時候正是離開人員於論文水深火熱之際，而論文寫完後也就急急忙忙地辦理離校手續而離開了，實際能好好交接的時間與精力是難以將這些知識完整的傳遞的。
而這就顯得平時的 Code Review 是重要的。每一次合併主線前的 Code Review，除了前述有避免劣質程式碼與缺陷進入主線的優點外，更有知識傳遞的效果。資深開發者透過 Code Review，讓新手暸解到自己可以更好的地方。而新手透過 Code Review，去更近一步暸解軟體的架構與概念。任何專案成員，都可以透過 Code Review開啟更多的討論、激盪更多的想法。經過這樣一年的開發，等新人成長起來、資深者要離開前，其實真正需要交接的地方已經不多了，如此就可以避免知識的斷層。
不過當時的我其實不一定有意識到這麼多。只是一昧認為在前一份工作環境習得的 Code Review 文化是真的有幫助，所以想要去建立這樣的文化。然而，學長們在已有既定文化的認知與在開始要忙論文的當下，是反對這樣的方式，所以在學長畢業前，我都沒有成功說服過。
到了學長即將畢業之際，新的學弟妹提前加入實驗室，我就決定從他們開始建立起這樣的文化。也時值在我們這一屆，專案的版本控制方式從 SVN 轉移到 Git，也建立起實驗室的 GitLab，所以我們就一起建立了 Code Review 文化，讓程式碼變動合併到主線前，必須透過 Merge Request 的方式，然後由至少一人去 Code Review，在暸解與認同後才能合併到主線。
時隔畢業數年，有天在實驗室學生的 Telegram 群組中，有學弟發問：「考古一下，當初ＯＯＯ專案會帶 code review 是哪個偉大的學長/姐帶頭阿？」開啟了對話，才知道這樣的 Code Review 文化是有不斷傳承的，也仍然是實驗室專案中，唯一一個有在 Code Review 的專案小組。而學弟也認為這樣的文化是很有幫助的，該專案也是實驗室後來少數發展不錯的（儘管成功應該不會只是因為有 Code Review）。
這件事時隔多年回想起來，不禁讓我連結起了軟體開發宣言：
個體與互動 重於 流程與工具
我認為 Code Review 就是一個創造「互動」的機會。
今天其實本來重點是要聊這個的，但沒想到一聊起 Code Review 就佔了大把時間與篇幅。上面兩個故事講得是我成功的經歷，而之後來要聊的就是一個失敗的經歷，就讓我們明天一起聊聊這個故事吧～
iThome鐵人賽
看影片追技術