建站
咨詢
售后
建站咨詢
新聞中心
目前有很多程序開發(fā)人員都認為敏捷開發(fā)會幫助項目更快的完成，但是本次討論卻要從反方向來進行探討。希望這些對大家有所幫助。
增量迭代開發(fā)(敏捷實踐之一，它意味著每次迭代的產(chǎn)出只是本次迭代范圍內(nèi)的需求)真的不利于產(chǎn)生好的設(shè)計嗎?Scrum真的提倡“忽視架構(gòu)問題”嗎?如果沒有敏捷技術(shù)實踐的話，架構(gòu)設(shè)計能有效的演化嗎?測試先行式的開發(fā)真會產(chǎn)生優(yōu)雅的設(shè)計嗎?在紅綠條提示下的重構(gòu)循環(huán)只在局部小范圍內(nèi)有效嗎?
來自Net Objectives的Alan Shalloway就利用Scrum構(gòu)建應(yīng)用的經(jīng)驗向ScrumDevelopment yahoo group的成員提出一些問題，問題之一就是“他們是否找到代碼質(zhì)量是依靠什么來保證的?”
當我在課程中或在那些討論“向已建系統(tǒng)中追加新特性”的會議中提出這個問題時，每個人都認為這屬于集成成本。我想，這是因為大多數(shù)人不會編寫那些融入了很多設(shè)計模式的具有良好的擴展性、足夠靈活并且易維護的代碼。這些人中，大部分也沒有使用過Scrum。
Shalloway隨后詳細解釋了他的觀點：
……正如Scrum所告訴我們的，他們(指在Scrum團隊中的開發(fā)者)根據(jù)客戶價值一次只開發(fā)系統(tǒng)的一小部分，如果團隊中有高級架構(gòu)師的話，就會組織得更好。很多開發(fā)者有一種很好的意識，即他們會回頭看一下是否應(yīng)該做一些改動，使架構(gòu)更合理。但更多的人并不知道，假如代碼是通過拷貝、粘貼并修改(甚至改得面目全非)得來的，那么這會帶來很多冗余。此時，Template Method可能是一個比較好的解決方案。
也許我悲觀了一些，但我的感覺是，假如你沒有注意熵的話，就意味著它們會達到你不期望的地步。在你的案例中，你正在使用Scrum來改善很多團隊忽視的東西。所以，我的問題是：
大家忽視它了嗎?
如果真是這樣，它會引來問題嗎?
到目前為止，這些反應(yīng)都表明很多使用Scrum的團隊有這個問題，甚至那些堅持寫測試和進行重構(gòu)的團隊也有同樣的問題。那些沒有使用多少有些變化的敏捷技術(shù)實踐的團隊，可能會有更大的麻煩。(請記?。篠crum 與開發(fā)技術(shù)沒有必然的聯(lián)系，你可以使用傳統(tǒng)方法開發(fā)軟件，也可以用XP，或者其它技術(shù)實踐，只要你在Scrum的框架之內(nèi)使用就可以了)
接下來，讓我們討論一下現(xiàn)實中，Red-Green-Refactor loop是如何發(fā)揮作用的?一個團隊在寫測試和重構(gòu)方面深有心得，就會有一個好的設(shè)計嗎?Paul Jones 的blog中有一篇關(guān)于TDD如何創(chuàng)建了混沌代碼(Ravioli Code)，宣稱用TDD開發(fā)出來的代碼是低耦合的代碼：
我想，很多TDD和測試先行的理想主義者和宣傳者寫出了的確經(jīng)過充分測試的代碼，但還是很難理解。
Jones并不想撼動TDD，因為與其測試目的相比，TDD實際上更關(guān)注于設(shè)計。但這還是會帶來一個有趣的事情。在使用這些實踐的敏捷社區(qū)中，好在哪里呢?隨著社區(qū)的成長，這些實踐帶來的麻煩比其帶來的好處還多嗎?與傳統(tǒng)開發(fā)技術(shù)相比，這些工具被不正確的使用是否更危險?
最后，讓我們假設(shè)：我們正在恰當?shù)厥褂肧crum和TDD。畢竟，象Ron Jeffries 在《We Tried Baseball and It Didn't Work》一文中所呈現(xiàn)的，我們不能因為自己沒有正確地使用它而將不好的結(jié)果強加給它。TDD會產(chǎn)生好的設(shè)計嗎?對于使用Red-Green-Refactor loop的做法，重構(gòu)可以說是一種局部優(yōu)化技術(shù)。我們優(yōu)化局部的設(shè)計。本質(zhì)上，這等同于steepest descent algorithm，也就意味著重構(gòu)幾乎總是會帶來次優(yōu)設(shè)計，就象使用TDD來做“數(shù)獨游戲”一樣。
現(xiàn)在是我們用批判的眼光來重新審視我們的這些實踐的時候了嗎?
網(wǎng)頁標題：討論：敏捷開發(fā)真的對架構(gòu)設(shè)計不利嗎？
當前網(wǎng)址：http://www.dlmjj.cn/article/cdsepip.html
