繼 [軟體開發] 淺談軟體開發 再接著聊聊軟體工程師如何面對這一片困境，從一個最小的面向談起 ― 自己。
上一篇提到工具軟體及軟體系統，僅有些粗略的定義及區別。我曾經很認真的思考這之間該如何明確的區別及定義，我該如何向老闆陳述我是在「大兜兜」，而不僅僅是在開發工具軟體，需要更多的資源，更不一樣的文化。經過 CSM 課程開腦後，我有了答案―「SHOW, DON'T TELL.」。自己如何看待自己的產品，那它自然就會是什麼層級的項目。想要老闆更重視之前，請先讓自己更把自己的產品看作一回事。
既然 bug 是系統層級的問題，加班不能解決，那自己如何用系統層級的角度或高度去正視這一個問題？我想單元測試會是很棒的一個起手式。單元測試不僅僅是一個承諾，更是一種態度。每次是用著怎樣的心態遞交出每一字的程式碼，是用著什麼樣的方式擔保這一切的正確性？用人格？用經驗？不，我用的是單元測試。
有幸在六月時參加了九一大的 TDD 課程，近半年過去了，單元測試的威力仍在持續發酵。每次遞交程式碼，看著測試覆蓋率有意義的提昇，就覺得更是踏實。每次的建置發行，看著那一排綠燈的單元測試，心也比較泰然。課程簡介中提到：「哥不是教你測試，我們教的是開發！」，我更認為學到的不只是單單只是開發或測試，而是更扎扎實實態度。這段開頭說是有幸，絕非高捧客套，事後想想一點也不為過。倘若我沒有參加過課程，開始土砲撰寫單元測試以示負責，我想現在應該會非常崩潰，有幾個狀況是我可以猜想而知的：
- 依據函式而非工作單元撰寫測試，每天都在改測試程式。 => 那就 Ignore 這個測試吧。
- 耦合度太高，不知道該怎麼測。 => 那就不要測吧。
- 不明白測試覆蓋率的意義，沒有將之具體呈現。=> 寫單元測試看不見成就感。
- 自己也不知道怎麼測，每次遞交程式碼也不強求各位附上測試。=> 「有空」再寫單元測試吧。
- 單元測試應該也是 QA 的責任吧，我說那個 QA 呢？要不要來幫測一下？
綜上所述，這不太令人放心的測試，有測跟沒測一樣，寫測試好像變得多餘。如此崩潰的狀況，我這輩子可能再也不會想寫單元測試了。
經過這門課的學習、半年來的實務心得、《單元測試的藝術 第二版》讀後感，簡單摘要出幾個很常出現的問題：
- 單元測試是開發人員寫還是測試人員寫？
是開發，絕對是開發。不要再推給 QA 了。 - 承上，開發兼測試，不會有盲點嗎？
單元測試就是用來描述你的工作單元的，驗證工作單元運行結果的跟自己思考的一樣。如果自個都描述不好，怎能期待別人幫你驗證？ - 單元測試只是測試嗎？
不，他還是最棒的交接文件。否則...寫程式前先寫文件？嗯。。。
也是大刀闊斧重構時的定心丸。 - 寫程式還要再寫單元測試，要花更多時間？
沒錯，單就程式碼遞交前的時間來說，的確是要花更多的時間。但對於長期開發時程來說，絕對不會。bug 越早攔截，所付出的成本也就越低。想想光是一個 bug 流到客戶端，要花多少時間在溝通、重現問題，還要加班趕工解決，相較之下，我不覺得單元測試需要更多時間。 - 為了寫單元測試，程式碼會變得很醜嗎？
我想多數的情況是耦合度太高，本來就沒多漂亮，寫了單元測試更突顯這個醜陋的事實。
然而或許有種種不可抗力的因素，無法辦法撰寫單元測試。那還有其他方式表現你的態度嗎？我第一個想到的會是 ― Clean Code。是否很認真的讓自己寫出來的程式碼像文章一樣流暢？是否在正確執行之後，重新為了追求可讀性、可維護性，甚至是可測性，不斷的潤飾、修改你的程式碼？
讓程式碼運行結果正確與保持整潔容易閱讀同等重要。然而我們往往忽略後者的重要性。
-- Uncle Bob.
哥寫的不是程式，而是一種
溫度態度。-- 米史提克
