在我的周邊朋友身邊就發(fā)生過這樣的事情：
A君在北京從事Java開發(fā)好多年了，萌發(fā)了創(chuàng)業(yè)的念頭，想組建了一個開發(fā)團隊想大干一場。但是慢慢發(fā)現(xiàn)，構建一個有戰(zhàn)斗力的團隊真不容易。后來技術團隊的組建初步有了起色，但是技術路線卻非常難成一致意見。折騰來折騰去，把有點上道的技術人員都折騰得跳槽了。費了巨高的成本搞了一個架構師，就是利用SSH框架搭建了一個開發(fā)環(huán)境，數(shù)據(jù)量小，業(yè)務初期還是不錯的，但是當業(yè)務快速增長的時候，運行速度就無法滿足需要了。是重新來過還是在SSH的基礎上繼續(xù)折騰，非常難以抉擇！
Jenny從英國回青島大半年了，很喜歡青島這座海濱城市，空氣很好，周圍的一草一木也很親切，這也是當初為什么回來的原因之一。不過，Jenny一直在為產(chǎn)品管理的事情焦頭爛額。除了開發(fā)成本高，軟件層次一直比較低。產(chǎn)品團隊管理之外，還要考慮技能水平、分工、角色崗位、薪酬、性格特點等等，各方面都耗費了大量的時間。由于缺乏大規(guī)模的壓力測試，花了大量時間做出來的產(chǎn)品，卻不能適應海量數(shù)據(jù)下的大并發(fā)訪問。想找一些高手吧，在軟件業(yè)本來就不發(fā)達的二線城市又不太現(xiàn)實；離開二級城市轉到一級城市發(fā)展吧，又承擔不起高額的運營成本與人力資源成本，路在何方真的是個問題！
經(jīng)過大半年的籌備，阿燦的技術團隊終于組建起來了。不過，人員流動始終是個揮之不去的話題。換了人，技術方案就要換，隨之而來的維護問題也是讓人焦頭爛額！阿燦沮喪了，他怎么也想不明白，為什么新來的人就不愿意繼續(xù)在老人留下來的系統(tǒng)上進行維護和再開發(fā)呢？如果才能建得起來鐵大的營盤？
類似的故事，不勝枚舉。總結一下問題出在如下幾個方面：
從人力資源團隊的角度來講，更多考慮人員的職業(yè)道德是否符合企業(yè)文化和價值觀。而軟件開發(fā)項目經(jīng)理更多考慮的是，新成員是否能夠為軟件開發(fā)項目做出貢獻，并符合項目文化和價值觀。如果你的軟件開發(fā)團隊都不是自己親手組建起來的，你又如何能夠保證軟件開發(fā)團隊能夠按你期望的模式運作？應聘人員通過各種認證，僅僅代表具備了基本的知識體系和理論基礎。但任何認證都無法真正體現(xiàn)出每個人的學習能力和應用知識的能力，而這兩點恰恰是軟件開發(fā)項目最關心的技能。尤其是，要成為一個優(yōu)秀的軟件架構師，往往需要具備10年以上的軟件開發(fā)經(jīng)驗，入門的門檻是相當高的，尤其是在互聯(lián)網(wǎng)產(chǎn)品愈發(fā)重要的當下，一個軟件架構師往往需要掌握多項技能，他所需要的知識面會很廣，需要過程更需要時間的學習和磨練。
一個產(chǎn)品往往需要多個部門的合作，各部門溝通的有效性直接會影響到產(chǎn)品的質(zhì)量和產(chǎn)品的進度。如果技術開發(fā)人員沒有良好的交流溝通能力，可能會嚴重阻礙項目的推動。尤其是小型的團隊開發(fā)中，缺乏溝通往往會導致成員對任務內(nèi)容、要求和職責理解有誤，導致開發(fā)效率低下，甚至引發(fā)成員間的矛盾。開發(fā)人員如果不能清楚地表達工作計劃、遇到的困難、需要什么支持，會導致項目負責人無法及時掌握項目進展情況，并進行合理分配資源。在工作中時常會發(fā)生別人（通常是上級）征詢意見時不知如何表達，但被分配具體工作后又覺得自己未被尊重，從而產(chǎn)生挫折感。技術開人員大多思維能力強于交流溝通能力，性格也大多趨向于內(nèi)向，喜歡做事多于說話。如何提高自身溝通交流能力是擺在很多開發(fā)人員面前的一大難題。
作為設計師，需要保證產(chǎn)品功能的現(xiàn)實，產(chǎn)品功能的可持續(xù)性，產(chǎn)品的穩(wěn)定性及產(chǎn)品的可用性等。產(chǎn)品的這些需求都依賴于架構師對產(chǎn)品技術的規(guī)劃。架構師在接到商業(yè)需求之后，最主要的工作就是將其轉化為技術需求。這個過程的完成與架構師抽象思維的能力密不可分。好比說Tiny框架這個項目，主架構師第一個閃過的念頭多半就是：這個系統(tǒng)必須具有長期的統(tǒng)一性。而負責每一個Tiny框架功能的架構師，又需要對這些部分進行進一步的抽象化。這些往往是中小企業(yè)團隊所不具備的。由于缺乏優(yōu)秀的架構師，導致團隊在產(chǎn)品的現(xiàn)實規(guī)劃上沒有自己明確的目標和具體的可行性實施方案，缺乏統(tǒng)一的延續(xù)性，導致后期難以滿足產(chǎn)品在升級、改版方面的需要。
整天只知道大談“云計算，SaaS”這些東西的團隊，注定開發(fā)不出優(yōu)秀的產(chǎn)品。這種毛病在新的開發(fā)團隊非常常見，因為這可以忽悠更多的客戶。不過，新的技術雖好，程序員接受和再培訓還需要時間，還要考慮到系統(tǒng)的兼容性問題。因此，夸夸其談的名詞專家，往往死得更慘。尤其是出現(xiàn)大并發(fā)的數(shù)據(jù)考驗時，做出來的產(chǎn)品往往會難以滿足運營要求。
時下各種軟件系統(tǒng)發(fā)展越來越復雜，尤其是框架軟件，其涉及的問題以及知識面太多。當網(wǎng)站變大后，不可避免的需要拆分應用進行服務化，以提高開發(fā)效率，調(diào)優(yōu)性能，節(jié)省關鍵競爭資源等。當服務越來越多時，服務的URL地址信息就會爆炸式增長，配置管理變得非常困難，F(xiàn)5硬件負載均衡器的單點壓力也越來越大。當進一步發(fā)展，服務間依賴關系變得錯蹤復雜，甚至分不清哪個應用要在哪個應用之前啟動，架構師都不能完整的描述應用的架構關系。接著，服務的調(diào)用量越來越大，服務的容量問題就暴露出來，這個服務需要多少機器支撐？什么時候該加機器？等等……在遇到這些問題時，開發(fā)成本往往會正比例飛速增長，甚至讓中小企業(yè)團隊無法支撐。
想要減少開發(fā)工作量或是縮短時間，降低成本，使用框架便是一個很好的選擇。尤其是，使用質(zhì)量好且有延續(xù)性的開源框架正在成為主流！
框架節(jié)省了我們不少的時間，并且讓擴展變得更容易。由于擁有完整的生態(tài)體系，以及活躍的社區(qū)氛圍，使得團隊戰(zhàn)斗力更強！由于框架強制使用公共的約定，因此它能有效地解決一些共有的問題?？蚣苣軌蜃尮ぷ鞲B貫，也能避免我們寫一大堆自定義模塊來實現(xiàn)某些性能，我們所需要做的，就是將這些共用模塊放在框架中實現(xiàn)。以Tiny框架為例，一年的開發(fā)就需要提交數(shù)千個Commits，解決了無數(shù)個疑難雜癥。此外，從文檔維護的角度來看，一年900多頁的文檔內(nèi)容，也能夠幫助開發(fā)團隊解決許多難題。
優(yōu)秀的開源框架，通常具有高內(nèi)聚、低耦合、高質(zhì)量的代碼，專職的團隊，可以保持項目持續(xù)不斷的前進。還是以Tiny框架為例，Tiny主工程共有621個Issues，里面有需求，和改進，有BUG。由于有良好知識積累體系，使得使用Tiny框架的人們越用越強，越用越爽！相當于有一個強大的后援團隊在為你的項目服務。這些優(yōu)點，不勝枚舉。當A君在青島的海邊悠閑地喝著咖啡時，完全不用擔心客戶的跟蹤電話了。
在優(yōu)秀的開源框架體系里，由于頂層設計避免了重復勞動，所有軟件參與者都會避免做重復的事情。尤其是對于個體或小型企業(yè)，很明確，光是SSH/I已經(jīng)不足讓你的方案看起來高大上，也不足以支持業(yè)務數(shù)據(jù)量比較大的時候的應用場景，也不足以支撐居高不下的軟件開發(fā)實施成本。在優(yōu)秀的開源框架開發(fā)團隊里，整個團隊配置往往更加合理，高低水平者各司其職，使得運營成本更低、附加值也更高。以Tiny為例，正在構建的Tiny生態(tài)圈，上百個UI組件及流程組件已經(jīng)足夠你日常使用，還會有更多被不斷加入，這些完全就是超值服務了！
總之，使用質(zhì)量好有延續(xù)性的開源框架，基于開源框架做應用是未來中小型軟件公司的發(fā)展趨勢，你將獲得更加超值的回報！
掃碼關注鍍金池微信號
手機訂課，優(yōu)惠多多
