[軟體開發] 單元測試及Clean Code

繼 [軟體開發] 淺談軟體開發 再接著聊聊軟體工程師如何面對這一片困境,從一個最小的面向談起 ― 自己。

 

上一篇提到工具軟體軟體系統,僅有些粗略的定義及區別。我曾經很認真的思考這之間該如何明確的區別及定義,我該如何向老闆陳述我是在「大兜兜」,而不僅僅是在開發工具軟體,需要更多的資源,更不一樣的文化。經過 CSM 課程開腦後,我有了答案―「SHOW, DON'T TELL.」。自己如何看待自己的產品,那它自然就會是什麼層級的項目。想要老闆更重視之前,請先讓自己更把自己的產品看作一回事。

要別人怎麼看你,你得先如何看待自己。

既然 bug 是系統層級的問題,加班不能解決,那自己如何用系統層級的角度或高度去正視這一個問題?我想單元測試會是很棒的一個起手式。單元測試不僅僅是一個承諾,更是一種態度。每次是用著怎樣的心態遞交出每一字的程式碼,是用著什麼樣的方式擔保這一切的正確性?用人格?用經驗?不,我用的是單元測試。

有幸在六月時參加了九一大的 TDD 課程,近半年過去了,單元測試的威力仍在持續發酵。每次遞交程式碼,看著測試覆蓋率有意義的提昇,就覺得更是踏實。每次的建置發行,看著那一排綠燈的單元測試,心也比較泰然。課程簡介中提到:「哥不是教你測試,我們教的是開發!」,我更認為學到的不只是單單只是開發或測試,而是更扎扎實實態度。這段開頭說是有幸,絕非高捧客套,事後想想一點也不為過。倘若我沒有參加過課程,開始土砲撰寫單元測試以示負責,我想現在應該會非常崩潰,有幾個狀況是我可以猜想而知的:

  • 依據函式而非工作單元撰寫測試,每天都在改測試程式。 => 那就 Ignore 這個測試吧。
  • 耦合度太高,不知道該怎麼測。 => 那就不要測吧。
  • 不明白測試覆蓋率的意義,沒有將之具體呈現。=> 寫單元測試看不見成就感。
  • 自己也不知道怎麼測,每次遞交程式碼也不強求各位附上測試。=> 「有空」再寫單元測試吧。
  • 單元測試應該也是 QA 的責任吧,我說那個 QA 呢?要不要來幫測一下?

綜上所述,這不太令人放心的測試,有測跟沒測一樣,寫測試好像變得多餘。如此崩潰的狀況,我這輩子可能再也不會想寫單元測試了。

經過這門課的學習、半年來的實務心得、《單元測試的藝術 第二版》讀後感,簡單摘要出幾個很常出現的問題:

  1. 單元測試是開發人員寫還是測試人員寫?
    是開發,絕對是開發。不要再推給 QA 了。
  2. 承上,開發兼測試,不會有盲點嗎?
    單元測試就是用來描述你的工作單元的,驗證工作單元運行結果的跟自己思考的一樣。如果自個都描述不好,怎能期待別人幫你驗證?
  3. 單元測試只是測試嗎?
    不,他還是最棒的交接文件。否則...寫程式前先寫文件?嗯。。。
    也是大刀闊斧重構時的定心丸。
  4. 寫程式還要再寫單元測試,要花更多時間?
    沒錯,單就程式碼遞交前的時間來說,的確是要花更多的時間。但對於長期開發時程來說,絕對不會。bug 越早攔截,所付出的成本也就越低。想想光是一個 bug 流到客戶端,要花多少時間在溝通、重現問題,還要加班趕工解決,相較之下,我不覺得單元測試需要更多時間。
  5. 為了寫單元測試,程式碼會變得很醜嗎?
    我想多數的情況是耦合度太高,本來就沒多漂亮,寫了單元測試更突顯這個醜陋的事實。
經過這半年實務經驗,不只一次令我發出驚嘆「呼~還好有單元測試」。

然而或許有種種不可抗力的因素,無法辦法撰寫單元測試。那還有其他方式表現你的態度嗎?我第一個想到的會是 ― Clean Code。是否很認真的讓自己寫出來的程式碼像文章一樣流暢?是否在正確執行之後,重新為了追求可讀性、可維護性,甚至是可測性,不斷的潤飾、修改你的程式碼?

讓程式碼運行結果正確保持整潔容易閱讀同等重要。然而我們往往忽略後者的重要性。

                                                                                                                                 -- Uncle Bob.

哥寫的不是程式,而是一種溫度態度。

                                                                                                                                   -- 米史提克