本篇的主題是 The power of duplicate code，翻成中文是『重複的程式碼的力量』。奇怪，duplicate code 不是一種寫程式應該要避免的 bad smell 嗎，為什麼這種壞東西還會有『力量』？別忘了星際大戰中尤達大師也曾經說過要留意『the power of dark side』，這種暗黑勢力有時候比正義的力量來的還要強大（不然黑武士為什麼那麼強）。
那麼，duplicate code 到底有什麼力量？Teddy 發現 duplicate code 最大的力量就是可以讓 programmers 看起來很忙且生產力很高。多麼神奇的力量啊！
講一個 Teddy 從朋友那裡聽來的的故事，真的是聽來的喔，絕對不是發生在 Teddy 周遭的人身上。故事是這樣的，有一個小型的軟體開發團隊，在沒有採用 Scrum 之前，team members 都各自負責若干個 sub-projects，彼此也幾乎不會去看其他人所寫的 code。後來，這個團隊不小心無緣無故被強迫中獎採行了 Scrum。經過若干 sprints 之後，閒閒沒事的 Scrum Master 突然去 review 某一個 sub-project，發現雖然是用 OO (物件導向) 語言來開發系統，但是裡面的 code 設計的很不 OO ，理解度大該只有 10% 不到（另一種說法是這個 Scrum Master 太遜了，看不懂別人寫什麼...）。但是由於當時這個 sub-project 的程式可以正常執行，Scrum Master 也就沒有立即建議要 refactor 該模組，反而是偷偷保佑永遠都不需要改到它。
但是，如果真的不用修改那麼這個故事也就講不下去了。某一天，該團隊突然發現這個 sub-project 在 multiple-threaded 的情況會出錯，而原本的負責人 （在此稱之為 X 先生）在事蹟敗露之前早已想辦法『落跑』到其他專案中。為了解決此問題，Scrum Master 花了一點時間以 OO 的方式來重新設計該 sub-project，然後與其中一位有一點了解這個 sub-project 的 team member 一起採用 pair programming 的方式重新寫了這個 sub-project。完成之後，原本在 multiple-threaded 環境所遇到的 bug 也自然消失了。不過這不是重點，重點是 Scrum Master 很無聊的去算了一下該 sub-project『改造前』和『改造後』的 LOC (line of code)：
- 改造前：約 10000 行 。
- 改造後：約 2000 行 （包含 unit tests）。
***
在真實世界中，有多少人（多少主管或同事）會幫你做 code review？在台灣應該極少，因此誰說 duplicate code 是 bad smell，從 X 先生的觀點，duplicate code 可是 good smell 呢！要不是有 duplicate code，如何讓每天都有生產力呢。
老闆：我的員工每天都加班，工作好認真，好辛苦喔。
Teddy ：你確定...
也許大部分的老闆或主管都忙到只能對員工實施『black-box testing』，無法實際了解員工每日的工作。此時，duplicate code may be a good smell。如果鄉民們的公司採行的是 TPS（Toyota Production System），強調『現場管理』，那麼 duplicate code 肯定是 bad smell。但是，話說回來，在台灣有誰開發軟體那麼『精實』啊。
結論，duplicate code 因為文化因素因此在台灣可能有 90% 的機率是屬於 good smell。
***
友藏內心獨白：故事真的是聽來的喔。
沒有留言:
張貼留言