昨天大女兒早上去學校、下午去上美語、晚上去游泳，回來已經很累很晚了，一直猛打哈欠。在去游泳之前，已經讓她先把學校作業寫完了。
睡覺前收拾書包時，太太檢查她新的國字（硬體字筆畫）作業寫得怎樣，因為是第一次練，當時寫作業又蠻趕時間的，又沒大人在旁一起看，所以蠻多內容寫得只是有形狀，但很多細節都不對（很有即視感吧）。
此時我癱在按摩椅上，聽著太太跟女兒隔著餐桌坐在對面的對話。
太太：「你覺得你寫得跟上面的字有一樣嗎？」
女兒：「一樣啊！」
太太：「有嗎？你仔細看看」
女兒：「一樣啊…」
太太：「你那個字最後那邊勾了起來，上面的字有勾起來嗎？」
女兒：「我沒有勾起來啊…」
聽著這段對話，我的腦袋浮現一些軟體開發過程常見的場景…所以我正瞅著何時去摻一腳。
接著大概連續10次，女兒寫了字，太太只說著問題在哪，女兒擦掉，再寫一次，還是一樣的問題，不斷 repeat。
她一直在打哈欠，因為一天上三種課，從早到晚真的很累，而且之前有約定過要避免這樣上課。為了避免她在根本不知道怎麼寫才會「對」的無限循環中崩潰，我決定起身。
將她們從 code review 的形式，
改成 pair programming。
我：「怎麼啦，唷，你開始練習寫國字啦」
女兒：（嘟著嘴巴，含著眼淚，沒力氣跟心情多說一句話，繼續不情願地把她寫的字擦掉）
我走到她的身後，伸出兩隻手環著她。
我：「我來看看是哪個字，哇，這筆畫也太特別了點，你這後面好像往上翹了」
（我刻意不用勾的字眼，因為他們剛剛才吵過這件事）
我：「要不爸爸負責幫你用橡皮擦，你再寫一次我看看會不會就好了。」
擦掉之後，她再寫了一次，還是歪歪的。我問她：「嗯，這邊還是有點問題，你覺得呢？要不要爸爸再幫你擦掉？」
她仍然沒講話的點點頭。（她處女座的完美主義）
我再擦掉之後，跟她說，爸爸握著你的手一起寫。
接著我就在後面握著她的手，告訴她另一隻手壓著本子，我們一起寫了那個字（估計此時對面的老婆應該要很羨慕嫉妒渴望才是，但我無暇理會她的眼神，我現在要專心跟女兒寫作業）。
結果我們一起寫的字還是歪七扭八。
我告訴她：「這真的不簡單，要不換爸爸試試寫寫看。」
我把字擦掉，寫了一遍。醜醜的，再擦掉，再寫了一遍，還是不到位。我笑了笑道：「這真的要寫漂亮沒那麼容易。」
女兒聽了，說著她要自己練習寫。我幫她擦掉字之後，她照著上面的字描了一遍，再到格子裡練習一遍，終於通過媽媽的標準了。
昨晚的例子就到這邊終了。
很多目前軟體產品開發還蠻上軌道的客戶，他們現在碰到的瓶頸是在 code review。
要嘛 review 容易變成瓶頸、要嘛因為瓶頸導致時間緊迫而淪為橡皮圖章的形式，又或者只是看看 code diff 之間的差異、寫法有沒問題，只能指出寫得「好不好」，而無法確認寫得「對不對」。
「先落實 code review，形成瓶頸之後再嘗試用 pair programming 解決」
我經常這樣建議那些覺得該 code review 但覺得 pair 不實際或是有抗拒的團隊。
code review 就像稽核，常見有幾個特點：
- 稽核沒過，代表沒完成，不給過關的。
- 稽核人員跟開發人員的目標不完全一致，稽核人員更偏重於把關，尤其是品質。而開發人員最大壓力來自於時程。
- 稽核是落後指標，發現問題時間點越晚，修復成本越高。加上責任落在要扛時程的開發人員，往往來來回回壓力會越來越重，要嘛心情受影響，要嘛放掉品質受影響。
- 離線（非面對面）斷點式的往返（context switch)，大部分工程師傾向在線上留下 review comments, 而不是坐在一起面對面溝通，哪邊寫法有問題，了解作者的考量是什麼，我們怎麼達成一致的共識後交付。對雙方來說，這樣多次斷點式往返，只依賴 comments 上的文字描述，會有許多誤解、中斷、等待的浪費。
這很像甲乙方的驗收方式，只是都是團隊內的工程師罷了。
我們整體最終目標（也該是共同目標）應該是：「在時程內有品質地交付我們倆有共識的程式碼。」
所以建議大家從這種傳統線上的 code diff review，線上 comments，來來回回後允許 merge 的形式，改成 reviewer 要 review 時跟作者約個時間，帶著電腦坐在一起，照著 reviewer 對需求的瞭解，以及 reviewer 自己的思路，去看跟作者設計、寫法不一致的地方（前面已經過了共同的 refinement, 驗收情境, planning part2，再從 test case 出發來看整體產品程式碼的設計），進行瞭解與討論，雙方持續有共識地一起修改調整，最後兩人一起完成這段 feature final commit，然後 merge 回 trunk。
By the way，我通常建議 reviewer 主導這個過程，以 reviewer 思路往下推進，而不是讓作者自己先描述作法跟思路。一來避免錨定效應，二來實務上看 code 的人不會聽到作者解釋和說明，得試著在沒有作者解說下，讀者能用最短時間、最少腦力、正確地理解程式碼的意圖。
兩人一起承擔時間、品質、對程式碼有共同理解的責任，只是這次擔任的角色不同而已。當下雙方都專心的完成這個共同的任務與目標。
先從 review 練習 pair，熟悉了之後他們就會覺得那一開始就 pair 不就可以更早發現問題了嗎？
再搭配 scrum 那種非派工而是 value-first 領工作的方式，再配合 向上 pair 的原則，團隊內 pair programming 是一件再正常不過的事了，通常也是效果最好，產出最高，但也最累的開發方式。
更別說 as a team 學習型組織、互補、增加公車指數、避免破窗、共同制定/調整規範、避免盲點、避免過度設計等等好處。
code 只要是一個人寫，沒別人看，永遠都是自己會改的那種「養 code 自重」的形式，裡面藏污納垢的程度會遠超過想像。
搞產品的只要出現那種特定模組永遠都只有特定人維護，基本上死期不遠，而且這情況拖越久越沒辦法，慎之慎之。
Reference
- 菜鳥養成策略－Pair Programming
- 結對程設指南
- 培訓時我們也都會建議以 pair 的形式上課，通常效果會比一般的方式好。
- 熱血 Coding Dojo – 202103 (台北)
