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

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

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

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

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

　　小型項目是不是還需要設計？

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

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

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

　　什么是好需求？

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