注重紀律——讀《浮現式設計》有感

        題記：正在讀《浮現式設計:專業軟體開發的演化本質》(榮獲第19屆Jolt生產力大獎)一書，順手寫下了一點自己的感想與淺見，是以為記。

 

        這一章的主題是單元測試，給我帶來了很多思考。

        首先就是測試經濟學，作者為我們帶來了非常有趣的辯證邏輯：

• 大多數軟體開發專業人員都會稱讚測試的好處，而大部分現代軟體開發過程亦會包含測試，將其作為項目中必備的元素之一
• 許多軟體開發人員除了確保他們的代碼能夠編譯成功（讓我們看看它是否能夠運行）並進行手動的功能測試外，並不會做任何的測試

        這兩個現象在我身上的體現都很明顯，一方面我也在推動工程過程當中重視測試並建議引入單測，另一方面我也與許多軟體開發人員一樣，認為單測的成本太高。“我太忙了，寫不了測試”，“如果我寫單測，就沒時間寫代碼了”，“My Code都已經實現功能了，為何還要去寫單測來再次進行這個無謂的不嚴謹的證明呢？”

        其實在三章前的內容裡，作者提到可測試性是一個基本的品質準則時，我就開始反思自己對單測和測試的認識。在我的眾多代碼實踐中，我是忽視了可測試性這個指標的。而且只看到了單測的成本，而沒有看到單測的收益，甚至都沒有給自己找個理由來試行單測。儘管軟體工程的理論學了不少，但還是單純的把測試作為了一個工程階段，沒有與開發融合在一起。即使使用了敏捷開發方法，也沒有重新審視在敏捷方式下編碼和測試的變化。

        據我瞭解，單元測試在很多類型的開發領域中都已經或正在起著越來越重要的作用，並且獲得了很好的收益，在代碼品質上均有所提高，比如server開發。不過在需要快速響應變化的移動用戶端領域，還很少有較好的施行單測的案例，一方面是在這方面的單測架構、技術還沒有那麼豐富的積累，另一方面可能受到開發方法、裝置、快速變化的需求的限制。但是本章中作者已經展現了測試的收益給我們，我想這是我要彌補的地方了。

        最後用作者的原文結束本章。

• 編寫測試是對類的預期行為進行研究的一個過程。在動手之前先理解自己要做的是什麼，這會讓你對整個工作流程有更清楚的認識。
• 測試為重構提供了安全網。浮現式設計是一個漸進的流程，也就是說會出現很多變更（甚至比我們習慣的還多）。要想積極地做出變更，則需要進行測試，以確認我們沒有破壞任何東西，從而增加我們進行變更的信心。
• 測試是一種文檔，它記錄的不是類是如何啟動並執行，而是表達了從外部視角看，類應該做什麼。

——歡迎轉載，請註明出處 http://blog.csdn.net/caowenbin ——