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