每個人走過來的道路都是不一樣的，經歷過的專案都是不一樣的。雖然我的大學是計算機專業，但是理論上的東西學的不多，也不系統。我主要是實踐，就是寫**了。上學的時候很喜歡寫**，把自己的想法變成**，執行出來，實現自己想要的效果。我都是先寫**，做測試然後再去尋找理論依據。一直到現在我也是真麼做的。
上班之後，當老闆、客戶提出需求的時候，我首先要做到的就是用編碼的方式來搞定，而不是理論的方式。畢竟老闆、客戶要的是能用的程式，而不是漂亮的理論。寫不出來**，實現不了老闆、客戶要的東西，飯碗不就沒有了嗎？
所以我是實踐派，就是寫**，用**來實現。而我又是很懶的，不願意寫那麼多的**，尤其是重複的**，不願意做那麼多的判斷（比如許可權判斷），所以我就想辦法去「偷懶」，於是寫了乙個大堆的自定義控制項、類庫，後來整理了一下，自然框架就誕生了。
如何應對需求變更？首先需求變更也得有點普吧，如果客戶想要把石頭變成金子，那是傳說中的點金術，去看yy**吧。如果客戶想把恐龍變成美女，那麼去網聊吧。我們討論問題要現實一點、實際一點，不要抬槓對吧。
需求變化了，**勢必要進行一些改動，才能應對客戶的需求。我所想要做到的就是「**改動的盡量的少」——很原始的想法。
當需求變化了，我只需要做最少的改動就可以滿足客戶的需求變化，甚至是不需要我去改**就可以實現。
我可沒有去追求能夠把石頭變成**的方法，也沒有去追求「銀彈」，我的想法很簡單、很原始，也很實際那就是 ——少改點**！
那麼如何少改點**呢？我的做法有兩個：一是寫自定義控制項，把不變的**都「提煉」到控制項裡面，在控制項裡實現，其他的地方呼叫一下就可以了。如果要修改的話，也是只需要改控制項內部**就可以了。這樣就盡可能的少改**。
二是根據配置資訊實現一些功能。orm不是有乙個xml嗎？o和r是如何對應的就靠這個xml裡的內容進行對應的，那麼如果有什麼變動，只需要改xml，而不需要改**了。我的想法也是這樣，只是沒有用xml，也不僅僅侷限於「持久化」。而是涉及整個專案，不過請注意，不包括業務邏輯。複雜的業務邏輯是不可能配置出來的，簡單的業務邏輯倒是可以，不過這個「簡單的業務邏輯」如何來定義或者是劃分，那就是乙個問題了。
那麼我能夠配置出來什麼？資料列表、分頁、查詢、表單。也就是簡單的增刪改查。現在的自然框架對於簡單的增刪改查都是可以配置出來的，就是說不用再寫**了。如果客戶有什麼這方面的需求，或者變更，那麼我就不用再去改**了！只需要改配置資訊。
當然了不可能所有的東西都能夠配置出來，我也沒有那個打算。我的目的只限於那些簡單的、繁瑣的、沒什麼難度的、但是又不得不寫的那些煩人的**。對於複雜的業務邏輯我是根本就沒有打算用配置的方式來實現，我也不打算讓自然框架去實現這些複雜的業務邏輯，那麼怎麼辦呢？當然是「委託」出去了，交給能夠實現的人去實現。做力所能及的事情，不要大包大攬。
對了，最後還有乙個許可權，許可權是很繁瑣的，你永遠都不知道客戶的老闆要如何去分配任務、分派人員，尤其是小公司。今天讓甲去用a功能，明天就讓甲去用b功能，而a功能又和b功能有交集，而且還有其他人也要可以用a功能。今天加乙個部門，明天又合併兩個部門。今天乙是c部門的經理，明天就是乙是d部門的經理，部門變了，那麼做的事情是不是可以跟著部門變呢？如果是的話那還好辦點，但是真的是這樣的嗎？
有首歌唱得好哇，女孩的心思男孩你別猜。所以我想說，領導的分工不要猜。領導願意讓誰去做什麼，那麼就讓他自己去設計許可權吧。當然了，領導不必勢必躬親，可以讓他的秘書去做，或者找乙個「許可權管理員」去做。總之，這是客戶的事情，程式設計師把功能（許可權管理做靈活）做好了，讓客戶（許可權管理員）自己去玩吧。
我的需求變更
最近好累啊，不停的在變更我所寫的需求說明書，覺得自己不想是個有思想的動物，只是在按照他人的想法在不停的修改，修改。回頭想起來，自己是不是乙個有想法的人呢？似乎又沒有辦法完全的回答，對於目前所處的這個領域我覺得自己真的是缺乏很多的知識，拼命的在補充自己，但是似乎沒有辦法在短時間內完全的掌握現在的工具，...
良好的設計是應對需求變更的最佳方法
良好的設計是應對需求變更的最佳方法。需求總是會變的，但是良好的設計可以適應需求的變化。設計有諸多原則，也有諸多模式可復用。不妨以點代面，拋磚引玉的來舉例來說 1.將不變的和變化的分離。構成軟體的 有些是骨架，有些是筋肉，有些則是毛髮。要識別出需求中那些要約是相對不變的，那些是臨時的，那些是會經常變化...
需求變更的代價和如何減少需求變更
需求變更的代價 一般來講，需求的變更通常意味著需求的增加，需求的減少相對很少，而且處理需求減少方面的問題也比較容易。當客戶提出新需求的時候，專案開發人員應該分析這些新需求對專案現階段帶來的風險，得出雙方實現變更需求的需要的成本，包括時間 人力 資源等等方面。變更都是有代價的，應該評估一下變更的代價和...