摘要：如何挑选框架这个问题是我面试的常用起手问题，所以在看到这个提问的时候，就抽时间回答了一下。某些框架甚至本身自己有安全漏洞不多说。另一个角度是框架的各个部分是否能脱离框架运行。不用的，或者假装自己用的那些框架没有未来。
如何挑选PHP框架？
这个问题是我面试的常用起手问题，所以在SF看到这个提问的时候，就抽时间回答了一下。这里做一些整理和补充。
很多时候，讨论问题从抠概念出发是个好想法。框架是团队在项目初期选定的开发框架，或者在长期开发过程中提炼的公共逻辑等。所以无论是初期挑选框架、是中途重构更换框架、还是需要抽离团队内部自己的框架，都应当以下面三个角度综合考虑
团队
项目
框架本身
团队成员情况 & 未来团队成员情况 & 所在地职业市场情况如果团队现在和未来都只有你一个人（比如自己的toy project），那选自己最想用的就好。但只要不是这个情况，你最好先得了解市面上常见的各种框架，然后忘记自己的个人偏好。
了解你的团队成员的现在情况，考虑你的团队未来的发展速度，未来可能加入的团队成员的情况，以及你所在地职业市场情况。打比方说，Laravel经常是个不错的选择，但如果你在产业不发达的小城市，团队又必须高速发展大量招人，选择Laravel可能很快会让你陷进“composer和现代PHP技能培训班”的窘境，而一些更“接地气”的框架则能让你的团队迅速扩张，快速满足业务发展的需求
项目生命周期 & 未来演变方向有的项目，作为贵司的主营业务是需要长期维护，持续迭代的。而另一些项目可能作为一些边角、过渡的项目，可能做完以后不会再有什么后续的需求。最后还有一些外包／类外包的项目，交付以后就没有需求／后续需求可以当另一个项目。
再大的项目，需求再多，如果是第三种，无需考虑未来演变的，那么框架的扩展性就能够被牺牲（从而换取开发速度或其他好处），打比方说基于一些成品二次开发的选择就可以被考虑。再小的项目，如果是贵司的主营业务，持续迭代的，那么就算工作量再小，也必须慎重考虑框架的扩展性。
那么，什么是框架的扩展性呢？ CI是扩展性很好的框架吗？ZendFramework1/2是扩展性很好的框架吗？
答案是，看未来演变方向。有的项目未来的压力在访问流量大，有的压力在数据量大检索频繁，也有项目压力在需求迭代快，变动频繁而周期短。项目面临的问题越是普遍，那么预设各种解决方案的框架可能越能减少重复造轮子，反之项目面临的问题越是极端，那么轻量化的那些框架可能更适合让你的团队自己研究解决方案对接到框架中。另外，项目维护的时间越长，变动越难预测，采用预设各种解决方案的框架的风险就会越大（那些预设的解决方案恰好能解决你的每个问题的概率越来越小）
框架本身的基本素质性能和跑分。除了phalcon和Yaf两个C实现的框架，其他框架请认为一样快。另外除非你在主持类似新浪微博更换PHP框架这样的事，或者说除非你管理的项目web机器超过100台，请忽略PHP框架的性能因素
psr和composer亲和性。这是双刃剑，前面已经聊过怎么看待这个特质了。
安全性。某些框架甚至本身自己有安全漏洞不多说。另外如果框架层面提供了一些安全方面的东西，建议还是要简单看一遍代码，有时那可能反而不如自己写。
功能性。也就是预设的解决方案的数量和质量，前面有提过。
模块化程度。框架内的各个部分是否能够自定义，自定义的代价多高。另一个角度是框架的各个部分是否能脱离框架运行。
表达能力（业务功能需要多少代码量来实现），这三个特性（表达能力、功能性、模块化程度）互相冲突，无法达到三者兼得。功能丰富，模块化程度又高可以随意定制、替换的框架，往往普通的业务代码也要写一堆。一句话能写出一大堆功能的框架，往往模块化程度不理想，不容易自定义。 模块化程度高，而业务代码不啰嗦的框架，则往往没有丰富的预设功能。
周边生态和活跃程度以及兼容性。活跃的框架就还有成长和改进的空间，但相应过于活跃有时会导致应用无法兼容。另一个指标是周边的生态，有没有其他人基于这个框架开发一些周边的模块／插件之类的东西，以及文档的丰富程度、出问题后能是否容易找到的解决方案等。
“无招胜有招” -- 谈composer和psr-7和我心目中未来十年的PHP框架（本节内容仅仅是我个人的判断，另外基于中国国情，这个未来可能也还是老外先享受到）
PHP是个相对古老的语言，PHP框架也是个相当古老的概念了。我认为隔壁的NodeJS社区很好的为我们示范了真正“web框架”应有的形态。以依赖解决方案npm为核心，connect到express为代表的中间件架构为骨架，周围围绕着星罗密布的数不胜数的中间件。中间件架构设定了web请求和响应的标准接口，周围的其他项目以这些接口为基础开发各种功能。工程师要做的就是找到合适的中间件安插到项目中，或者自己写合适自己情况的中间件（当然最好是开源出来回报社区咯）。于是你会发现相当于“PHP框架”概念的那些项目基本行不通（sails已经是做的最好的了？）
这也是我对未来PHP框架的判断。大而全的“PHP框架”时代已经过去了。不用composer的，或者假装自己用composer的那些框架没有未来。基于composer的，模块化组件化的项目，未来在强势的输入输出标准统一下，会爆发出惊人的生产力。symfony/http-foundation本来是个不错的选择，社区也有对应的中间件化的努力。但目前看来，怀胎已久的PSR-7更可能成为未来的赢家。有强力的标准和解构化的中间件生态，社区才有充分的竞争，开发者才有充分的选择权，A2框架 视图层巨烂但路由很漂亮，B2框架 路由好用但视图糟糕？下一代A3和B3都一样支持PSR-7，拿回家自己拼接就好！
广告时间： 基于这样的判断，connect的PHP移植又没有很多star的情况下，我花了一些时间撸了自己的中间件架构mcfog/nimo，欢迎围观和star
原文地址：http://inside.mcfog.wang/2015/09/ichizon-d/
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/21127.html
摘要：今天就来研究一下如何在上实现高斯模糊效果。平时我们对图片缩小，必然会带来很明显的清晰度的损失，但高斯模糊本身的目的就是要实现模糊的效果，因此实际上的效果差别不大，几乎可以忽略。 前言 从 iOS 7 开始 Apple 从 拟物化 过渡到了 扁平化 的设计风格，同时也搭配使用了 毛玻璃风格 当做背景效果，不得不说十分惊艳，颇有当时pc上 Widows Vista 和 OS X Yosem...
摘要：判断依赖对象当收到某个的变化或者嵌套滑动事件时，就会尝试把事件下发给，绑定了该的就会对事件做出响应。另外的两种布局事件触摸事件就没有这一步了。变化事件这个变化是指的位置尺寸发生了变化。由主动发出滑动事件传递给，做出响应。 前言 许多文章都是将CoordinatorLayout、AppbarLayout、CollapsingToolbarLayout、Toolbar等放在一起介绍，容易误...
摘要：是包最多管理工具，按照定律，其中的包都可能是坑，其中的包应该是高质量的。那么应当如何挑选呢最好的都在这里整合了最优秀的的和项目资源。并给出一个包的整体分数。 我以前写过一篇文章，UI大全：前端UI框架集合（持续更新，当前32个）, 最近翻阅了这篇文章。发现有些框架，如果你用了，那你就掉坑里去了。 NPM是包最多管理工具，按照80-20定律，其中80%的包都可能是坑，其中20%的包应该是...
摘要：之前受到这篇为你的站点插上的翅膀的启发就尝试在中引入，并完成中文索引。关于中文索引谷歌上关于中文搜索的文章有很多，例如这篇。中文索引中涉及的内容比较多，下次再用一个篇幅来分析。 如何在Lumen中使用Elasticsearch 前言 Lumen是基于Laravel核心组件的微框架，随着Laravel5的发布，目前版本也已经到5了。之前受到这篇为你的站点插上ElasticSearch...
摘要：之前受到这篇为你的站点插上的翅膀的启发就尝试在中引入，并完成中文索引。关于中文索引谷歌上关于中文搜索的文章有很多，例如这篇。中文索引中涉及的内容比较多，下次再用一个篇幅来分析。 如何在Lumen中使用Elasticsearch 前言 Lumen是基于Laravel核心组件的微框架，随着Laravel5的发布，目前版本也已经到5了。之前受到这篇为你的站点插上ElasticSearch...
阅读 1430·2021-11-23 10:01
阅读 2758·2021-11-19 09:40
阅读 1539·2021-11-15 11:38
阅读 3051·2021-10-18 13:24
阅读 3343·2019-08-29 14:20
阅读 2866·2019-08-26 13:39
阅读 1139·2019-08-26 11:56
阅读 2462·2019-08-23 18:03
