PHP團隊選擇框架thinkphp和symfony2，我和技術總監分歧，請給予中肯意見? 謝謝

01-15

我們團隊需要開發一個在線教育項目（類似不同學科的在線輔導服務），可以簡單的理解為：網易公開課（在這個基礎上加入教師人工學習輔導），技術上並不存在難度；
主要是業務邏輯模塊的規劃，讓後期更加具備擴展；
CodeIgniter框架（小型簡易框架，超強擴展性）。
Thinkphp框架（簡潔和分組模塊，快速開發）。

Laravel PHP社區最受歡迎，Github 上最有名的PHP 項目8627 個 star, 領先第二名的 Symfony 和第三名的 CI 接近 1000個 star。
Zendframework2框架（企業級框架）php官方框架，一些大公司大企業使用，很多項目其實完全用不到ZF2這種大型框架。
symfony2框架（企業級框架）功能可以說比上面的框架還要強大。
&>&>&>&>&>&> 文字版權問題，這裡雖然有個人意見，但都是整理自網路。
團隊如何選擇一款適合的框架：
1，沒有最好的框架，只有最適合團隊的框架；

2，項目不同，需求不同，框架選擇也不同；
3，中小企業講究快速開發，快速上手，能夠提高團隊開發效率；
4，可擴展和無痛版本更新 : 核心代碼低耦合，便於擴展，框架設計有預見性，版本升級無需大功干戈
5，文檔豐富，考慮到團隊合作的情況下，都可以快速上手；
6，開發使用過程中，遇到問題能夠快速找到解決辦法，活躍的社區；
7，官方對框架的更新發布穩定，使用人群多，有成熟項目案例；
8，開發迅速 : 基礎組件齊全且不累贅，框架的設計哲學可以助人快速寫出優雅且高效地代碼（相對而言）
9，邏輯清晰 : 框架的代碼邏輯清晰，代碼的目錄結構清晰，輕鬆地協作開發和代碼重用
性能 : 大多數WEB應用無需考慮框架層面的性能問題，當你真的需要考慮框架性能問題的時候，也有很多平滑地解決方案
無重大BUG漏洞，一般來說成熟的開源框架不會有這個問題。

使用框架的好處有：
1. 利用框架提供的標準程序架構和實用的組件進行高效開發
2. 利用框架完善的文檔，有利於團隊新成員培訓和協作開發，減少溝通成本
&>&>&>&>&>&> 文字版權問題，這裡雖然有個人意見，但都是整理自網路。
目前我們團隊都熟悉使用thinphp開發項目，但現在的問題是，技術總監認為symfony2更加功能強大，靈活，前瞻性，也考慮很多成熟項目都往此框架轉型，也還由於有其他開源教學項目基於symfony2，我們可以很徹底的學習和借鑒設計和架構經驗。

我個人認為，我們小公司團隊，講究快速開發，而且大家目前熟悉thinkphp，在整體綜合thinkphp也或許能被symfony2秒殺，但thinkphp更加適合我們團隊，快速開發，thinkphp也並不差，很多國內大型站也使用的thinkphp。
臨時學習symfony2，缺少實際的項目開發經驗，缺少文檔，開發中遇到問題快速尋找解決辦法，對我們團隊非常危險，因為項目有嚴格日程。
其實我個人內心有非常明確的答案：小團隊，小公司，不大的項目，選擇自己最熟悉擅長，沒有重大缺陷的框架，快速開發，才是最適合的。
但我還是以免自己固執，期望能聽聽意見，這樣，我也能夠對自己的決策更加自信。
謝謝。

為什麼要用框架呢

首先我贊同你敢於提出自己觀點勇氣。

但是：

你要知道，無論任何框架都可以完成你所說的上述功能。

其次，你要明白有時候團隊裡面做一件事情可能有N種解決方案，但是無論選擇哪種解決方案

都需要有一個人來抉擇，來負責，他才是負責人，出了問題都是他的，你可以提出你的觀點，但你沒有權利決定，你可以辭職拒絕，但必須要有那麼一個人為團隊做出選擇，哪怕他的選擇是錯的，不然這個項目無法進行以及開展。

曾經也面對過這個問題，也曾經嘗試在公司推廣 Symfony2，我當時的狀況跟你們技術總監類似，我對Symfony2與THINKPHP都熟悉，而團隊成員都熟悉THINKPHP（不得不說，TP簡單，而且推廣得太好了，隨便找個懂PHP的都可以很快上手），遇到團隊的阻力，但不大。

首先，我希望能夠改變團隊成員對Symfony的誤解，所以我快速搭建了一個Demo，包含用戶管理、OAuth2 Client、OAuth2 Server、Restful Api、ApiDoc、SonataAdmin後台、FOSCACHE+varnish等（這些是我們業務上需要用到的功能），然後讓他們評估用THINKPHP搭建這個功能的工作量。因為都是用開源Bundle來做的，再加上有緩存，功能跟性能上都沒問題，搭建速度很快。又演示了Symfony2 CRUD的便捷、功能修改的靈活。這樣下來，大部分團隊成員都對Symfony抱著濃厚的興趣。

