落實的能力 (2)

April 22 21:20~22:18

昨天寫到一半跑去到垃圾，當 Teddy 把垃圾放在電線桿旁邊，人站在離垃圾約 5 步之遙的位置，正在等待垃圾車到來時，突然發現有某位婦人正在偷偷地亂搞 Teddy ...的垃圾。Teddy 也沒想那麼多，直覺反應立刻跑過去說了一聲『這是我的垃圾耶 （垃圾還怕人家搶...XD）』。原來那位婦人手上拿著兩包小垃圾，但是她沒有使用 舊北市 台北市政府所規定的垃圾袋，所以她就到處找『落單的垃圾袋』，試圖把她自己的垃圾『寄生』在別人的垃圾袋之中。

被 Teddy 一喊，這位婦人面露不好意思的表情，就帶著她的那兩小包垃圾，另外尋找合適的寄生對象。事後 Teddy 想一想，會不會太嚴厲了一點，也許有些人真的有經濟上的困難，雖然一般人可能覺的一包專用垃圾袋沒多少錢，但是對於經濟較不寬裕的人，長期省下來也是一筆小錢。至少這位婦人也沒把垃圾亂丟，還願意把自己的垃圾寄生在別人的垃圾袋裡面，也算是還有守法的精神了。和那些把垃圾隨地亂丟，或是硬塞到路邊垃圾筒的人相比，這位婦人算是有公德心的了。以後如果再遇到這種『垃圾寄生事件』，應該要抱持著寬容一點的心去看待才是。

***

昨天談到在持續整合系統（以下簡稱 CIS）上面如何兼顧『縮短整合執行時間』與『執行多樣化整合任務』這兩件事，最後得到『安裝兩套 CIS，一套用來跑編譯與產生安裝程式的工作，另一套用來執行整的整合任務』這樣的結論。

說真的 Teddy 之前沒想過這個問題，記得有快四年前有一次 Teddy 聽到有人在 CIS 上面只編譯程式而沒有執行單元測試，當場表現出『CI 不是這樣做滴』的鄙視態度。對於對方回答『測試案例執行時間太久了啊，所以為了縮短整合的時間，只能選擇不去執行單元測試』這樣的理由，當時 Teddy 是完全無法接受。為什麼？因為『書上說』單元測試就是要『想辦法』跑的很快啊，如果寫出來的單元測試跑的很慢，那一定是不認真沒有寫出『正港的單元測試啦』。因為單元測試跑太久在 CIS 上面就不執行，如此因噎廢食的態度，實在是無法認同。

沒多久 Teddy 也面對到同樣的問題...結果...走上同樣的道路...『測試案例執行時間太久，所以為了縮短整合的時間，只能選擇不去執行單元測試』。如此向下沉淪，實非 Teddy 行事之道。很遺憾，已經如此苟且偷生快三年了，難道這就是傳說中的『理論與實務之間的差距』？以Teddy 的情況而言，會演變至此有以下幾個原因：

• 把 code 送交到 CIS 之前都有在開發環境（Eclipse）上執行 JUnit，所以在 CIS 上面沒有跑 JUnit 的罪惡感就沒有那麼重...XD
• 每次把 code 送交到 CIS 之後，過不久就會產生一個 Installer 程式，而 Teddy 所屬團隊後來都有一個習慣，會直接去測試這個新產生的 Installer。由於我們有採行一些辦法讓測試整個 Installer 的流程比較順一點，所以慢慢也就覺的沒有在 CIS 上執行單元測試好像還過得去。
• 因為我們的程式需要跨平台且與硬體設備相依性很高，而 CIS 目前是安裝在 Linux 上面。以前剛開始還有在跑 JUnit 的時候，有一些與平台或是硬體相依的 test cases  會失敗，也沒有人去理它，因為大家都知道此為正常現象，請安心服用...XD。久而久之就沒有去注意 CIS 上面執行失敗的測試案例。既然沒人去看，為了省時間就乾脆廢掉算了。
• 當然最後總歸一句就是要省時間，趕快拿到新產生的 Installer。
• 再加上後來有採行每天晚上自動執行功能測試案例，自此之後在 CIS 上沒有執行單元測試這件事情就更加逐漸的被遺忘。

***

其實省時間的另外一個方法就是升級硬體，自從換了高檔的伺服器作為執行 CIS 的電腦之後，『手頭寬裕了不少』，因此開始想要儘量回歸到原本 CI 的精神，除了執行單元測試以外，test coverage 與靜態程式碼分析（FindBugs, PMD 這類的工具）也都要執行一下。今天在 sprint demo meeting 時，大家看了一下 PMD 的報表，就當場不小心找到一個 bug。雖然是一個小小的 bug，但是當下大家都認同這件事情應該要做。PMD 這個工具大概 5-6 年前 Teddy 就用過了，但是都是心血來潮時稍微用了一下下，從來沒有持續使用下去。可是只要是跟別人介紹 CI 觀念，都會提到 test coverage，PMD, FindBugs 這類的工具。為什麼不能持續使用的原因姑且先不談（因為打字打到手痛了），現在把 test coverage，PMD, FindBugs 放到 CIS 上面，有以下幾個好處：

• 整個 team 的人都看的到，專案變的更透明了。例如，當 Teddy 看到某個 class 的 test coverage 很低的時候，就有一股衝動會想要去多寫幾個 test cases。這難道是『便利商店集點活動症候群』發作嗎？
• 由於專案變透明了，如果自己寫的程式被這些工具找出太多明顯的 bugs，那就有點『太難看了』。所以 programmers 會更『自愛』一點。往正面思考，可以學到一些平常疏忽的 coding 技巧或是應該要避免的壞習慣。
• Scrum Master 如果沒事可看看報表，很容易可以找出一堆有待改善的項目。
• Test coverage 如果很高，可以拿到客戶面前去『炫耀』。

啊，衣服洗好了，Teddy 要去批衣服了。

***

友藏內心獨白：好忙的一天，為了九顆硬碟得罪了一堆人。