從一個失敗的項目說起——需求和設(shè)計

申請免費(fèi)試用、咨詢電話：400-8352-114

　　由于是一個小項目，感覺需求也簡單，再加上時間緊，如果從需求開始一步步來，時間肯定來不及，在這種情況下，項目就匆匆的開始了。為了節(jié)省時間，分層、設(shè)計等等都不去考慮了，想到哪寫到哪，完全瀑布式開發(fā)。直接結(jié)果是，完工時間一拖再拖，最后不得不決定下一版本整個推倒重來。項目失敗的原因有兩個：需求分析不到位、架構(gòu)設(shè)計不合理。

　　需求和架構(gòu)設(shè)計是相輔相成的，如果需求分析做的好，架構(gòu)設(shè)計合理，那么就可以靈活的適應(yīng)變化的需求，這是理想的狀況。如果需求好了，架構(gòu)有不合理的地方，項目也可以實(shí)現(xiàn)，只是以后的維護(hù)會有困難。架構(gòu)好了，需求沒有做好，隨著需求的進(jìn)一步完善，項目也會完成，這是容易實(shí)現(xiàn)的一種狀況。如果都沒有做好，象這個項目一樣，就只能有兩種選擇：

　　1、盡早重來，這樣雖然會推出項目的完成日期，但總的來說還是省了時間，也可以交出一個滿意的項目。

　　2、通過架構(gòu)的修補(bǔ)、需求的完善，先在規(guī)定時間交出一個不完善的版本，等下一個版本在重新開始。

　　好的需求，會加快項目的進(jìn)度，也可以給開發(fā)人員的設(shè)計提供幫助。項目開始前一定要做好需求和設(shè)計，至少要有明確的思路，匆忙開始的項目很可能會失敗，至少也會走彎路，而走彎路花的時間很可能會超過在需求和設(shè)計上省下來的時間，更不用說失敗的項目所造成的后果。需求和設(shè)計難做時，也可以先動手實(shí)現(xiàn)一個版本，讓客戶體驗，這樣可以防止設(shè)計上迷失方向，在設(shè)計上走錯路。

　　小型項目是不是還需要設(shè)計？

　　我以前一直認(rèn)為，項目小，完全可以不做任何設(shè)計，類、接口等都不用去想，分層也是不必要的，因為做設(shè)計會花時間，實(shí)現(xiàn)設(shè)計也會花比直接寫代碼（如雙擊按鈕，在事件中寫代碼，而不去掉用已經(jīng)封裝好的實(shí)現(xiàn)。）花更多的時間。簡單有效的方法就是邊想邊寫，這樣可以有最快的開發(fā)速度。但通過這個項目，我認(rèn)識到，小的項目，也可能存在你現(xiàn)在還沒有發(fā)現(xiàn)的陷阱，如果采用上面的開發(fā)方式，遇到陷阱時就不能靈活應(yīng)對，因為架構(gòu)不好。更不用說，經(jīng)常要變化的需求，等需求一變，又是頭痛的時候，還是因為架構(gòu)不好，最后設(shè)計越來越糟，到處都是重復(fù)的代碼，時間在逐漸的流逝，而項目的進(jìn)度會越來越慢，你最后發(fā)現(xiàn)，要想讓項目完美的實(shí)現(xiàn)已經(jīng)不可能了，時間都浪費(fèi)在一些重復(fù)的勞動上，而有好的架構(gòu)，這些都是可以避免的。人也會變的絕望，面對著象線團(tuán)一樣的代碼，根本沒有了工作的激情，也沒有了動力。再加上一些小項目有時候會牽扯到幾個系統(tǒng)，按照這種設(shè)計，根本沒有辦法進(jìn)行單元測試，集成測試又會耗費(fèi)太多的時間，有時根本就不能測試。結(jié)果只有痛苦的重新開賽。

　　而有好的設(shè)計，情況就會完全不同，開始會慢一些，而隨著項目的進(jìn)行，一切會逐漸的明晰，你也不會懼怕陷阱和需求的變化。看著項目在一天天的完善，心情也會開心。最好項目會成功。

　　因此，即使是小的項目設(shè)計也是十分必要的。

　　什么是好需求？

　　需求要從客戶的角度去尋找，需求是客戶要求的抽象，而不是具體的表現(xiàn)，這樣做的需求才能對以后的設(shè)計產(chǎn)生積極的影響。而一些具體的要求可能都是易變的，這些可能是商業(yè)政策，而不是真正的需求。需求總是易變的，這就要求架構(gòu)要有靈活性，靈活性不是靠提前設(shè)計實(shí)現(xiàn)“你認(rèn)為將來會有的需求”，而是靠抽象，這樣可以在需求變化時，架構(gòu)做最少的修改。從開發(fā)者角度說，需求是架構(gòu)必須要實(shí)現(xiàn)的要求，要把抽象的需求再擴(kuò)展到具體。這樣需求就經(jīng)歷了從具體（客戶的描繪）到抽象（架構(gòu)，好的需求）再到具體（實(shí)現(xiàn)）的一個過程都是自己的理解，有不合理的地方請指教，剛才圖書館借了本關(guān)于需求的書，以前對需求了解太少了，上學(xué)時學(xué)的印象不深，只有碰到問題才能加深理解。