[吐槽]刚读了 yii3-demo， PHP 框架是怎么把 PHP (优雅的)玩死的。

@HiCode

小而美得框架也已经有一堆了啊。
所以没必要重复造轮子。
大框架也提供了小而美得兼容方式。

至于 PHP 发展，我有两个观点：

第一：

一门想语言发展好，主要是建立好生态。

这方面探索我们能看到的有：

1，前面我提到可以建立一个基于云原生的框架；

2，symfony 的 api 平台；

3，thinkphp 的 fastadmin ；

4，微擎的应用商店；


第二：

PHP 享受了 WEB 高速发展的红利期，
而现在虽然还没有进入衰退期，
但是 WEB 发展已经没有以前那么快了。
前文提到环境变化了，
恐龙就不能生存了，
自我改良是缓慢的，
所以不要将所有鸡蛋都放在一个篮子里面，
我们尝试 PHP 新出路同时，
不妨碍同时 go，python，java 甚至 c++等语言，
生老病死本常态，
一招鲜吃遍天的懒惰思想是行不通的。

@nicoljiang

PHP 还是简单，快速啊。
你看我都学了用了这么多框架，
我还是个很懒的人，
经常在 v2 灌水。
就知道这些框架有多简单了。

你说的 lue,python 方向是可以做客户端之类的吗？
那些真不适合 PHP 。

我宁愿去学 C#，C++，
每个人都有适合自己的定位。
历史决定的。

@encro 我很早就在准备换 lua，改用 openresty，我的业务不复杂。

其实当我们这么聊的时候，哈哈哈哈，PHP 就只是一个选择而已。

@HiCode

openresty 很好，价值很大。
曾经尝试做 waf 。

你们网站流量居然用 openresty ？
比我现在做的流量高吧？
我怕人难招，老板嫌开发不够敏捷。
如果不是因为上面原因，我更乐意用 go 慢慢堆代码吧，毕竟新玩具比较好玩。

@meshell 只是记忆中的而已，我好久没关注 PHP 了。

PSR 现在很多东西都是标准化，Class Loading，HTTP Messages，Mididleware，Logging，DI 等，各标准都是有大量实现。如果你真的是熟悉 PHP 生态，完全可以不用任何框架，自己像写 ExpressJS 程序那样，用一个 App 类启动组装一下，还纠结什么优雅问题。

楼主懂不懂 php 哦，业务代码在于你业务的丰富度，口口声声在吐槽框架是什么鬼。期待你写一个我们围观一下？

ROR 和 Django 不香了吗？

@wwolf 楼主有框架的，可以去围观 👀

php 天下无敌

@encro 小项目 H5，流量是不确定的，服务器成本预算不多，所以很难。

语言，框架始终只是工具，花样玩出头也就那样，都是浮云，什么业务场景适合用什么就用什么，没有就自己造，没什么好争来争去，谁也说服不了谁。

@dvaknheo
> 恕我浅薄，我真不知道依赖注入，对于动态语言，除了解决 [调用方式不变，实际实现可变] 功能之外还能有什么用。
如果你之前不知道，不是你的错。但现在有人明确给你指出这个概念以后，还在用你自己设想的（没错你之前的帖子我也看了，这几个你一直在强调的字我也有印象）

> 超长字符串拼接效率高还是 ob 函数分段输出效率高？
字符串拼接效率高，有数量级上的差距。（ https://3v4l.org/K7c6e ）

> 我所说的热修复，就是不强行去改第三方库的代码，修复出第三方库出现的功能。
> 就是要跟踪到第三方库还没解决问题，这才是折腾。
『另外你这个函数能做到的，依赖注入也都行。』
此外我觉得对于一个高级程序员，在三方库中踩坑是一个很常见的事情。。。


@HiCode
> 框架是一定要用的，这是生产力工具，以一定的性能损耗换取开发效率提高非常有意义。
> 我只是因为穷才追求高性能，我的业务都是薛定谔的“qps”，爆不爆发看策划看设计，我只负责打造一个“低成本高效率”的系统。

那么我有个疑问，像 laravel 这种被批评的，在你看来，是因为它的设计导致了性能损耗，但却没有带来开发效率的提高（设计带来的价值是负），还是尽管它带来了开发效率的提高，但是相比它带来的性能损耗，性价比太低（设计带来的价值依然是正数，但是很低）？
如果是后者，我有一个新的疑问。我们都知道在优化时一般我们应该先优化瓶颈部分。那么框架性能是否已经成为了一个瓶颈，或者说不可忽略的因素？

@jhdxr

第一个疑问，“laravel 带来了开发效率的提高，但是相比它带来的性能损耗，性价比太低”——我不反对优雅，我反对的是以性能为代价的“过度”优雅，将原生 PHP 的性能降到 4%，是很恐怕的一种优雅。

第二个问题，对于我日常的项目来说，有 redis 后，php 的性能问题就变成了新瓶颈，有钱可以直接升级服务器，没钱就要想办法抠性能。

我觉得我最重要的观点就是：土豪请随意，没钱才焦虑。

大概看了 Lz 框架一眼，可能是正统的 tp3 受害者吧

类似 App::G 这种东西，建议就别用了，跟 tp3 那年代一个函数用 ABCDE 命名那种差不多，不明所以，点进去人都懵了，一点也不清真

每次接手年代久远的 php 项目，那些代码基本不是给人看的，只能当场重写·

