接續前兩日聊到的，今天更多是在聊導入的經歷帶給我的學習。這三篇算是為我的在前公司不斷改善流程與文化的經歷的學習紀錄吧。

經歷

如同我在實驗室做的，剛到前公司時，當我發現沒有 Code Review 文化時，我又開始嘗試了導入 Code Review 作為嘗試改變的第一步。Code Review 幾乎是我的起手式了，這是一個小的改變，卻能為程式碼品質以及知識傳遞帶來良好的效果，更能因此為團隊建立改變的信心。

因為我有導入過 Code Review，所以團隊也很樂於聽我的經驗。但在開始要討論是否要實施時，讓我沒有預料到的是引發了滿長的討論——大家開始針對 Code Review 的標準進行探討。

事實是，有幾位同事在 Code Review 上是有不好的經驗。包括 Merge Request 為了等 Code Review 完成，從提出到合併拖了三到五天才完成、或是在 Code Reveiw 的過程中，不斷的被提出程式碼風格、變數命名、或是寫法不好看，但是真正重要的商業邏輯與程式架構功能卻沒有顧到，借用這位同事的原話：

瞭解一個產品應該先了解他的操作流程再看程式碼。（該說是宏觀 -> 微觀嗎）
團隊的成員先懂得操作自己的產品之後，我們面對功能提交是不是也該先測試功能的正確性，然後再來建議細節的語法構成。

我只是覺得這樣的流程至少我們可以先專注在當下功能的完整性。
比方說，我們在與人交談時，應該先著重在溝通解決事情，而不是逐字檢視對方的文法一樣。除非對方說話根本狗屁不通。

接著我們耗費了不少時間在進行討論，包括嘗試解決以前有不好經驗同事的顧慮、釐清 Code Review 到底要到什麼程度等等。最後終於定調：只要第二個人能讀懂這份變動，且對於邏輯上沒有認為有錯誤狀況，就可以了。終於，我們定出了我們的第一個技術上的改變行動：「要變更開發分支的程式碼，要有第二人看過變動的差異並認可。」

學習

這件事讓我意識到，一個過去經驗上感覺再好的政策，可能在其他人身上存在的不好的經驗。如果沒去暸解每個人對一個政策的看法，就貿然強制執行，一來可能會讓那些人不舒服且不願意執行，二來可能會忽略他們經驗中寶貴的觀點，失去我們一開始可以讓這件事更好得機會。

所以，我在此之後分享了一個主題時，更喜歡和大家一起討論這件事在執行上會有什麼顧慮，我們該如何去解決這些顧慮，以更適合我們的狀況去實踐。