在我的周邊朋友身邊就發生過這樣的事情：

故事1：A君在北京從事Java開發好多年了，萌發了創業的念頭，想組建了一個開發團隊想大干一場。但是慢慢發現，構建一個有戰斗力的團隊真不容易。后來技術團隊的組建初步有了起色，但是技術路線卻非常難成一致意見。折騰來折騰去，把有點上道的技術人員都折騰得跳槽了。費了巨高的成本搞了一個架構師，就是利用SSH框架搭建了一個開發環境，數據量小，業務初期還是不錯的，但是當業務快速增長的時候，運行速度就無法滿足需要了。是重新來過還是在SSH的基礎上繼續折騰，非常難以抉擇！

故事2：Jenny從英國回青島大半年了，很喜歡青島這座海濱城市，空氣很好，周圍的一草一木也很親切，這也是當初為什么回來的原因之一。不過，Jenny一直在為產品管理的事情焦頭爛額。除了開發成本高，軟件層次一直比較低。產品團隊管理之外，還要考慮技能水平、分工、角色崗位、薪酬、性格特點等等，各方面都耗費了大量的時間。由于缺乏大規模的壓力測試，花了大量時間做出來的產品，卻不能適應海量數據下的大并發訪問。想找一些高手吧，在軟件業本來就不發達的二線城市又不太現實；離開二級城市轉到一級城市發展吧，又承擔不起高額的運營成本與人力資源成本，路在何方真的是個問題！

故事3：經過大半年的籌備，阿燦的技術團隊終于組建起來了。不過，人員流動始終是個揮之不去的話題。換了人，技術方案就要換，隨之而來的維護問題也是讓人焦頭爛額！阿燦沮喪了，他怎么也想不明白，為什么新來的人就不愿意繼續在老人留下來的系統上進行維護和再開發呢？如果才能建得起來鐵大的營盤？

類似的故事，不勝枚舉。總結一下問題出在如下幾個方面：

1. 人員培養速度緩慢。從人力資源團隊的角度來講，更多考慮人員的職業道德是否符合企業文化和價值觀。而軟件開發項目經理更多考慮的是，新成員是否能夠為軟件開發項目做出貢獻，并符合項目文化和價值觀。如果你的軟件開發團隊都不是自己親手組建起來的，你又如何能夠保證軟件開發團隊能夠按你期望的模式運作？應聘人員通過各種認證，僅僅代表具備了基本的知識體系和理論基礎。但任何認證都無法真正體現出每個人的學習能力和應用知識的能力，而這兩點恰恰是軟件開發項目最關心的技能。尤其是，要成為一個優秀的軟件架構師，往往需要具備10年以上的軟件開發經驗，入門的門檻是相當高的，尤其是在互聯網產品愈發重要的當下，一個軟件架構師往往需要掌握多項技能，他所需要的知識面會很廣，需要過程更需要時間的學習和磨練。

2. 人員開發效率低下。一個產品往往需要多個部門的合作，各部門溝通的有效性直接會影響到產品的質量和產品的進度。如果技術開發人員沒有良好的交流溝通能力，可能會嚴重阻礙項目的推動。尤其是小型的團隊開發中，缺乏溝通往往會導致成員對任務內容、要求和職責理解有誤，導致開發效率低下，甚至引發成員間的矛盾。開發人員如果不能清楚地表達工作計劃、遇到的困難、需要什么支持，會導致項目負責人無法及時掌握項目進展情況，并進行合理分配資源。在工作中時常會發生別人（通常是上級）征詢意見時不知如何表達，但被分配具體工作后又覺得自己未被尊重，從而產生挫折感。技術開人員大多思維能力強于交流溝通能力，性格也大多趨向于內向，喜歡做事多于說話。如何提高自身溝通交流能力是擺在很多開發人員面前的一大難題。

