敏捷式軟體開發 (Agile Software Development)——一個例子：copy程式

標籤：style   blog   http   color   使用   ar   2014   sp   代碼   

和代碼顯示 應用程式中有3個模組，或者子程式。copy模組調用另外兩個模組。copy從read keyboard中擷取字元，並把字元傳遞給write printer模組。

。。。。需求在變化：

    希望copy可以從紙帶讀入機中讀入資訊：如果變數值為false，就像以前一樣從鍵盤讀取資訊。槽糕的是，現在已有許多其他程式正在使用copy程式，你不能改變copy程式的介面。改變介面會導致長時間的重新編譯和重新測試。

    打補丁：

    當然會想到使用一個全域變數的方法，結果如下：

想讓copy從紙帶讀入資訊設定ptFlag為true即可，然後再調用copy，它就會正確地從紙帶讀入資訊，一旦copy調用返回，調用者必須要重新設定ptFlag。

。。。。

需要再次改變：

客戶希望copy程式可以輸出到紙帶穿空機上。

如果繼續這樣的打補丁，軟體終會變的難以維護。

這次的設計的改動和上次的相似。只不過需要另外一個全域變數和？操作符。

—————————————————————————————————————————————————————————————————————————————

說上面的例子不是要吐槽客戶的需要改變，實際中，客戶的需要一定是會有變化的。

通過上面的例子可以看到在 變化面前程式的設計退化的速度是多麼的快。copy程式的原始設計是簡單的，是優雅的。但是僅僅經曆了兩次變更，它就已經表現出了僵化性、脆弱性和不必要的複雜性、不必要的重複急晦澀性的癥狀。

    記住，在大多數軟體項目中最不穩定的就是需求。需要處在一個持續變動的狀態之中。這是我們作為開發人員必須得接受的事實！

一個好的解決方案：

在這個例子中，在我們遇到第一個需求變化時，我們要修改設計並使修改後的設計對於那一類的需求的變化具有彈性。

    在要實現新需求時，團隊抓住這次機會去改變設計，以便設計對於將來的同類變化具有彈性，而不是設法去給設計打補丁。

敏捷式軟體開發 (Agile Software Development)——一個例子：copy程式