軟件系統隨着業務的發展，變得越來越複雜，不同領域的業務所涉及到的知識、內容、問題非常非常多。如果每次都從頭開發，那都是一個很漫長的事情，且並不一定能將它做好。團隊協作開發時，沒有了統一標準，大家各寫各的，同樣的重複的功能到處都是。由於沒有統一調用規範，很難看懂別人寫的代碼，出現Bug或二次開發維護時，根本無從下手。（無框架不堪回首的黑暗日子請看前面章節的講述）
而一個成熟的快速開發框架，它是模板化的代碼，它會幫我們實現很多基礎性的功能，我們只需要專心的實現所需要的業務邏輯就可以了。而很多底層功能操作，就可以完完全全不用做太多的考慮，快速開發框架已幫我們實現了。這樣的話，整個團隊的開發效率可想而知。另外對於團隊成員的變動，也不用太過擔心，快速開發框架的代碼規範讓我們能輕鬆的看懂其他開發人員所寫的代碼。
搭建快速開發框架時，我們要如何定位
是不是快速開發框架的擴展性、可移值性、功能越強大就越好呢？
好的快速開發框架是相對的，它都有自己特定的應用領域，合適纔是最好。
個人覺得在實際開發中要根據具體情況來看的，因爲功能越全面它的複雜度就越大，所需要的開發人員能力和技能就會要求更高，付出的成本也就最大。比如做一個還未發展起來的電商網就想 將系統做成像京東那樣，直接用京東分模塊分佈式的框架來開發，那得怎麼來組建這個團隊？更不用說開發成本了。就算團隊有能力做到，也沒有那個必要這麼去做，因爲從成本預算和開發週期等方面來看，得不嘗失，更多的可能項目還未完成公司就給拖垮了。
一般來說，一箇中小型項目，1到5人左右的開發團隊，使用一般的三層結構就可以了，不用去細想框架要分三層還是五層，每個層之間要怎麼實現解耦，要用什麼設計模式.....因爲當今飛速發展的互聯網時代，快纔是王道，做一箇中小型項目能用一週完成的，絕不能拖了一個月還未做完。人工與時間成本纔是重點中 的重點，唯有快才能更好的生存下來並壯大。至於擴展功能、接口、分佈式、併發、大數據......等等問題，實際上過早考慮太多並不是好事情，有經驗的程序員在寫這個快速開發框架時早已留下擴展方案或思路，而沒到這一層次的開發人員你想再多也可能想不明白，還不如先做出來積累一定經驗後再慢慢學習，慢慢升級框架。
當然也不是說設計框架時不用考慮高內聚低耦合，而是要根據自己的能力與經驗來設計出自己能把控的框架出來。因爲框架不是開發出來後就不再變動，它也需要不停的進行升級，將你所學到的新知識新技術融合到框架中，使它的功能更加強大，更加健壯。而對於自己不能把控的快速開發框架，在團隊協作開發和上生產環境後，你就發現有一大堆的坑等着你去填埋，這種框架只能拿來先練練手，有空再慢慢完善。
快速開發框架通過小步快跑，不斷的迭代升級來慢慢擴展的，當項目上生產環境後，根據新的需求和所碰到的問題，去不停的調整，最終越來越強大。所有框架都是從1.0版本到2.0、3.0......發展而來，而不是直接跳過最初版本到最終成熟版本。
所以說我們在創建一個框架時，必須根據我們當前個人的技術能力、團隊成功技術水平、時間、投入成本、項目現狀（規模與需求複雜程度）、以後的發展前景來決定所要開發的框架的最終設計方案。當然也不是說不能一步到位，心有多大世界就有多大，只要個人能力和團隊能力配得上，老闆資金成本雄厚，時間充足，直接上大項目使用超級框架也完全沒有問題。