預料之外的Pair Programming & Code Review

Pair Programming & Code Review 是常見於軟體書中被推崇的開發方法與流程，

我也很想進行這樣的開發活動，但當時公司沒有這樣的風氣，

身為公司內最菜的人好像也很難要求前輩跟你一起寫Code，

但偶然間發現，透過以下方式，

也能間接達到Pair Programming & Code Review 的好處。

由於我習慣手寫筆記，但手寫筆記很難將程式碼的一些結構與流程表現出來，

因此我會透過Power Point進行紀錄，這樣可以很方便的擷取程式碼來記錄。

將解決問題的思路完整的紀錄在簡報

簡報中包含

發現問題：描述如何發現問題，透過那些線索推導出可能的問題。

解決方式：針對剛剛思考的問題，列出可能的解決方式。

嘗試與推論：對已列出的解決方式，實作並推導是否已成功解決，或者還有哪些疑慮？

結論：總結你的思路，如果問題還沒解決，列出困難處，並思考更深層的疑問。

同時也節錄重點程式碼加以說明，

最後寄給主管與同仁看，主動出擊。

要記得，嘗試與推論這個步驟是非常重要的，

一定要自己先行思考過，整理出思緒，

才不會覺得你是雙口空空的來要答案。

問題情境：

該程式有兩者各自獨立的thread運作，進行數據蒐集的動作，

各自完成後便結束自身的Thread，避免程式持續佔據Thread資源。

而它們共用同一個CancellationToken(用以通知該結束Thread的訊號)，

因此第一支Thread完成蒐集數據的任務時立刻啟動了CancellationToken，

導致第二支Thread還沒達到任務完成的條件就偵測到CancellationToken被啟動了，

因此第二支Thread蒐集的數據便會短缺。

這時發現是可能是對於CancalltionToken使用上的誤解，

因此將該問題與簡報寄給同事並請教他相關議題，

熱心的同事仔細的看完我的簡報後，除了點出CancalltionToken使用上的誤區，

也告訴我他認為CancalltionToken應用在非預期結果的情況下去中斷Thread，

有正當結束條件時應寫出判斷式，

有助於往後閱讀程式碼時能夠理解在什麼情形下會被中斷。

雖然我認為用在一般情況去終止Thread應該不無不妥，它就是一個終止的方式而以，

這時念頭一轉，我才恍然大悟發現我已經有終止Thread的條件了，

(也就是達成蒐集資料的數量)

因此達到條件後透過Return就能終止Thread。

跳脫思考框架

當初會使用CancellationToken是因為同仁的功能是連續蒐集資料，

沒有結束的判斷點(停止條件)，

因此只能透過CancellationToken去取消Task，

而我接手之後也順著沿用CancellationToken去做停止Task的動作，

可能是怕破壞既有的工作模式，就沒去思考是否有更佳的解決方式，

思緒被第一印象帶著走，視野就變的狹隘了，

所以Clean Code才會提倡Pair Programming吧！

一起看Code

在這樣的討論過程中，不只原本的問題被點到，

連同其他程式部分也給了許多實用的建議，

甚至直接開啟專案進行修改，

體驗到Pair Programming時的交流樂趣。

想要的團隊自己創造

前公司當時並沒有Code Review的制度，

但這一次因為詳細的把思考歷程與程式碼紀錄在簡報，

變成一種另類的Code Review，儘管不是直接的解答我的問題，

但卻激發我以不同的視角去看這件事情，幫助實在很大。

當下主管沒有code review的規劃，

甚至也不知道Pair Programming是什麼，畢竟他不是軟體專長。

但或許也可以透過這樣的方式和同事進行code review，

如果大家開始體會到Pair Programming & Code Review 的好處，

也可能漸漸地感染大家套用更好的開發模式。