《PHP挖宝》1—再论框架

文章目录

• 《PHP挖宝》1—再论框架
• • 一起思考
  • 我看重的几个角度
  • • 易用性
    • 生态社区
    • 学习成本
  • 总结

《PHP挖宝》专栏入口地址

在本文编写时，2020年已经接近尾声，网络上关于PHP框架性能测评的文章大家也见得很多了，除了正在或即将使用“现代框架”的团队或个人，其实生活中还有很大一部分开发者在开发没有框架^{1的项目，对他们而言讨论框架更是一种奢望，对，我有段工作经历就是其中一员。}

对于这些性能评测文章，我觉得认清一些基本事实就好了，不需要抓着A比B快几个毫秒就如获至宝。比如用Swoole和常规MVC框架比较速度性能，运行原理不同完全没有可比性。不清楚这点的，盲目推崇用Swoole通杀一切MVC场景会适得其反，主要是因为Swoole的常驻运行方式，会让代码热更新和内存管理变得复杂，不那么容易上手和掌握，时常会因为误用静态变量存储会增大的对象，导致因内存泄漏耗光而服务器崩溃。对于很多基础薄弱的PHP程序员来说，使用Swoole会是个较大的困难。

这里我想提出一些观点，是我工作中认为选择框架应该看重的地方。由于各人成长环境不同，看重的事物也有所不同，千人大公司和三人小公司的取舍自然也是不同的。粗鄙之见仅供参考。

一起思考

• 你为了证明自己的能力，想使用MVC框架从0开发一个个人博客，你会选择哪个框架？

• 你的上级希望使用一个只有全英文文档的Symfony框架或Phalcon框架作为项目的MVC框架，你是否赞同或者劝上级改用其他框架？

• 如果你曾经对ThinkPHP有微词，2020年了，ThinkPHP6会令你有所改观吗？

• 选择框架时，你会考虑它的ORM和视图模板的易用程度吗？你能说出不同框架的ORM和模板引擎好用和不好用的地方吗？

• 某些框架能够天然支持SSO、LDAP、多域名多站点、MongoDB、PostgreDB、前后端分离SPA、API Token等等，你有了解过吗？还在手工实现这些功能吗?

• 不同框架之间的ORM在做关联模型操作时的难易程度是非常不同的。有些能准确返回指定关联模型对象，有些只能返回数组，返回字段的多少和类型都不能保证。

• 还有很多很多……

不难发现，抛开网络那些框架对比性能评测文章，我们在选择框架的时候实际还会考虑很多东西。比如Symfony框架，作为PHP框架的老祖宗，光环优点数不胜数，虽然性能确实不咋地。然而让绝大多数团队放弃它的重要原因之一是没有中文教程文档。真有人会觉得Symfony不能满足项目需求吗？以我个人经历来看，经验较少的开发平时会给自己写很多轮子或者工具库，或者手工实现一些比较复杂的功能比如SSO单点登录，然而在Symfony和Laravel的世界，这一切都给你准备好了。你要做的只是看看文档找找三方包，安装并调试就好了。

我看重的几个角度

实事求是，实践是检验真理的唯一标准。

易用性

我把易用性放在第一位，这对于一个职业开发者来说是最重要也不为过。没人会喜欢一个创建项目需要大半天还各种bug连Hello World都跑不起来的框架；也没人愿意天天和框架做斗争，就是为了研究出怎么写ORM查询才更加优雅。我们每天都要面对一大堆等待开发的需求，多问问自己一句，性能速度真有那么重要吗，你每天加班就是为了读懂框架、调试框架、理解框架，这是你的工作吗？不是，这是框架作者的工作。我们都不希望在加班工作中被框架的各种问题折磨。

易用性是相对于个人和团队来说的，哪怕是选择了非常庞大复杂的框架，只要个人或团队感到熟悉且能顺利完成开发，那它就是易用的。人力成本比机器贵多了，易用的框架，能增强个人和团队的幸福感，能使项目得到有序稳定的进行，不至于每个一段时间就会碰到框架的坑，这里不允许操作，哪里不允许调用等等。

如果一个项目中认为性能速度是最重要的，我想作为一个管理者肯定不会选择普通MVC框架尤其是Symfony这种庞大复杂笨重的框架，轻量级微服务框架或者直接上Swoole或者用JAVA来实现更加靠谱，而且在可预期的未来不容易出现性能瓶颈。有种要求的项目毕竟属于少数。一开始就选择为高性能设计的框架，让后期优化工作更少更简单，也可以理解为是框架易用性的一种体现，“它易于优化，甚至不用优化，真爽”。

