敏捷開發VS傳統軟體工程

標籤：理解   bug   而且   時間   撰寫   問題   style   簡單   判斷   

　　在1960年代中期軟體危機爆發之後，人們就在對軟體的生產方式進行著不斷地探索，以期找到更加高效，科學的軟體開發方式，來提高軟體的生產率，提升軟體的品質。於是便有了隨後提出的軟體工程的概念。於是我們在現在的軟體開發過程中，或者在軟體工程課程老師的介紹中，就會看到這樣的一種開發模式：在項目前期將調研工作儘可能做到面面俱到，客戶的需求以合約的方式進行“凍結”，在這些需求確定和調查的基礎之上，可以開始進行初步的軟體開發計劃書的說明，隨後進行需求分析，系統設計等等。開發過程中或許會有迭代，但通常客戶只有在測試或者培訓時才會看到產品的真容。為了保證開發過程的正確性以及產品的按時交付，在每一項任務開發之前，還要撰寫內容詳盡的設計以及測試文檔等。這種軟體開發方法在軟體危機爆發之後一定程度上提高了開發的規範性，可靠性，面對複雜軟體的設計，也可根據各類文檔中對各個功能模組的劃分，然後任務分配的個人完成協同開發。然而進入21世紀之後，資訊行業的迅猛發展也帶來了軟體產業的大繁榮，也因此市場的競爭更加激烈，產品開發週期也需要相應的縮短。面對越來越多的軟體開發項目，傳統的軟體工程似乎不再像提出之初那樣是一顆“靈丹妙藥”，於是便有了後來提出的敏捷開發，。那麼究竟出了什麼問題呢？敏捷開發能夠有效面對所有的開發情境嗎？

　　為了對這個問題進行深入的瞭解，首先我們需要知道軟體開發是幹嘛的，什麼樣的軟體能夠被稱作一個好的軟體。所謂的軟體開發，實質就是把使用者的需求轉化為能滿足需求的可執行代碼的一個過程，轉化之後的好壞怎麼判斷，沒有絕對的標準，但是我們可以從普遍的使用者反饋上總結出以下幾點：

（1）     正確性：軟體的正確性是指軟體按照需求能夠正確執行任務，並且得到正確的反饋或者結果的能力。這無疑是軟體品質的第一保證。簡單試想一下，如果你開發出的計算機軟體運算的結果都不正確，能夠被稱作一個好的軟體嗎？

（2）     可靠性：可靠性根據IEEE的規定，包含兩個方面的含義。一方面是指在規定的時間周期內程式執行所要求功能的能力，這與軟體的正確性相關；另一方面是指在規定條件和規定時間內，軟體不引起系統失效的機率，這裡主要牽涉到程式的健壯性，即系統如果出現了某種意外軟體能夠按照預定的方式進行適當的處理，從而避免出現嚴重的後果。比如說銀行的賬戶管理系統，你再執行轉賬操作時，一方的錢你已經扣掉了，但此時機器故障，比如斷電等，那麼就要考慮如何處理這種意外情況，避免出現一方的錢少了，另一方錢沒到的情況。

　　但是一個軟體能夠滿足使用者的需求並且得到正確的結果，執行過程總遇到意外情況能夠有效處理，這樣就能稱得上一個好軟體了嗎？顯然這樣只是滿足了最基本的要求，你可以交付你的產品了，然而並不能稱為這是一個好軟體。還應當考慮到軟體的效率（需要佔用多大空間啊，執行一個任務需要花多少時間啊等），在不同平台上的適應情況（當然軟體也可以不跨平台），是否簡明易用等等因素，這裡不再一一列舉。

　　知道了什麼是一個好的軟體，或者說能夠滿足基本要求的軟體之後，我們再來看依據傳統軟體開發方法，我們是否能夠充分利用現有的資源，正確高效地設計出一個好軟體。

　　我們採用傳統軟體工程中的瀑布式開發模型來對開發過程進行說明，傳統的軟體工程一個項目從開始到結束基本包含以下幾個基本階段：