然後，在團隊中進行培訓，講解Symfony的依賴注入、服務容器等具有特色的特性。團隊對Symfony的興趣得到提升。

然而，問題來了。我希望團隊成員先自己搭這個Demo來折騰一下，看看Symfony上的文檔。團隊成員開始遇到各種挫折。

1）Symfony對windows環境不大友好，composer無論是連接國內還是國外的源都很慢；

2）Symfony中文文檔極度稀缺，團隊成員閱讀英文文檔吃力；

3）Symfony代碼，組件代碼太複雜，不好理解。譬如，他們不理解為何就一個ajax請求，需要做這麼多工作；定製一個表單，需要寫這麼多代碼；

然後，到了徵求大家意見階段，普遍意見都是不支持轉用Symfony，還是喜歡THINKPHP的簡單粗暴。

最後，使用了一個折中的方式，框架還是使用THINKPHP，然後引入依賴注入功能，將Symfony上面一些好用的功能以service的方式來實現。譬如：用monolog來代替自帶的Log功能，這樣可以根據日誌的不同級別做不同的記錄；配置swiftmailer服務來發送郵件，增加靈活度。

--------------------

Symfony好，但小團隊很難招到高水平的Symfony程序員（或者說小團隊很難招到高水平的PHP程序員）。

別侮辱symfony2!不是一個時代的東西。

麻痹，被thinkphp坑死了老項目真噁心

我分享一下我們的一些經歷，thinkphp上手很簡單（當時團隊剛剛開始起步，有的開發還是剛從學校出來，甚至有的學的都不是計算機相關專業，給他們報了培訓班臨時去學的），一開始雖然開發起來很順手但是坑特別的多，bug自然不用提，非mysql支持不是很好，越往後，越難受。

symfony2複雜些，上手困難，如果大家不是很熟悉容易被坑，而且依賴的開源項目中也有很多坑，symfony2用起來要想舒服最好是在mac或者linux下，終端和相關工具鏈是很方便的。如果團隊條件允許是非常建議使用symfony2的。

我們做過很長一陣子外包，最早採用thinkphp搞過一陣子，開發進度非常快，但是個把月就發現問題層出不窮，好多地方要進行各種非常費力的修正，官方社區幾乎指望不上，而且項目的穩定性不好，自動化單元測試集成等困難，交付後問題很多，維護簡直是噩夢，結合持續打包環境使用也不方便，各種方面相當相當麻煩。

最後感覺這樣子下去實在是不行了，下決心換到了symfony2，我和團隊中另外一個技術之前是用過symfony2的，而且有java下的開發經驗，所以提供了一些基礎，採取的培訓方式是我們兩個帶頭做了一個培訓提綱，做出了教案以及整理了很多資料，精選了在線教學視頻，並寫了常見的樣常式序（增刪改查，分頁，rest介面，接受rest對象並序列化，調用微信介面，發簡訊，驗證碼，雙向路由等等一系列案例），然後我們表演這個是多麼的神奇，開發起來效率多麼高，引起大家的興趣，然後大家一起去學習，後面我們兩個帶另外一個人，雙雙結對編程，然後進行開發攻堅戰，大家爆肝一起做了幾個練手項目（一個企業站，一個簡單類似知乎的小論壇，一個純rest後端帶推送，前端也插手進來進行了配合），然後大家重新上手干正事，陸陸續續廢了將近3個月，2人離職，白髮了不少工資，期間外部和內部(主要來自於銷售、項目、和湊錢的幾個同僚)壓力很大，而我當時處理的不好，沒幫大家頂住外部壓力，加上團隊稚嫩，很多內部問題也隨之放大化了，而且整個轉型時間超出了預計沒能控制住（一開始太樂觀，感覺半個月到一個月就行了，實際證明根本就不是這麼回事），因為壓力巨大和熬夜太多一個合伙人和另外一個同事因為一件小事發生了一次嚴重的矛盾，兩人鬥毆打的滿臉都是血砸壞了一台電腦。最後終於是換到了symfony2，代價是很大的，對團隊的影響更是巨大（期間有人唱衰，十分不團結，對路線和方向的質疑，甲方那邊一開始還好，慢慢的簡直是要炸鍋，關鍵是給人家耽誤事了，銷售各種抱怨，總之你懂的），團隊發生的矛盾主要是趕時間和處理的不好，以及確實是部分同僚技術功底太差了，而且做出這個甚比在戰場上打著打著換武器的決定也是很難說好不好（但當時實在是沒辦法，甲方那邊也給了很大壓力）。這件事情之後大家都互相了解了很多，而且確實是整體技術水平有了顯著提高，還是值得的。更不要說symfony2的引入減少了多少麻煩，效率提升了很多。後來的一些外包項目就順的很了，開發非常迅速，bundle等symfony2的機制讓代碼復用非常方便，後來看是值得的，但是選擇的更換時機是有問題的。

