消除浪費 (3)：Relearning

Oct. 09 22:20~23:41

今日談談『七武器 七浪費』之三：Relearning，也可以稱為『rework』。如果一次就能做好，就不需要『rework』，所以 『第二次（或以上）』的 work 當然就是一種浪費。但是為什麼不直接說 rework，而要咬文嚼字的說 relearning？

由於軟體開發事實上就是一種『學習新知的過程』，因此減少重新學習已知的知識，就可以減少浪費，所以特別用 relearning 來強調『軟體開發實為學習新識』的特質。例如，團隊中有老鳥跟菜鳥，菜鳥被分配到開發『用 Java NIO 實做非同步檔案讀寫』的某項功能。老鳥對於此功能的技術十分熟練，但是被分配到該工作的卻是菜鳥。於是：

• 菜鳥先花了一整天搞懂什麼是 Java NIO。
• 菜鳥再花一天實做非同步檔案讀寫與撰寫單元測試。
• Tester 花了兩小時測出菜鳥所寫的程式有 5 個 bugs。
• 菜鳥解了其中的 3 個 bugs，另外 2 個看不出來問題再哪裡。
• 菜鳥請老鳥幫忙做 code review，老鳥只花了 10 分鐘就找出 8 個 bugs (原本尚未解的 2 個  bugs 外加 6 個 tester 沒測出來的 bugs)。
• 菜鳥將這 8 個 bugs 解完。
• 經過這一番過程，菜鳥獲得 10 點經驗值，菜鳥一級升級為菜鳥二級。

以上整個過程花了 6 個工作天，如果可以縮短學習的時間，便可減少時程的浪費。

***

大量的 relearning 對於軟體開發是一件『很傷』的事情，但是卻很難完全避免 relearning。團隊中幾乎不可能每一個人的知識與經驗都相同（如果能夠找『博格人』來開發軟體就太好了... 什麼，不知道博格人是什麼？來人啊，拖出去...看...Star Trek），因為『派工（分工）』的關係，又不可能把每件工作都交給最懂該工作的人來實做，因此便會造成 relearning 的現象。

另外，人是很『健忘的』，以前做過的事，曾經發生過的問題，日子一久，經常會忘記，因此相同的問題可能一再的發生，這也是 relearning（此時如果能找到『曾子』來開發軟體就好了，因為論語有紀載：『曾子不貳過』，這種人才找來寫程式最好）。

***

光知道 relearning 是一種浪費，那麼要如何減少 relearning 造成的浪費，這就傷腦筋了。請鄉民們想一下，有沒有哪一個 agile practices 是可以減少 relearning？知道答案的人，請將答案寫在明信片上，來信請寄『台北郵政 5408 號信箱』，前五名答對者本節目將提供神秘小禮物... XD

其實很多 agile practices 都和減少 relearning 有關，例如：

• 自動化測試：將程式正常行為的『知識』紀錄在自動化測試程式中，當自己或別人不小心產生 bugs 時（破壞程式正常行為），能夠透過紀錄下來的知識立即發現問題（就是這些自動化測試案例），如此便可減少  relearning 所花的時間（可參考 『需求分析書中最重要的資訊是什麼？』這篇）。
• 採用 Design by Contract 或是 assertion。理由類似自動化測試，這些技術在 runtime 都可自動驗證程式的行為是否符合原本的預期。
• Pair programming：師徒制是傳遞知識最好的方法之一，雖然過程辛苦了點。

族繁不及備載，請各自發揮。

***

友藏內心獨白：程式設計師徵人條件：具有博格人和曾子的性格。