摘要:如何挑選框架這個問題是我面試的常用起手問題,所以在看到這個提問的時候,就抽時間回答了一下。某些框架甚至本身自己有安全漏洞不多說。另一個角度是框架的各個部分是否能脫離框架運行。不用的,或者假裝自己用的那些框架沒有未來。
如何挑選PHP框架?
這個問題是我面試的常用起手問題,所以在SF看到這個提問的時候,就抽時間回答了一下。這里做一些整理和補充。
很多時候,討論問題從摳概念出發(fā)是個好想法。框架是團隊在項目初期選定的開發(fā)框架,或者在長期開發(fā)過程中提煉的公共邏輯等。所以無論是初期挑選框架、是中途重構更換框架、還是需要抽離團隊內部自己的框架,都應當以下面三個角度綜合考慮
團隊
項目
框架本身
團隊成員情況 & 未來團隊成員情況 & 所在地職業(yè)市場情況如果團隊現(xiàn)在和未來都只有你一個人(比如自己的toy project),那選自己最想用的就好。但只要不是這個情況,你最好先得了解市面上常見的各種框架,然后忘記自己的個人偏好。
了解你的團隊成員的現(xiàn)在情況,考慮你的團隊未來的發(fā)展速度,未來可能加入的團隊成員的情況,以及你所在地職業(yè)市場情況。打比方說,Laravel經常是個不錯的選擇,但如果你在產業(yè)不發(fā)達的小城市,團隊又必須高速發(fā)展大量招人,選擇Laravel可能很快會讓你陷進“composer和現(xiàn)代PHP技能培訓班”的窘境,而一些更“接地氣”的框架則能讓你的團隊迅速擴張,快速滿足業(yè)務發(fā)展的需求
項目生命周期 & 未來演變方向有的項目,作為貴司的主營業(yè)務是需要長期維護,持續(xù)迭代的。而另一些項目可能作為一些邊角、過渡的項目,可能做完以后不會再有什么后續(xù)的需求。最后還有一些外包/類外包的項目,交付以后就沒有需求/后續(xù)需求可以當另一個項目。
再大的項目,需求再多,如果是第三種,無需考慮未來演變的,那么框架的擴展性就能夠被犧牲(從而換取開發(fā)速度或其他好處),打比方說基于一些成品二次開發(fā)的選擇就可以被考慮。再小的項目,如果是貴司的主營業(yè)務,持續(xù)迭代的,那么就算工作量再小,也必須慎重考慮框架的擴展性。
那么,什么是框架的擴展性呢? CI是擴展性很好的框架嗎?ZendFramework1/2是擴展性很好的框架嗎?
答案是,看未來演變方向。有的項目未來的壓力在訪問流量大,有的壓力在數(shù)據(jù)量大檢索頻繁,也有項目壓力在需求迭代快,變動頻繁而周期短。項目面臨的問題越是普遍,那么預設各種解決方案的框架可能越能減少重復造輪子,反之項目面臨的問題越是極端,那么輕量化的那些框架可能更適合讓你的團隊自己研究解決方案對接到框架中。另外,項目維護的時間越長,變動越難預測,采用預設各種解決方案的框架的風險就會越大(那些預設的解決方案恰好能解決你的每個問題的概率越來越小)
框架本身的基本素質性能和跑分。除了phalcon和Yaf兩個C實現(xiàn)的框架,其他框架請認為一樣快。另外除非你在主持類似新浪微博更換PHP框架這樣的事,或者說除非你管理的項目web機器超過100臺,請忽略PHP框架的性能因素
psr和composer親和性。這是雙刃劍,前面已經聊過怎么看待這個特質了。
安全性。某些框架甚至本身自己有安全漏洞不多說。另外如果框架層面提供了一些安全方面的東西,建議還是要簡單看一遍代碼,有時那可能反而不如自己寫。
功能性。也就是預設的解決方案的數(shù)量和質量,前面有提過。
模塊化程度。框架內的各個部分是否能夠自定義,自定義的代價多高。另一個角度是框架的各個部分是否能脫離框架運行。
表達能力(業(yè)務功能需要多少代碼量來實現(xiàn)),這三個特性(表達能力、功能性、模塊化程度)互相沖突,無法達到三者兼得。功能豐富,模塊化程度又高可以隨意定制、替換的框架,往往普通的業(yè)務代碼也要寫一堆。一句話能寫出一大堆功能的框架,往往模塊化程度不理想,不容易自定義。 模塊化程度高,而業(yè)務代碼不啰嗦的框架,則往往沒有豐富的預設功能。
周邊生態(tài)和活躍程度以及兼容性。活躍的框架就還有成長和改進的空間,但相應過于活躍有時會導致應用無法兼容。另一個指標是周邊的生態(tài),有沒有其他人基于這個框架開發(fā)一些周邊的模塊/插件之類的東西,以及文檔的豐富程度、出問題后能是否容易找到的解決方案等。
“無招勝有招” -- 談composer和psr-7和我心目中未來十年的PHP框架(本節(jié)內容僅僅是我個人的判斷,另外基于中國國情,這個未來可能也還是老外先享受到)
PHP是個相對古老的語言,PHP框架也是個相當古老的概念了。我認為隔壁的NodeJS社區(qū)很好的為我們示范了真正“web框架”應有的形態(tài)。以依賴解決方案npm為核心,connect到express為代表的中間件架構為骨架,周圍圍繞著星羅密布的數(shù)不勝數(shù)的中間件。中間件架構設定了web請求和響應的標準接口,周圍的其他項目以這些接口為基礎開發(fā)各種功能。工程師要做的就是找到合適的中間件安插到項目中,或者自己寫合適自己情況的中間件(當然最好是開源出來回報社區(qū)咯)。于是你會發(fā)現(xiàn)相當于“PHP框架”概念的那些項目基本行不通(sails已經是做的最好的了?)
這也是我對未來PHP框架的判斷。大而全的“PHP框架”時代已經過去了。不用composer的,或者假裝自己用composer的那些框架沒有未來。基于composer的,模塊化組件化的項目,未來在強勢的輸入輸出標準統(tǒng)一下,會爆發(fā)出驚人的生產力。symfony/http-foundation本來是個不錯的選擇,社區(qū)也有對應的中間件化的努力。但目前看來,懷胎已久的PSR-7更可能成為未來的贏家。有強力的標準和解構化的中間件生態(tài),社區(qū)才有充分的競爭,開發(fā)者才有充分的選擇權,A2框架 視圖層巨爛但路由很漂亮,B2框架 路由好用但視圖糟糕?下一代A3和B3都一樣支持PSR-7,拿回家自己拼接就好!
廣告時間: 基于這樣的判斷,connect的PHP移植又沒有很多star的情況下,我花了一些時間擼了自己的中間件架構mcfog/nimo,歡迎圍觀和star
原文地址:http://inside.mcfog.wang/2015/09/ichizon-d/
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/21127.html
摘要:今天就來研究一下如何在上實現(xiàn)高斯模糊效果。平時我們對圖片縮小,必然會帶來很明顯的清晰度的損失,但高斯模糊本身的目的就是要實現(xiàn)模糊的效果,因此實際上的效果差別不大,幾乎可以忽略。 前言 從 iOS 7 開始 Apple 從 擬物化 過渡到了 扁平化 的設計風格,同時也搭配使用了 毛玻璃風格 當做背景效果,不得不說十分驚艷,頗有當時pc上 Widows Vista 和 OS X Yosem...
摘要:是包最多管理工具,按照定律,其中的包都可能是坑,其中的包應該是高質量的。那么應當如何挑選呢最好的都在這里整合了最優(yōu)秀的的和項目資源。并給出一個包的整體分數(shù)。 我以前寫過一篇文章,UI大全:前端UI框架集合(持續(xù)更新,當前32個), 最近翻閱了這篇文章。發(fā)現(xiàn)有些框架,如果你用了,那你就掉坑里去了。 NPM是包最多管理工具,按照80-20定律,其中80%的包都可能是坑,其中20%的包應該是...
摘要:之前受到這篇為你的站點插上的翅膀的啟發(fā)就嘗試在中引入,并完成中文索引。關于中文索引谷歌上關于中文搜索的文章有很多,例如這篇。中文索引中涉及的內容比較多,下次再用一個篇幅來分析。 如何在Lumen中使用Elasticsearch 前言 Lumen是基于Laravel核心組件的微框架,隨著Laravel5的發(fā)布,目前版本也已經到5了。之前受到這篇為你的站點插上ElasticSearch...
閱讀 1574·2021-11-23 10:01
閱讀 2969·2021-11-19 09:40
閱讀 3214·2021-10-18 13:24
閱讀 3464·2019-08-29 14:20
閱讀 2980·2019-08-26 13:39
閱讀 1275·2019-08-26 11:56
閱讀 2661·2019-08-23 18:03
閱讀 373·2019-08-23 15:35