3. 技術架構不統一沒有延續性。作為設計師，需要保證產品功能的現實，產品功能的可持續性，產品的穩定性及產品的可用性等。產品的這些需求都依賴于架構師對產品技術的規劃。架構師在接到商業需求之后，最主要的工作就是將其轉化為技術需求。這個過程的完成與架構師抽象思維的能力密不可分。好比說Tiny框架這個項目，主架構師第一個閃過的念頭多半就是：這個系統必須具有長期的統一性。而負責每一個Tiny框架功能的架構師，又需要對這些部分進行進一步的抽象化。這些往往是中小企業團隊所不具備的。由于缺乏優秀的架構師，導致團隊在產品的現實規劃上沒有自己明確的目標和具體的可行性實施方案，缺乏統一的延續性，導致后期難以滿足產品在升級、改版方面的需要。

4. 性能不能滿足運營要求。整天只知道大談“云計算，SaaS”這些東西的團隊，注定開發不出優秀的產品。這種毛病在新的開發團隊非常常見，因為這可以忽悠更多的客戶。不過，新的技術雖好，程序員接受和再培訓還需要時間，還要考慮到系統的兼容性問題。因此，夸夸其談的名詞專家，往往死得更慘。尤其是出現大并發的數據考驗時，做出來的產品往往會難以滿足運營要求。

5. 構建開發框架成本太高無法承受。時下各種軟件系統發展越來越復雜，尤其是框架軟件，其涉及的問題以及知識面太多。當網站變大后，不可避免的需要拆分應用進行服務化，以提高開發效率，調優性能，節省關鍵競爭資源等。當服務越來越多時，服務的URL地址信息就會爆炸式增長，配置管理變得非常困難，F5硬件負載均衡器的單點壓力也越來越大。當進一步發展，服務間依賴關系變得錯蹤復雜，甚至分不清哪個應用要在哪個應用之前啟動，架構師都不能完整的描述應用的架構關系。接著，服務的調用量越來越大，服務的容量問題就暴露出來，這個服務需要多少機器支撐？什么時候該加機器？等等……在遇到這些問題時，開發成本往往會正比例飛速增長，甚至讓中小企業團隊無法支撐。

想要減少開發工作量或是縮短時間，降低成本，使用框架便是一個很好的選擇。尤其是，使用質量好且有延續性的開源框架正在成為主流！

1. 節省團隊時間和精力。框架節省了我們不少的時間，并且讓擴展變得更容易。由于擁有完整的生態體系，以及活躍的社區氛圍，使得團隊戰斗力更強！由于框架強制使用公共的約定，因此它能有效地解決一些共有的問題。框架能夠讓工作更連貫，也能避免我們寫一大堆自定義模塊來實現某些性能，我們所需要做的，就是將這些共用模塊放在框架中實現。以Tiny框架為例，一年的開發就需要提交數千個Commits，解決了無數個疑難雜癥。此外，從文檔維護的角度來看，一年900多頁的文檔內容，也能夠幫助開發團隊解決許多難題。

2. 技術支撐更有保障。優秀的開源框架，通常具有高內聚、低耦合、高質量的代碼，專職的團隊，可以保持項目持續不斷的前進。還是以Tiny框架為例，Tiny主工程共有621個Issues，里面有需求，和改進，有BUG。由于有良好知識積累體系，使得使用Tiny框架的人們越用越強，越用越爽！相當于有一個強大的后援團隊在為你的項目服務。這些優點，不勝枚舉。當A君在青島的海邊悠閑地喝著咖啡時，完全不用擔心客戶的跟蹤電話了。

3. 成本更低，附加值更高。在優秀的開源框架體系里，由于頂層設計避免了重復勞動，所有軟件參與者都會避免做重復的事情。尤其是對于個體或小型企業，很明確，光是SSH/I已經不足讓你的方案看起來高大上，也不足以支持業務數據量比較大的時候的應用場景，也不足以支撐居高不下的軟件開發實施成本。在優秀的開源框架開發團隊里，整個團隊配置往往更加合理，高低水平者各司其職，使得運營成本更低、附加值也更高。以Tiny為例，正在構建的Tiny生態圈，上百個UI組件及流程組件已經足夠你日常使用，還會有更多被不斷加入，這些完全就是超值服務了！

總之，使用質量好有延續性的開源框架，基于開源框架做應用是未來中小型軟件公司的發展趨勢，你將獲得更加超值的回報！