opcache fastcgi 大家都会用
主要为何要全依赖框架 有时候需要的功能只要稍微改改底层实现就可以了 而不是叠床架屋
硬拼个能够符合全部需求的
装一堆插件的 vim 启动好几秒 自己写的秒开 也是一种例子
太重的东西个人觉得不是优雅

表示这种代码我 review 的话会直接驳回

https://github.com/dvaknheo/duckphp/blob/master/src/Ext/RouteHookRewrite.php

@JokeEnd
App::G 又不是给写业务代码的用的，业务代码的人，一般只会在 Controller, Service，Model,View, 这四个目录。对应的 ControllerHelper,ServiceHelper,ModelHelper,ViewHelper 里有什么东西才值得看。 这些 Helper 的 GetExtendStaticMethodList() 有点恶心而已。

G 方法用于扩展的。 比如你要替换默认的实现。

@zencoding

奇怪，怎么不从主流程看起呢？ RouteHookRewrite 这个扩展默认没加载，而且我文档都没写完啊。
如果你从代码琢磨起。 最古怪的是怎么 DuckPhp\App 初始化后跑的是 MY\Base\App 的代码。这部分需要在 init 函数里琢磨一下。

DuckPhp\Core\App use DuckPhp\Core\Kernel->init ,run 才是核心， 还有个复杂的是 DuckPhp\Core\Route 路由。

@jhdxr
字符串拼接效率高，有数量级上的差距。
谢谢，我之前没估计过。，但 View 还是基本上以 echo 方式显示的，基本没见到 heredoc 类型的。如果追求效率，看来还是把 view 文件转为 heredoc 模式的文件好，综合起来，这为方便牺牲效率，这可以接受。

这 Yii3 是什么来头？熟悉的 Yii 和 Yii2 原作者都不见了

额，我自己失误了，G() 函数确实会在业务中用到。如果为了扩展性。
XService::G()->foo 和 XModel::G()->foo 这种用法经常有。
或许实践起来会有一排，改成 static function 调用 吧，就是
XService::foo(); 和 XModel::foo();

有一种情况是 XSerivce::G 这模式省不了， 没默认载入的扩展，JsonRpcExt 切换成远过程调用。这属于高级用法了，具体在相关 ref 里

看样子 G 函数是 getInstance 获取单例之类的
话说现在不应该人均 IDE 写代码了吗，G 还得按 shift，还不如 getInstace，偷鸡不成蚀把米的感觉

php 的问题就是框架太多，没有像 spring 一样的集大成者，开发者资源都浪费在发明框架重复造轮子上面，现在是后互联网时代了，生态够广才能活下去

@conn4575 并不会，大部分造轮子的都是自嗨

... 不喷不闹 推荐大家去看看郭德纲的 《你要高雅》

我 fork 了一个 yii3 demo 的版本（大概 80%进度)，在 入口处 加了些代码，强行插入 duckphp 框架版本的实现。见

https://github.com/dvaknheo/yii-demo

我切 github 默认分支不是 master 分支，而是 for_duckphp 分支。

for_duckphp 分支，实际干了两个分支的事情，后面再拆分。

for_duckphp 另一个分支功能的事情 是 service 化。src/service 目录 ，抽出来，单独成立一个分支，然后画关系图让大家看看 这部分和 duckphp 没关系

最主要的就是在 index.php 入口 插入 duckphp 版本的实现。
duckphp 版本的特点

1. 只在 composer.json 依赖一个包：dvaknheo/duckphp 1.2.3 。
2. 相关实现都在 app 目录底下。其他文件只改了 public/index.php ，src/Command 目录的命令行入口。
3. 保证输出和 yii3 demo 一致。原有 bug 不改。入口文件在请求完之后 curl 原来 url，如果相同输出，则输出 same. 否则输出 different 并在 runtime 里加 a.php ,b.php 方便对比。
4. 业务逻辑提取成 Service 层 . 6 个目录，view 是视图目录，config 是配置目录, Model 跟着 表走，Controller 负责输入，输出 view 前处理，业务放到 Service 。 Base 目录是核心才动的目录。基本上不交叉引用。

用 cloc 算了一下 app 目录 1760 行，比 src 目录 2289 行少点， 还有点 yii 的引用，主要是 3 个复杂组件没拆解，也不想拆解，留着就行。 分页还有进一步调整可能。

两个星期折腾这个代码，感觉有点慢。 或许，就弄了个大白象？
回头来看 yii2 的代码主要还是 卡在 behaviors 和 actions 上， 说不定哪天就重写了。 然后把 gii 也重写了。

到现在，逆行工程，主要还是，这玩意从哪里来的？ 这玩意被什么东西悄悄调用？ 这玩意里面有什么？

yii3 里 那个 widget PostCard 在 view 里计算 我就很不爽， 后面拆解成 view 文件 ，传入 array 。看上去清晰多了。

还有想吐槽的暂时记不清，就暂时到这吧。

说实话 php 适合小作坊类， 甲方要求 3 天一个 H5 项目（投票，抽奖，砸金蛋，猜灯谜，划龙舟等） ，从 0 到上线，费用预算 2K 。 你做还是不做？
肯定做啊，模板切图 tp+jquery 一把梭，2 天赶项目，还有 1 天时间摸鱼

什么 laravel 什么 vue 统统滚犊子，等脚手架搭建好，路由规则写好，活动早就结束了

你说让 java 和 python go 程序员去写这类项目？ 2k 预算，估计早就被喷出翔了吧