專案做到這個程度了，突然要改需求，改邏輯，這無疑是給程式設計師們最狠的一擊，但是沒有辦法，只能照做，因為你是程式設計師。
前期的專案要求其實本身就不明確，但是上峰一聲令下，我就揹負著使命深扎客戶陣營，開始了操蛋的開發；從開始的動畫實現，到最後整個ui的成型，再到後來的資料模擬，網路請求資料，ui互動、顯示，每做一步都令自己身心憔悴，可能是自己沒做過這方面的東西，加上手頭人手不夠，只能我自己扛著。感覺每次對自己**進行重構，都彷彿是對自己手術一樣心痛。
開始預訂的資料來源是從網路拉下來放到本地資料庫快取，然後查詢本地；但是後台方面太忙了沒時間搭理我們，只能用視覺化工具進行資料模擬了；好的，那我也忍了；然後到後來資料庫又多加了個字段，進行層級查詢！我也忍了，期間蛋疼的修改過程讓自己水平得到了質的提公升！因為每當自己感覺到面對的是乙個無法抗拒的問題的時候，挑戰過後就是自己的昇華！是不是應該這麼的開朗跟樂觀呢？
今天上峰突然跟我說資料來源變了！每次查詢操作都是從後台獲取資料！我了個天，這不是意味著自己辛苦拼湊的演算法、邏輯都要重新整理麼？難度是降低了，但是卻增加了些未知的問題，這麼大的資料量請求，快慢不說，使用者體驗能好麼？ 恐怕這個不是我能決定的，得看他們的最終方案，反正自己先著手準備著好了，到真正用到的時候再做必要分支，**版本控制要做好！
到現在為止，自己感覺都沒什麼脾氣了，似乎已經習慣了需求的突然變更，就好像到特定時間就必然會出現的插曲一般，司空見慣了；然後讓我預估工作量，我能說什麼呢，看了看，1-2周吧，反正後台介面沒開發好，自己先看著其他東西吧；其實專案最大的收穫是對自己全面一次檢驗，抗壓性-忍耐力-鑽研勁兒-信心提公升-分享喜悅的心情；畢竟還算處在開始階段，慢慢的就好了，如果3年內自己沒有個質的飛躍，那接下來自己就難嘍、 呵呵
需求變更嘛，說白了，就是在適當時候對自己的程式架構可擴充套件性的一次檢驗，看看彈性怎麼樣，我對自己的**邏輯還是比較滿意的，當然期間也耗費了不少心血，重構真的很有必要！
需求變更的代價和如何減少需求變更
需求變更的代價 一般來講，需求的變更通常意味著需求的增加，需求的減少相對很少，而且處理需求減少方面的問題也比較容易。當客戶提出新需求的時候，專案開發人員應該分析這些新需求對專案現階段帶來的風險，得出雙方實現變更需求的需要的成本，包括時間 人力 資源等等方面。變更都是有代價的，應該評估一下變更的代價和...
需求變更管理
需求變更 是業界公認的專案管理重大挑戰，尤其是專案後期產生的需求變更，對專案的影響是非常大的。但是，需求開發不可能做到完美無瑕，而且隨著客戶對專案和系統的了解，很有可能提出新的需求或者對原有的需求作出修正。因此，需求的變化是不可避免的。對於如何應對需求變更，主要的思路有兩條 首先是從源頭做起，提高需...
需求變更的煩惱
客戶今天要求變更需求，加某某功能，這個應該不難吧，某某公司的產品都有這個功能的。客戶的需求一直在變，煩惱。開始是需求不明確，客戶都不知道要做成什麼樣，只有乙個大概的粗略的描述。等到大樓蓋好了，給客戶，卻發現大樓應該是這樣那樣的。客戶方和開發方在一起 workshop 還好，如果分開在兩地就更糟糕。永...