生态社区

大量的一次性外包开发项目，通常来讲，一个熟悉的框架加上一些组件包（图片、二维码、微信公众号、聚合支付等），可以很好地完成需求开发，生态社区似乎并不是那么地显眼。然而我们在开发公司长期运营的产品过程中，一个系统使用三到五年是很正常的事，如果公司发展较快，当初一个单站应用，很可能就会慢慢变成一个大前台、大后台，各种SPA、MongoDB、SSO、Redis、MQ等技术升级就会呼之欲出。

你所选用的框架能否满足公司产品未来发展，很大程度上依赖框架的生态社区，社区里组件丰富的，就会减少很多问题，要做的都有人帮你做了。如果选择了一个冷门框架或者是周边设施不那么完善的框架，很多组件插件都要自己写，自己接入，自己完善。稍大的公司有足够的人力物力耗得起，小公司人少工期紧，可能磨到公司倒闭破产都没磨出来，任何问题都是“下次一定”。

这一点和前面提到的易用性不同的是，需要管理者、决策者平时了解积累生态资源，才能在这个角度上做出评判。不知道的东西，是永远不会凭空出现的。

学习成本

2020年了，大多数主流框架设计的已经足够简单，凡事有例外，确实有些框架的设计比较反人类。以我和周围朋友的学习经历来看，学习成本主要体现在英语文档阅读和高级概念的理解上。不是每个团队都是高素质人才，英语这个只能因地制宜，结合实际来操作。这里我想说说高级概念的学习成本。

很多刚毕业从事PHP的读者，学习中文框架时，看到控制器、视图、模型等概念并不陌生，学校里就有很多实操经验，这些难不倒大家。

直到框架文档中出现这样的概念，尤其是以英文的方式呈现：

• 中间件（Middleware）、拦截器（Interceptor）、钩子（Hook）、过滤器（Filter）。
• Security（安全组件）：实现账号注册、多角色授权、验证、全站登录保护、找回密码、LDAP、账号连登等多种用户账号操作组件。
• Serialize（序列化）：JSOＮ-Array-Obejct的序列化和反序列化。
• Service Container(服务容器)和Dependence Injection(依赖注入)
• Message Queue(消息队列) 和 Async Task(异步任务)
• ……

这些概念好像在JAVA里似曾相识。没错，就是从JAVA里搬过来的，早期的PHP框架哪里有服务容器这一说，是后来JAVA有servlet技术，实现了容器化，还有用Spring实现了依赖注入。PHP才开始慢慢模仿实现这些概念，尽管PHP的容器和JAVA Web中的容器不是同一个概念。

这些东西用的好就是神器，用不好就是累赘。像安全组件，配置之多，用法之复杂，对于小网站来说可能有人会觉得手写个session控制更快更简单。这就是学习成本的体现，对于工作经验较少的读者，往往高估自己也高估同事，迷信框架伟大神奇之处，实际用起来的时候效果一团糟，伟大神奇的地方都没有好好利用起来，全部手工实现完事。

总结

前面介绍了很多观点和经验，不过说真的，你在选择框架时，真的会客观细致地慢慢分析这些吗？还不是哪个熟手用哪个——过于真实。

PHP框架之多，对于多次换工作的人来说，时常要重新学习一个新的框架，不少人对此感到痛苦。关于这点我推荐读者们能够尝试感受和理解不同框架的异同点，思考它们设计好与不好的地方，这也正是PHP生态里的宝贵的学习资源。

以我今天的目光来看，如果让我选择一个框架做新项目，我肯定选Spring Boot技术栈，JAVA的Spring全家桶真香。不存在性能、生态局限和易用性问题，开箱即用，就是Spring生态圈过于庞大，前期学习成本不低。当我跳出PHP的圈子，站在JAVA角度来看回PHP，很多争论其实都不是问题，早就被JAVA圈子玩烂了。这么说看起来像是背叛了并且鄙视PHP，然而我认为这是一种重新认识的过程，只生活在自己的PHP圈子里，不也是一种傲慢和迷之自信吗吗？跳出去从外人角度看，就会发现曾经自己所学所得是多么卑微和沾沾自喜。

---

1. 早期的PHP项目很多都是以非自动加载的MVC模式来实现，并且没有Composer加持，在这样的项目环境下工作，任何的重构升级优化都会变得非常艰难。不过也有不少项目是因为不需要MVC，只是想用PHP编写一些脚本比如爬虫，所以可以直接安装相应的功能包就能完成开发，不一定非要安装框架才能完成项目开发。 ↩︎