敏捷軟體開發-第六章

linjinxiao發表於2007-04-17
敏捷
敏捷軟體開發第六章是關於一個保齡球程式的實踐過程。

主要涉及了兩個主題:測試驅動和重構--這兩個概念都很好。
但我覺得這篇文章不好，感覺編寫程式碼的過程沒有很清晰的思路，過度依賴測試用例。我完全同意它結論部分的反方意見。
----
結論
　完成本章後，我把它釋出在ObjectMentor的ｗｅｂ站點上。許多人閱讀後給出了自己的意見。有些人認為這篇文章不好，因為其中幾乎沒有涉及物件導向設計方面的任何內容。我認為這種回應向物件設計的情形。事實上，僅有Ｓｃｏｒｅｒ類稍微有一點物件導向的味道，不過那也只是一個簡單的分割，而不是真正的ＯＯＤ。
　另外一些人認為確實應該有Ｆｒａｍｅ類。有人竟然建立了一個包含Ｆｒａｍｅ類的程式版本，該程式比上面所看到的要大得多，也複雜得多。
　一些人覺得我們對ＵＭＬ有失公正。畢竟，在開始前我們沒有做一個完整的設計。餐巾紙背面的有趣的小ＵＭＬ圖不是一個完整的設計。其中沒有包括序列圖。我認為這種看法更加奇快。就我而言，即使在圖６．２　中加入序列圖，也不會促使我們放棄Ｔｈｒｏｗ類和Ｆｒａｍｅ類。事實上，那樣做反而會使我們覺得這些類是必需的。
　圖示是不重要的嗎？當然不是。嗯，實際上，對於某些我所碰到的情形是不需要的。就本章中的程式而言，圖示就沒有任何幫助。他們甚至分散了我們的注意力。如果遵循這些圖示，所得到的程式就會具有很多不必要的複雜性。你也許會說同樣也會得到一個非常易於維護的程式，但是我不同意這種說法。我們剛剛瀏覽的程式是因為易於理解所以才易於維護的，其中沒有會導致該程式僵化或者脆弱的不正當依賴關係。
　所以，是的，圖示有時是不需要的。何時不需要呢？在建立了它們而沒有驗證他們的程式碼就打算去遵循它們時，圖示就是無益的。畫一幅圖來探究一個想法是沒有錯的。然而，畫一幅圖後，不應該假定該圖就是相關任務的最好設計。你會發現最好的設計是在你首先編寫測試程式碼，一小步一小步前進時逐漸形成的。
－－－
我同意上面三個反方的觀點：
１　沒有進行物件導向的設計，而這個例子用物件導向設計應該很清晰
２　確實應該有Ｆｒａｍｅ類，看完程式，我非常有衝動想以自己的物件導向的設計　　來重新寫一遍。
３　沒有一個完整性的設計，過度依賴能夠想到的測試用例。

相關文章