【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自重 的形式，裡面真的會比「長麵筋」還藏污納垢的....
搞產品的只要那種永遠特定模組都只有特定人維護，基本上死期不遠，腐敗發臭速度超乎想像，拖越久越沒辦法，慎之慎之。
#敏捷人生
養code自重 在 Re: [請益] 即將離職的屬下擺爛，怎麼辦？ - 精華區Tech_Job 的推薦與評價
※ 引述《uomtk (阿本Ben)》之銘言：
u大的方法要看情況
某些情況有用,某些情況死更快
我會覺得重點在於這個員工的離職原因
絕大部份的離職都不會搞到這麼僵
我過去跟主管處得不愉快,離職的時候我還是把該寫的文件寫完
並且跟交接的人講解整個程式架構.
會搞到擺爛不交接,大概分兩種情況
一種是這個人真的很沒有職業道德
但是會讓這種人負責重要專案,好像有哪邊不太對XD
而且真的不負責的人,絕對不會跟你兩個月後離職
一定是提了以後照勞基法30天走人.
另一種是積怨已久
不去了解怨恨的原因,反而將壓力轉嫁到別人身上
有時候只會引起更大的反彈....
基本上還是要搞清楚離職的原因,才比較好判斷該怎麼做
只不過建議就是主管要自己跳下去交接,
leader夠有guts,屬下才肯賣命.
P.S. 這邊的意思是交接的時候主管跟員工一起參與交接
讓交接的員工能有個討論對象.
順便聊一個過去不愉快的交接經驗 (就是先前提的 跟主管處的不愉快的那份工作)
當時負責C#的工程師離職,team裡面沒人會寫C#
主管跑來找我,以下是當時的對話
"你會寫java嗎?"
"只有學生時代寫過"
"C#跟java很像,這工作就你先接下來吧"
當時主管還說這邊只有我會java
明明team裡面有兩個台大資工碩,其中一個還是台大資工學士升上來的 = =|||
之後我花了一個月學C#
再花了一個月解完bug,把預計的功能做完,完成release.
又過了兩個月,我離職了 XD
雖然離職原因蠻雜的,
一以蔽之就是一堆不爽累積到我不想幹了.
不去搞清楚原因,只是把壓力轉嫁給其他人
一個沒搞好,就是其他人跟著走.
對了,陪著加班這點很重要
deadline前一晚我加班到九點多,整層辦公室只剩下我跟大主管
我6:30正在跟基層主管討論SPEC,結果我出去上個廁所,回來他就不見了
隔天我還被他罵了一頓,說我debug能力很弱之類的
當下我真的差點就要理智斷線跟他對罵了 XD
雖然有點扯遠,但是這份工作讓我學到的教訓是
不要隨便亂接工作,屎吃下來就是你的,主管絕對不會找別人幫你一起吃屎.
當初我在交接前就直接跟主管表明了我不想做這個工作
暫時頂一下我ok,但是希望未來能找到新人頂替這份工作.
當時主管也承諾我會繼續找人,實際上完全不是這麼一回事 XD
主要還是希望原po能多講一些細節啦
不然只是說離職員工擺爛,版友也沒辦法給啥有效的建議...@@"
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.248.193.160
※ 文章網址: https://www.ptt.cc/bbs/Tech_Job/M.1435940110.A.0DB.html
... <看更多>