【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自重 的形式，裡面真的會比「長麵筋」還藏污納垢的....
搞產品的只要那種永遠特定模組都只有特定人維護，基本上死期不遠，腐敗發臭速度超乎想像，拖越久越沒辦法，慎之慎之。
#敏捷人生
scrum好處 在 Re: [討論] Scrum Master是什麼樣的工作? - 看板Tech_Job 的八卦
我待過兩間公司跑 Scrum，只有最近的一間有明確感受到 Scrum Master
Scrum 團隊組成為三種成員
1. Product Owner (連長)
2. Developer (士官、士兵們)
3. Scrum Master (輔導長)
反正老闆/客戶的任務目標下來，連長要自己想辦法帶部隊攻下，用什麼辦法看連長自己
PO 有很高的權力去設計產品，開發者們也能在 planning 會議中提供意見
在一個不長的週期內做出來給老闆或客戶看，再開會調整，再改善...
不像傳統 PM 按照老闆的目標設計規範開規格書然後 RD 想辦法做出來那種流程
Scrum 團隊最好是成員對產品都有一定的了解和想法，然後也有能力實際做出來
而 Scrum Master 其實跟技術專業沒有絕對關係，但有技術專業的好處後面會講
Scrum Master 就是個輔導長，負責監督連長和士兵們有沒有按照部隊規定做事
有沒有誰違反了軍法 (早五查 daily scrum 沒出現、Retrospective 開士評會檢討)
開發過程中有內部或外部衝突時負責出來居中協調確認改變作法後可符合 scrum 規定
那麼有技術背景的 scrum master 有啥好處呢?
因為 scrum 是一種 state machine 機制，再在每個 Life cycle 做該做的事
從 planning > [...daily] > review > retrospective > planning ....
透過預估後實作並進行檢討改善在下一個輪迴做修正的方式做事
scrum master 要參與大小會議，確保討論跟修正作法沒有走偏 scrum 規範
比如有人覺得開會浪費太多開發時間，乾脆以後都不要開會，scrum master 就要阻止
然後找出問題關鍵，例如會議零散在每天的半小時、一小時，很容易打斷 RD 思考
這時他就要協調把會議整併在某些固定時間，確保 RD 有足夠連續思考不被打斷的時間
或者團隊成員外務太多無法專心在團隊內貢獻，scrum master 也要幫忙解決
在 retrospective 莒光日教育 scrum 的好處，請大家寫莒作講本週心得
在 planning 看 PO 連長開作戰會議確保底下 developer 士兵都聽懂理解有參與有互動
總之 scrum master 具有監軍的性質，確保團隊想出的作戰方式不會跑偏或違反軍規
我遇過的 scrum master 多少都像輔導長那樣會跟你聊天問你有啥想法之類的
千萬別在 scrum master 面前犯了思想上的錯誤
如果要當 scrum master 也必需對 scrum 有足夠的信仰，喔我的意思是深入理解
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.240.211.196 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Tech_Job/M.1663954743.A.10B.html
... <看更多>