　　過程中每一個階段的結果作為下一個階段的輸入，下個階段的執行情況再進行反饋，對上個階段進行相應的調整。但是這樣的一個模式或者說開發方法有著很明顯的缺點。首先軟體開發過程是基於項目開始時進行正確的估計和設計進行的，因此在開發進行到一定階段時，才會進行測試，這時發現的bug很可能是在設計之初被忽略的嚴重的問題，甚至影響到整個系統的構造。然後項目進行中會撰寫各種各樣的文檔，設計時必須嚴格按照文檔進行，但是實際設計中變更是無處不在的，這包括需求，設計，代碼，測試各個方面，因此完全按照文檔進行開發並不太現實。最後，客戶見到產品是在整個過程結束之時，但是客戶畢竟不參與到設計中，他陳述的需求和設計人員理解的需求，或者說實現方式，並不一致，這就導致了產品開發出來，但是客戶卻不買賬，此時再推翻重新設計，為時已晚。這些缺點是顯而易見的，從無數個軟體的開發過程中就可以看到這點，歸根結底，原因就是情況一致在發生改變，而你進行的設計還在基於之前某個時間點的理解進行。並不是說使用這種開發模式不能夠開發出一個好的軟體，團隊能力卓越，當然可以，然而並不是每個團隊都有這樣的遠見以及卓越的能力。

　　接下來我們再看敏捷開發。看名字就能夠理解這種開發方法具有的一個特點，“快”。所謂的敏捷開發，我個人認為其核心的思想就是在儘可能早的情況下推出一款可以使用的軟體，可能並沒有完成使用者的所有需求，設計也不夠完美，但是這隻是整個過程中的一次迭代。使用者通過使用軟體，提供反饋，從而參與到每次迭代過程中，迭代之間使用者當然可以更改現有的需求，也可以提出新的需求。敏捷開發出了這一點，當然還有別的要求，具體讀者可以參見敏捷開發的十二條準則，這裡筆者不再贅述。那麼我們來看看敏捷開發是如何解決傳統軟體工程中遇到的問題的呢。首先一點就是由於這是一種迭代增量的開發模式，每個迭代結束之時，使用者就能夠及時接觸到產品，並且對需求進行明確，因此使用者需求的不明確的問題會隨著開發的進行逐步被解決。然後就是測試參與的太晚導致嚴重bug發現過晚，從而導致項目進展不能按預期進行的問題。在敏捷開發中，項目被解構成具有各個功能的子模組，每個子模組都具備可整合和可啟動並執行特點，因此可將測試滲透到每個開發過程中。另外，敏捷開發的一個特點是以測試來驅動的，也就是說，在瞭解了需求之後，首先根據需求來進行測試代碼的編寫，然後編寫相關代碼能夠滿足這些測試案例。可以說，敏捷開發中所認識到世界更加符合現實世界的常態，情況是時刻進行變化，需要能夠及時認識到變化，並且及時作出應對才能夠跟得上發展的步伐。但是敏捷開發並不是沒有缺點的，當面對的項目比較巨大時，可能我們很難對項目進行模組劃分。而且隨著項目的增大，團隊的規模也需要相應的增加，這時團隊中負責各個模組的小組之間的交流也就變得更加困難，使得模組之間的整合變得困難。

　　其實關於這兩種開發方法，在查閱資料瞭解的過程中，看到一個比喻非常合適。傳統開發方式就像普通火炮，而敏捷開發就像是制導飛彈。普通火炮打擊目標是，要想命中，就要開始瞄的准而且對目標的運動軌跡進行準確的預測，即使如此，發射之後還是會受到風向風速，突然出現的障礙物等的影響。而制導飛彈只要在發射時設好目標，就可以在行進過程中根據目標對自身的運動狀態進行調整，最終命中目標。當然這個比喻有些許片面，但是相信對於兩者開發過程的理解還是很形象的。

敏捷開發VS傳統軟體工程