但是因為商業等方面的原因（主要是我們不做外包了），後來又全線換到了java(這個過程甚至可以說是在換人，走了好幾個人，又有新人加入)，其中主要是商業方向的變更以及對未來的業務與招募人員方便的考慮。（團隊方面。。。我就不說了。。。雖然不是我能決定的，但是想想看很對不起大家）。

朋友，分享我的經歷，希望能夠幫到你。

我所在的公司，php工程師用的都是symfony框架，這個框架只有真的用過才知道其中的好，我承認，這是個學習成本比較高的框架，現在也有了中文的網站了，學習起來沒有以前那麼困難了，我建議轉向symfony

用drupal吧( ????? )

TP更本地化，Symfony國內使用的公司畢竟不多，相關人才儲備也不多。Symfony從4.0開始感覺不再是一個框架而是一個平台，在引導甚至做PHP領域相關的一個規範，4.0的模式對於團隊合作，自動化方面更友好了，對於運維人員來說會更輕鬆。

技術總監這個角色考慮的問題應該是比較全面的，不單單是選擇開發框架這個問題本身，可能在技術團隊、公司業務領域方面都有所考慮了。

TP5.0 和 laravel 很像……

不過如果是項目的驗證版本的話，推薦用 CI 這個級別的框架

如果已經驗證過項目，整個項目已經比較成熟了，

推薦用 LARAVEL 啊 symfony2 啊這類框架 ……

另外，可以考慮把用戶系統拆出來做用戶中心應用，

這個用戶中心用 symfony2 ，其他系統用 TP/CI 實現，

然後有 symfony2 的經驗之後，再把 TP/CI 系統拆分或更換

很驚喜看到symfony中文鏡像站上線了http://www.symfonychina.com/，撒花恭喜十分感謝！就像網站下有人評論，他們的付出對於國內想學習symfony的同學簡直就是恩賜，甚至是救贖。反觀symphony.cn，占著這麼好的入口，也沒什麼動靜，幾年了還是那個樣子。。

一年前加入公司並且成功安利symfony，圍繞框架重構了所有業務（以前是discuz定製和修改，據說很痛苦），包括網站，wap頁面和app介面。項目不大，兩台前端機，一台隊列腳本，一台redis+資料庫。房地產網站，房源總量100w+，10w在售，坐標海外。一路坑踩過來（主要是團隊的上手差異和學習曲線），一旦團隊上手，工程效率顯著提升。我的感覺就是如果團隊里有經驗豐富的symfony好手做開發骨幹，就大膽的用吧，很多東西一點就通，用上了才能發現其中的方便。我們目前的實踐是結合vuejs做前後分離，後端只提供rest介面，更專註業務和性能優化。

symfony的優勢是

維護周期長，版本過渡平滑。從官網上看到，目前穩定的2.8將會維護到2019年，3.4到2021年。在我們還沒有升級到3的時候，4的開發計劃都提上日程了。
國外社區比較活躍，遇到的問題基本都有解決方案。
可以用的bundle太多了，不管是官方的還是第三方，大到安全組件，小到ip轉地區的資料庫整合，免去造輪子，大大提高開發效率。官方也很開放，如果你的組件做的足夠好，沒準第二天就被收編作為官方認證的新特性了。
基於依賴注入service的業務模式讓項目結構有條理，方便測試，而且容易擴展。
靈活。你可以用symfony做全棧框架，也可以用其中的組件來按需開發自己的項目，基於request和response的模式讓你對mvc有新的認識。
自帶的profile工具條非常全面，可以清楚的看到哪個環節拖慢了速度，哪一條sql需要優化。
當然了，其他框架有的功能symfony也少不了，hook，表單，路由等等

有人說symfony太重了，太慢了。在php7上實踐性能還不錯，瓶頸大都在資料庫讀寫，但是開發效率上帶來的提升是質的飛躍。有針對的做一些緩存，加上二級緩存的開啟，速度飛起。

缺點就是國內不夠普及，文檔稀缺（但現在也有中文鏡像站了），看著隔壁Laravel陣營的小夥伴們熱火朝天的討論問題，有時候還有點羨慕呢，怎麼說這兩個框架也是一個舅舅和侄兒的關係了。

如果你討論的不是像天貓京東那種巨無霸項目，一般情況下symfony還是能遊刃有餘。

你的考慮不無道理，不過快速開發和後期的擴展性需要綜合考慮，後期你會發現TP絕非好選擇，尤其是自己項目需要長期迭代維護。從你所述，Laravel 5.1 LTS 比較適合，上手也很容易。你可以建議，但最終的決策還是你們頭兒說了算。

其實選哪個都沒有絕對的對錯。但是技術上過於單一是不好的。

Symfony的開發成本較高，維護成本也相對較高。而且就本人經驗來說，Symfony框架過於沉重，給伺服器負擔較高，響應速度太慢，

ZF2，好，但是臃腫。

Laravel目前版本5.0，我個人認為完全可以承擔大型項目的需求。用4.*版本開發過三個項目，目前已經在用它開發第4個項目。評價一個字：爽！