迭代是一種軟件開發(fā)的生命周期模型，在設(shè)計中應(yīng)用迭代設(shè)計，我們可以得到很多的好處。
在軟件生命周期中，我們?nèi)绾螌Υ軜?gòu)設(shè)計的發(fā)展？
架構(gòu)設(shè)計往往發(fā)生在細節(jié)需求尚未完成的時候進行的。因此，隨著項目的進行，需求還可能細化，可能變更。原先的架構(gòu)肯定會有不足或錯誤的地方。那么，我們應(yīng)該如何對待原先的設(shè)計呢？
我們在簡單設(shè)計模式中簡單提到了"Planned Design"和"Evolutionary Design"的區(qū)別。XP社團的人們推崇使用"Evolutionary Design"的方式，在外人看來，似乎擁護者們從來不需要架構(gòu)的設(shè)計，他們采用的方式是一開始就進入代碼的編寫，然后用Refactoring來改進代碼的質(zhì)量，解決未經(jīng)設(shè)計導(dǎo)致的代碼質(zhì)量低下的功能。
從一定程度上來說，這個觀點并沒有錯，它強調(diào)了代碼對軟件的重要性，并通過一些技巧（如Refactoring）來解決缺乏設(shè)計的問題。但我并不認同"Evolutionary Design"的方式，在我看來，一定程度上的"Planned Design"是必須的，至少在中國的軟件行業(yè)中，"Planned Design"還沒有成為主要的設(shè)計方向。借用一句明言，"凡事預(yù)則立，不預(yù)則廢"，在軟件設(shè)計初期，投入精力進行架構(gòu)的設(shè)計是很有必要的，這個架構(gòu)是你在后續(xù)的設(shè)計、編碼過程中依賴的基礎(chǔ)。但是，一開始我們提到的設(shè)計改進的問題依然存在，我們?nèi)绾谓鉀Q它呢？
在簡單設(shè)計模式中，我們提到了設(shè)計改進的必要性，但是，如果沒有一種方法去控制設(shè)計的改進的話，那么設(shè)計改進本身就是一場噩夢。因此，何時改進，怎么改進， 如何控制，這都是我們需要面對的問題。
解決方法
為了實現(xiàn)不斷的改進，我們將在開發(fā)流程中引入迭代的概念。迭代的概念在《需求的實踐》中已經(jīng)提到，這里我們假設(shè)讀者已經(jīng)有了基本的迭代的概念。
軟件編碼之前的工作大致可以分為這樣一個工作流程：
上圖中的流程隱含著一個信息的損失的過程。來自于用戶的需求經(jīng)過整理之后，開發(fā)人員就會從中去掉一些信息，同樣的事情發(fā)生在后面的過程中，信息丟失或變形的情況不斷的發(fā)生。這里發(fā)生了什么問題？應(yīng)該說，需求信息的失真是非常普遍的，我們?nèi)鄙俚氖且环N有效的辦法來抑止失真，換句話說，就是缺少反饋。
如果把眼睛蒙上，那我們肯定沒有辦法走出一條很長的直線。我們走路的時候都是針對目標不斷的調(diào)整自己的方向的。同樣的，漫長的軟件開發(fā)過程如果沒有一種反饋機制來調(diào)整方向，那最后的軟件真是難以想象。
所以我們引入了迭代周期。
初始設(shè)計和迭代設(shè)計
在團隊設(shè)計中，我們一直在強調(diào)，設(shè)計組最開始得到的設(shè)計一定只是一個原始架構(gòu)，然后把這個原始架構(gòu)傳播到每一位開發(fā)者的手中，從而在開發(fā)團隊中形成共同的愿景。（愿景（Vision）：源自于管理學(xué)，表示未來的愿望和景象。這里借用來表示軟件在開發(fā)人員心中的樣子。在后面的文章中我們會有一個章節(jié)專門的討論架構(gòu)愿景。）
迭代（Iterate）設(shè)計，或者我們稱之為增量（Incremental）設(shè)計的思想和XP提倡的Evolutionary Design有異曲同工之妙。我們可以從XP、Crystal、RUP、ClearRoom等方法學(xué)中對比、體會迭代設(shè)計的精妙之處：每一次的迭代都是在上一次迭代的基礎(chǔ)上進行的，迭代將致力于重用、修改、增強目前的架構(gòu)，以使架構(gòu)越來越強壯。在軟件生命周期的最后，我們除了得到軟件，還得到了一個非常穩(wěn)定的架構(gòu)。對于一個軟件組織來說，這個架構(gòu)很有可能就是下一個軟件的投入或參考。
我們可以把早期的原始架構(gòu)當作第一次迭代前的早期投入，也可以把它做為第一次迭代的重點，這些都是無所謂的。關(guān)鍵在于，原始架構(gòu)對于后續(xù)的架構(gòu)設(shè)計而言是非常重要的，我們討論過架構(gòu)是來源于需求的，但是原始架構(gòu)應(yīng)該來源于那些比較穩(wěn)定的需求。
TIP：現(xiàn)實中迭代設(shè)計退化為"Code and Fix"的設(shè)計的情況屢見不鮮（"Code and Fix"參見簡單設(shè)計）。從表面上看，兩者的做法并沒有太大的差別，都是針對原有的設(shè)計進行改進。但是，二者效果的差別是明顯的："Code and Fix"是混沌的，毫無方向感可言，每一次的改進只是給原先就已搖搖欲墜的積木上再加一塊積木而已。而迭代設(shè)計的每一次改進都朝著一個穩(wěn)定的目標在前進，他給開發(fā)人員帶來信心，而不是打擊。在過程上，我們說迭代設(shè)計是在控制之下的。從實踐的經(jīng)驗中，我們發(fā)現(xiàn)，把原該在目前就該解決的問題退后是造成這一問題的主要原因之一。因此，請嚴格的對待每一次的迭代，確保計劃已經(jīng)完成、確保軟件的質(zhì)量、確保用戶的需求得到滿足，這樣才是正統(tǒng)的迭代之路。
單次的迭代
我們說，每一次的迭代其實是一個完整的小過程。也就是說，它同樣要經(jīng)歷文章中討論的這些過程模式。只不過，這些模式的工作量都不大，你甚至可以在很短的時間內(nèi)做完所有的事情。因此，我們好像又回到了文章的開頭，重新討論架構(gòu)設(shè)計的過程。
單次迭代最令我們興奮的就是我們總是可以得到一個在當前迭代中相當穩(wěn)定的結(jié)果，而不像普通的架構(gòu)設(shè)計那樣，我們深怕架構(gòu)會出現(xiàn)問題，但又不得不依賴這個架構(gòu)。從心理上來分析，我們是在持續(xù)的建設(shè)架構(gòu)中，不需要回避需求的變更，因為我們相信，在需求相對應(yīng)的迭代中，會繼續(xù)對架構(gòu)進行改進。大家不要認為這種心理的改變是無關(guān)緊要的，我起初并沒有意識到這個問題，但是我很快發(fā)現(xiàn)新的架構(gòu)設(shè)計過程仍然籠罩在原先的懼怕改變的陰影之下的時候，迭代設(shè)計很容易就退化為"Code and Fix"的情形。開發(fā)人員難以接受新方法的主要原因還是在心理上。因此，我不得不花了很多的時間來和開發(fā)人員進行溝通，這就是我現(xiàn)實的經(jīng)驗。
迭代的交錯
基于我們對運籌學(xué)的一點經(jīng)驗，迭代設(shè)計之間肯定不是線性的關(guān)系。這樣說的一個原因架構(gòu)設(shè)計和后續(xù)的工作間還是時間差的。因此，我們不會傻到把時間浪費在等待其它工作上。一般而言，當下一次迭代的需求開始之后，詳細需求開始之前，我們就已經(jīng)可以開始下一次迭代的架構(gòu)設(shè)計了。
各次迭代之間的時間距離要視項目的具體情況而定。比如，人員比較緊張的項目中，主要的架構(gòu)設(shè)計人員可能也要擔(dān)任編碼人員的角色，下一次迭代的架構(gòu)設(shè)計就可能要等到編碼工作的高峰期過了之后。可是，多次的交錯迭代就可能產(chǎn)生版本的問題。比如，本次的迭代的編碼中發(fā)現(xiàn)了架構(gòu)的一個問題，反饋給架構(gòu)設(shè)計組，但是架構(gòu)設(shè)計組已經(jīng)根據(jù)偽修改的本次迭代的架構(gòu)開始了下一次迭代的架構(gòu)設(shè)計，這時候就會出現(xiàn)不同的設(shè)計之間的沖突問題。這種情況當然可以通過加強對設(shè)計模型的管理和引入版本控制機制來解決，但肯定會隨之帶來管理成本上升的問題，而這是不符合敏捷的思想的。這時候，團隊設(shè)計就體現(xiàn)了他的威力了，這也是我們在團隊設(shè)計中沒有提到的一個原因。團隊設(shè)計通過完全的溝通，可以解決架構(gòu)設(shè)計中存在沖突的問題。
迭代頻率
XP提倡迭代周期越短越好（XP建議為一到兩周），這是個不錯的提議。在這么短的一個迭代周期內(nèi)，我們花在架構(gòu)設(shè)計上的時間可能就只有一兩個小時到半天的時間。這時候，會有一個很有意思的現(xiàn)象，你很難去區(qū)分架構(gòu)設(shè)計和設(shè)計的概念了。因為在這么短的一個周期之內(nèi)，完成的需求數(shù)量是很少的，可能就只有一兩個用例或用戶素材。因此，這幾項需求的設(shè)計是不是屬于架構(gòu)設(shè)計呢？如果是的話，由于開發(fā)過程是由多次的迭代組成的，那么開發(fā)過程中的設(shè)計不都屬于架構(gòu)設(shè)計了嗎？我們說，架構(gòu)是一個相對的概念，是針對范圍而言的，在傳統(tǒng)的瀑布模型中，我們可以很容易的區(qū)分出架構(gòu)設(shè)計和普通設(shè)計，如果我們把一次迭代看作是一個單獨的生命周期，那么，普通的設(shè)計在這樣一個范圍之內(nèi)也就是架構(gòu)設(shè)計，他們并沒有什么兩樣。但是，迭代周期中的架構(gòu)設(shè)計是要遵循一定的原則的，這我們在下面還會提到。
我們希望迭代頻率越快越好，但是這還要根據(jù)現(xiàn)實的情況而定。比如數(shù)據(jù)倉庫項目，在項目的初期階段，我們不得不花費大量的時間來進行數(shù)據(jù)建模的工作，這其實也是一項專門針對數(shù)據(jù)的架構(gòu)設(shè)計，建立元數(shù)據(jù)，制定維，整理數(shù)據(jù)，這樣子的過程很難分為多次的迭代周期來實現(xiàn)。
如何確定軟件的迭代周期
可以說，如果一支開發(fā)團隊沒有相關(guān)迭代的概念，那么這支團隊要立刻實現(xiàn)時隔兩周迭代周期是非常困難的，，同時也是毫無意義的。就像我們在上面討論的，影響迭代周期的因素很多，以至于我們那無法對迭代周期進行量化的定義。因此我們只能從定性的角度分析迭代周期的發(fā)展。
另一個了解迭代的方法是閱讀XP的相關(guān)資料，我認為XP中關(guān)于迭代周期的使用是很不錯的一種方法，只是他強調(diào)的如此短的迭代周期對于很多的軟件團隊而言都是難以實現(xiàn)的。
迭代周期的引入一定是一個從粗糙到精確的過程。迭代的本質(zhì)其實是短周期的計劃，因此這也是迭代周期越短對我們越有好處的一大原因，因為時間縮短了，計劃的可預(yù)測性就增強了。我們知道，計劃的制定是依賴于已往的經(jīng)驗，如果原先我們沒有制定計劃或細節(jié)計劃的經(jīng)驗，那么我們的計劃就一定是非常粗糙，最后的誤差也一定很大。但是這沒有關(guān)系，每一次的計劃都會對下一次的計劃產(chǎn)生正面的影響，等到經(jīng)驗足夠的時候，計劃將會非常的精確，最后的誤差也會很小。
迭代周期的確定需要依賴于單位工作量。單位工作量指的是一定時間內(nèi)你可以量化的最小的績效。最簡單的單位工作量是每位程序員一天的編碼行數(shù)?？上э@示往往比較殘酷，團隊中不但有程序員的角色，還有設(shè)計師、測試人員、文檔制作人員等角色的存在，單純的編碼行數(shù)是不能夠作為的統(tǒng)計依據(jù)的。同樣，只強調(diào)編碼行數(shù)，也會導(dǎo)致其它的問題，例如代碼質(zhì)量。為了保證統(tǒng)計的合理性，比較好的做法是一個團隊實現(xiàn)某個功能所花費的天數(shù)作為單位工作量。這里討論的內(nèi)容實際是軟件測量技術(shù)，如果有機會的話，再和大家探討這個問題。
在軟件生命周期中，我們?nèi)绾螌Υ軜?gòu)設(shè)計的發(fā)展？
架構(gòu)設(shè)計往往發(fā)生在細節(jié)需求尚未完成的時候進行的。因此，隨著項目的進行，需求還可能細化，可能變更。原先的架構(gòu)肯定會有不足或錯誤的地方。那么，我們應(yīng)該如何對待原先的設(shè)計呢？
我們在簡單設(shè)計模式中簡單提到了"Planned Design"和"Evolutionary Design"的區(qū)別。XP社團的人們推崇使用"Evolutionary Design"的方式，在外人看來，似乎擁護者們從來不需要架構(gòu)的設(shè)計，他們采用的方式是一開始就進入代碼的編寫，然后用Refactoring來改進代碼的質(zhì)量，解決未經(jīng)設(shè)計導(dǎo)致的代碼質(zhì)量低下的功能。
從一定程度上來說，這個觀點并沒有錯，它強調(diào)了代碼對軟件的重要性，并通過一些技巧（如Refactoring）來解決缺乏設(shè)計的問題。但我并不認同"Evolutionary Design"的方式，在我看來，一定程度上的"Planned Design"是必須的，至少在中國的軟件行業(yè)中，"Planned Design"還沒有成為主要的設(shè)計方向。借用一句明言，"凡事預(yù)則立，不預(yù)則廢"，在軟件設(shè)計初期，投入精力進行架構(gòu)的設(shè)計是很有必要的，這個架構(gòu)是你在后續(xù)的設(shè)計、編碼過程中依賴的基礎(chǔ)。但是，一開始我們提到的設(shè)計改進的問題依然存在，我們?nèi)绾谓鉀Q它呢？
在簡單設(shè)計模式中，我們提到了設(shè)計改進的必要性，但是，如果沒有一種方法去控制設(shè)計的改進的話，那么設(shè)計改進本身就是一場噩夢。因此，何時改進，怎么改進， 如何控制，這都是我們需要面對的問題。
解決方法
為了實現(xiàn)不斷的改進，我們將在開發(fā)流程中引入迭代的概念。迭代的概念在《需求的實踐》中已經(jīng)提到，這里我們假設(shè)讀者已經(jīng)有了基本的迭代的概念。
軟件編碼之前的工作大致可以分為這樣一個工作流程：
上圖中的流程隱含著一個信息的損失的過程。來自于用戶的需求經(jīng)過整理之后，開發(fā)人員就會從中去掉一些信息，同樣的事情發(fā)生在后面的過程中，信息丟失或變形的情況不斷的發(fā)生。這里發(fā)生了什么問題？應(yīng)該說，需求信息的失真是非常普遍的，我們?nèi)鄙俚氖且环N有效的辦法來抑止失真，換句話說，就是缺少反饋。
如果把眼睛蒙上，那我們肯定沒有辦法走出一條很長的直線。我們走路的時候都是針對目標不斷的調(diào)整自己的方向的。同樣的，漫長的軟件開發(fā)過程如果沒有一種反饋機制來調(diào)整方向，那最后的軟件真是難以想象。
所以我們引入了迭代周期。
初始設(shè)計和迭代設(shè)計
在團隊設(shè)計中，我們一直在強調(diào)，設(shè)計組最開始得到的設(shè)計一定只是一個原始架構(gòu)，然后把這個原始架構(gòu)傳播到每一位開發(fā)者的手中，從而在開發(fā)團隊中形成共同的愿景。（愿景（Vision）：源自于管理學(xué)，表示未來的愿望和景象。這里借用來表示軟件在開發(fā)人員心中的樣子。在后面的文章中我們會有一個章節(jié)專門的討論架構(gòu)愿景。）
迭代（Iterate）設(shè)計，或者我們稱之為增量（Incremental）設(shè)計的思想和XP提倡的Evolutionary Design有異曲同工之妙。我們可以從XP、Crystal、RUP、ClearRoom等方法學(xué)中對比、體會迭代設(shè)計的精妙之處：每一次的迭代都是在上一次迭代的基礎(chǔ)上進行的，迭代將致力于重用、修改、增強目前的架構(gòu)，以使架構(gòu)越來越強壯。在軟件生命周期的最后，我們除了得到軟件，還得到了一個非常穩(wěn)定的架構(gòu)。對于一個軟件組織來說，這個架構(gòu)很有可能就是下一個軟件的投入或參考。
我們可以把早期的原始架構(gòu)當作第一次迭代前的早期投入，也可以把它做為第一次迭代的重點，這些都是無所謂的。關(guān)鍵在于，原始架構(gòu)對于后續(xù)的架構(gòu)設(shè)計而言是非常重要的，我們討論過架構(gòu)是來源于需求的，但是原始架構(gòu)應(yīng)該來源于那些比較穩(wěn)定的需求。
TIP：現(xiàn)實中迭代設(shè)計退化為"Code and Fix"的設(shè)計的情況屢見不鮮（"Code and Fix"參見簡單設(shè)計）。從表面上看，兩者的做法并沒有太大的差別，都是針對原有的設(shè)計進行改進。但是，二者效果的差別是明顯的："Code and Fix"是混沌的，毫無方向感可言，每一次的改進只是給原先就已搖搖欲墜的積木上再加一塊積木而已。而迭代設(shè)計的每一次改進都朝著一個穩(wěn)定的目標在前進，他給開發(fā)人員帶來信心，而不是打擊。在過程上，我們說迭代設(shè)計是在控制之下的。從實踐的經(jīng)驗中，我們發(fā)現(xiàn)，把原該在目前就該解決的問題退后是造成這一問題的主要原因之一。因此，請嚴格的對待每一次的迭代，確保計劃已經(jīng)完成、確保軟件的質(zhì)量、確保用戶的需求得到滿足，這樣才是正統(tǒng)的迭代之路。
單次的迭代
我們說，每一次的迭代其實是一個完整的小過程。也就是說，它同樣要經(jīng)歷文章中討論的這些過程模式。只不過，這些模式的工作量都不大，你甚至可以在很短的時間內(nèi)做完所有的事情。因此，我們好像又回到了文章的開頭，重新討論架構(gòu)設(shè)計的過程。
單次迭代最令我們興奮的就是我們總是可以得到一個在當前迭代中相當穩(wěn)定的結(jié)果，而不像普通的架構(gòu)設(shè)計那樣，我們深怕架構(gòu)會出現(xiàn)問題，但又不得不依賴這個架構(gòu)。從心理上來分析，我們是在持續(xù)的建設(shè)架構(gòu)中，不需要回避需求的變更，因為我們相信，在需求相對應(yīng)的迭代中，會繼續(xù)對架構(gòu)進行改進。大家不要認為這種心理的改變是無關(guān)緊要的，我起初并沒有意識到這個問題，但是我很快發(fā)現(xiàn)新的架構(gòu)設(shè)計過程仍然籠罩在原先的懼怕改變的陰影之下的時候，迭代設(shè)計很容易就退化為"Code and Fix"的情形。開發(fā)人員難以接受新方法的主要原因還是在心理上。因此，我不得不花了很多的時間來和開發(fā)人員進行溝通，這就是我現(xiàn)實的經(jīng)驗。
迭代的交錯
基于我們對運籌學(xué)的一點經(jīng)驗，迭代設(shè)計之間肯定不是線性的關(guān)系。這樣說的一個原因架構(gòu)設(shè)計和后續(xù)的工作間還是時間差的。因此，我們不會傻到把時間浪費在等待其它工作上。一般而言，當下一次迭代的需求開始之后，詳細需求開始之前，我們就已經(jīng)可以開始下一次迭代的架構(gòu)設(shè)計了。
各次迭代之間的時間距離要視項目的具體情況而定。比如，人員比較緊張的項目中，主要的架構(gòu)設(shè)計人員可能也要擔(dān)任編碼人員的角色，下一次迭代的架構(gòu)設(shè)計就可能要等到編碼工作的高峰期過了之后。可是，多次的交錯迭代就可能產(chǎn)生版本的問題。比如，本次的迭代的編碼中發(fā)現(xiàn)了架構(gòu)的一個問題，反饋給架構(gòu)設(shè)計組，但是架構(gòu)設(shè)計組已經(jīng)根據(jù)偽修改的本次迭代的架構(gòu)開始了下一次迭代的架構(gòu)設(shè)計，這時候就會出現(xiàn)不同的設(shè)計之間的沖突問題。這種情況當然可以通過加強對設(shè)計模型的管理和引入版本控制機制來解決，但肯定會隨之帶來管理成本上升的問題，而這是不符合敏捷的思想的。這時候，團隊設(shè)計就體現(xiàn)了他的威力了，這也是我們在團隊設(shè)計中沒有提到的一個原因。團隊設(shè)計通過完全的溝通，可以解決架構(gòu)設(shè)計中存在沖突的問題。
迭代頻率
XP提倡迭代周期越短越好（XP建議為一到兩周），這是個不錯的提議。在這么短的一個迭代周期內(nèi)，我們花在架構(gòu)設(shè)計上的時間可能就只有一兩個小時到半天的時間。這時候，會有一個很有意思的現(xiàn)象，你很難去區(qū)分架構(gòu)設(shè)計和設(shè)計的概念了。因為在這么短的一個周期之內(nèi)，完成的需求數(shù)量是很少的，可能就只有一兩個用例或用戶素材。因此，這幾項需求的設(shè)計是不是屬于架構(gòu)設(shè)計呢？如果是的話，由于開發(fā)過程是由多次的迭代組成的，那么開發(fā)過程中的設(shè)計不都屬于架構(gòu)設(shè)計了嗎？我們說，架構(gòu)是一個相對的概念，是針對范圍而言的，在傳統(tǒng)的瀑布模型中，我們可以很容易的區(qū)分出架構(gòu)設(shè)計和普通設(shè)計，如果我們把一次迭代看作是一個單獨的生命周期，那么，普通的設(shè)計在這樣一個范圍之內(nèi)也就是架構(gòu)設(shè)計，他們并沒有什么兩樣。但是，迭代周期中的架構(gòu)設(shè)計是要遵循一定的原則的，這我們在下面還會提到。
我們希望迭代頻率越快越好，但是這還要根據(jù)現(xiàn)實的情況而定。比如數(shù)據(jù)倉庫項目，在項目的初期階段，我們不得不花費大量的時間來進行數(shù)據(jù)建模的工作，這其實也是一項專門針對數(shù)據(jù)的架構(gòu)設(shè)計，建立元數(shù)據(jù)，制定維，整理數(shù)據(jù)，這樣子的過程很難分為多次的迭代周期來實現(xiàn)。
如何確定軟件的迭代周期
可以說，如果一支開發(fā)團隊沒有相關(guān)迭代的概念，那么這支團隊要立刻實現(xiàn)時隔兩周迭代周期是非常困難的，，同時也是毫無意義的。就像我們在上面討論的，影響迭代周期的因素很多，以至于我們那無法對迭代周期進行量化的定義。因此我們只能從定性的角度分析迭代周期的發(fā)展。
另一個了解迭代的方法是閱讀XP的相關(guān)資料，我認為XP中關(guān)于迭代周期的使用是很不錯的一種方法，只是他強調(diào)的如此短的迭代周期對于很多的軟件團隊而言都是難以實現(xiàn)的。
迭代周期的引入一定是一個從粗糙到精確的過程。迭代的本質(zhì)其實是短周期的計劃，因此這也是迭代周期越短對我們越有好處的一大原因，因為時間縮短了，計劃的可預(yù)測性就增強了。我們知道，計劃的制定是依賴于已往的經(jīng)驗，如果原先我們沒有制定計劃或細節(jié)計劃的經(jīng)驗，那么我們的計劃就一定是非常粗糙，最后的誤差也一定很大。但是這沒有關(guān)系，每一次的計劃都會對下一次的計劃產(chǎn)生正面的影響，等到經(jīng)驗足夠的時候，計劃將會非常的精確，最后的誤差也會很小。
迭代周期的確定需要依賴于單位工作量。單位工作量指的是一定時間內(nèi)你可以量化的最小的績效。最簡單的單位工作量是每位程序員一天的編碼行數(shù)?？上э@示往往比較殘酷，團隊中不但有程序員的角色，還有設(shè)計師、測試人員、文檔制作人員等角色的存在，單純的編碼行數(shù)是不能夠作為的統(tǒng)計依據(jù)的。同樣，只強調(diào)編碼行數(shù)，也會導(dǎo)致其它的問題，例如代碼質(zhì)量。為了保證統(tǒng)計的合理性，比較好的做法是一個團隊實現(xiàn)某個功能所花費的天數(shù)作為單位工作量。這里討論的內(nèi)容實際是軟件測量技術(shù)，如果有機會的話，再和大家探討這個問題。