我是 Laravel 开发员，不是 PHP 开发员
Laravel
/
创建于 3周前
/
阅读数 2748
/
评论数 64
国外DISS PHP 的人很多很多，但是说Laravel坏话的没有。我发现很多Laravel 开发者不会想去 php.net 找答案，因为里面你所能看到的大部分函数， Laravel 有一个（或者多个）对应包裹 （Wrapper） 或者 函数。 做Laravel多了，甚至有种没有在写PHP的感觉。 我尽量不用PHP函数，理由如下：
- 保持代码标准。比如说函数应该是小驼峰，但是 PHP的函数都是蛇行 (snake_case)。现在业界的标准是，所有函数都应该是小驼峰 (camelCase)，所有类都应该是大驼峰(CamelCase) ， 所有常量 都应该是全大写 。 Laravel 本身的函数都是跟这个标准的， ( arr_search, str_replace 那类是例外，我基本上也不用他们)
- 流式接口 ( Fluent Interface) 。Laravel很多时候是推荐这种代码格式的，我们很经常这么写：
$user = App\User::where('name', 'Test') ->whereNull('verification_date');如果这些函数PHP有的话，你就要可能这么写：
$userObject = new App\User(); $user = user_where_null(user_where('name', 'Test'), 'verification_date');你需要的函数越多，括号也越多。所以我是倾向于流式接口的，干净，高端大气上档次。但是Laravel不是万能的, 有些函数也是没有的. (下面有例子)
我昨天看到了 LHao 大大的 这个： https://learnku.com/articles/22338?#reply78664 ， 启发了我，把那些 PHP 函数转换为 Laravel 函数， 就先翻译五个吧：
array_combine--- 创建一个数组，用一个数组的值作为其键名，另一个数组的值作为其值 ，
// php 版本
$a = array('green', 'red', 'yellow');
$b = array('avocado', 'apple', 'banana');
$c = array_combine($a, $b);
print_r($c); // 输出：['green' => 'avocado', 'red' => 'apple', 'yellow' => 'banana']
// Laravel 版本
$a = collect(['green', 'red', 'yellow']);
$b = ['avocado', 'apple', 'banana'];
$a->combine($b)
->dump();
//输出：
Collection {#1812 ▼
#items: array:3 [▼
"green" => "avocado"
"red" => "apple"
"yellow" => "banana"
]
}array_count_values--- 统计数组中所有的值, 没有 Laravel 版本
// 说明：array_count_values ( array $array ) : array
$array = array(1, "hello", 1, "world", "hello");
print_r(array_count_values($array)); // 输出：[1 => 2, "hello" => 2, "world" => 1]
array_diff_assoc--- 带索引检查计算数组的差集
// 说明：array_diff_assoc ( array $array1 , array $array2 [, array $... ] ) : array
$array1 = array("a" => "green", "b" => "brown", "c" => "blue", "red");
$array2 = array("a" => "green", "yellow", "red");
$result = array_diff_assoc($array1, $array2);
print_r($result); // 输出：["b" => "brown", "c" => "blue", 0 => "red"]
// 大家可以发现这里 red 有输出，为啥呢，因为第二个数组中 red 的 key 为 1。与数组一中的 key 为 0，不一致，所以有输出。
// Laravel
$array1 = collect([
"a" => "green",
"b" => "brown",
"c" => "blue", "red"
]);
$array2 = [
"a" => "green",
"yellow", "red"
];
return $array1->diffAssoc($array2);
// Result
{
"0": "red",
"b": "brown",
"c": "blue"
}
array_diff_key--- 使用键名比较计算数组的差集
// 说明：array_diff_key ( array $array1 , array $array2 [, array $... ] ) : array
$array1 = array('blue' => 1, 'red' => 2, 'green' => 3, 'purple' => 4);
$array2 = array('green' => 5, 'blue' => 6, 'yellow' => 7, 'cyan' => 8);
var_dump(array_diff_key($array1, $array2)); // 输出：['red' => 2, 'purple' => 4]
//laravel
$array1 = collect([
'blue' => 1,
'red' => 2,
'green' => 3,
'purple' => 4]
);
$array2 = [
'green' => 5,
'blue' => 6,
'yellow' => 7,
'cyan' => 8
];
return $array1->diffKeys($array2);
// result
{
"red": 2,
"purple": 4
}
array_diff_uassoc--- 用用户提供的回调函数做索引检查来计算数组的差集
// 说明：array_diff_uassoc ( array $array1 , array $array2 [, array $... ], callable $key_compare_func ) : array
function key_compare_func($a, $b)
{
if ($a === $b) {
return 0;
}
return ($a > $b)? 1:-1;
}
$array1 = array("a" => "green", "b" => "brown", "c" => "blue", "red");
$array2 = array("a" => "green", "yellow", "red");
$result = array_diff_uassoc($array1, $array2, "key_compare_func");
print_r($result); // 输出：["b" => "brown", "c" => "blue", 0 => "red"]
// Laravel
$array1 = collect([
"a" => "green",
"b" => "brown",
"c" => "blue",
"red"
]);
$array2 = [
"a" => "green",
"yellow",
"red"
];
return $array1->diffAssocUsing($array2, function ($a, $b) {
if ($a === $b) {
return 0;
}
return $a > $b
? 1
: -1;
});
// result
{
"0": "red",
"b": "brown",
"c": "blue"
}如果需要多过一个函数的时候, Collect 和 流式接口 的优势就显现出来了, 栗子:
$array1 = collect([
'blue' => 1,
'red' => 2,
'green' => 3,
'purple' => 4]
);
$array2 = [
'green' => 5,
'blue' => 6,
'yellow' => 7,
'cyan' => 8
];
return $array1->diffKeys($array2)
->transform(function ($item, $key) {
return [
'key' => $key,
'difference' => $item,
];
})
->values()
->all();
//结果
[
{
"key": "red",
"difference": 2
},
{
"key": "purple",
"difference": 4
}
]上面的例子， 首先用 Key 找到两个 Array 的差别，然后将结果变形 （变形或者 Transform 会保留原本的Key， 只变形值），剔除原本的 Key ， 然后整合成全新的 Array 。 可以看得出来，很清楚，很容易修改代码， 如果你要是用原本的PHP函数，你就得去追括号了，很多括号 。。。。 额，我残念了。
当然 Laravel Collection 也不是万能的，比如说上面那个 array_count_values 我就没找到好的代替方法，所以在这种情况下，还是乖乖用 PHP 自带功能吧。
后话
我这个人很坚持软件开发标准，因为我相信如果大家都信奉一条标准，开发过程会变得更有效率，而且日后的维护和升级，都会简单不少。我的团队的开发标准制定地很详细，所以我们看到 Bug , 可以在半个小时内，找到根源并修复。 复发几乎没有的事情。 而我们以前的代码（咳咳，不靠谱的前队友）有些不按照规定来写，修起来耗时间， 加功能更是几乎不可能，修三四次，每次都有新问题， 原作者当时也离职了，他的代码也没人看得懂。 最后，很多时候，只能重写。 不过大体上一切都很easy, 我们在 Laravel 更新框架版本一个月后更新上去， 也没有出过乱子。 我个人觉得，很大部分原因是因为我们保持了标准，而且我们的标准和Laravel官方的标准非常相似。
对不起各位，我有点标题党了。本文意思绝非贬低php原生
开发标准是团队的凝聚力表现 :+1:
坚守同一个开发标准这一点很赞！
新接触的团队，总是排斥 laravel，虽然在用，
但是laravel的 定时任务不用，job不用等等，总说如果redis或者xx挂了咋办
我该怎么反驳？
没必要这么吹，函数（不是方法）命名 Laravel 也是蛇形（https://github.com/laravel/framework/blob/5.7/src/Illuminate/Support/helpers.php ）；流式接口更不是 Laravel 独有，甚至其实是其他主流语言都常见的；至于 Collection，只不过是一种尴尬，只是因为 PHP 没有实现 scalar object，仅此而已。坦白讲，我不相信熟悉 Laravel 比 熟悉 PHP 好，我相信框架相比于语言更是工具。
函数本来就应该是蛇行，类的名称是大驼峰，类的方法和属性是小驼峰，命名是为了便于识别，你看看laravel的辅助函数是不是也是有蛇行的？
我相信框架相比于语言更是工具。
@839891627
哈哈，你问问他们 MySQL 挂了怎么办，要不也不要用了，直接往文件里写吧。
不要用php 函数 【大写滑稽】
@839891627
这么反问：自己造的轮子难道比社区开源一起维护的项目还要稳定吗。
对啊，标准能提升可读性和维护性，也能增加团队凝聚力
赞同。
个人想法：两者没什么可比性。「熟悉 Laravel」能够让你在开发业务时游刃有余；「熟悉 PHP」，可以帮助你更加快速理解框架某些模块的实现原理。可以说是相辅相成的。
不过，在实际开发中，还是要尽量统一一套开发标准，不能部分人喜欢使用原生实现，部分人喜欢使用 Laravel 的辅助函数，就像 Summer 提到的
开发标准是团队的凝聚力表现。对此，我更倾向于：
目前有些写法我会少用部分laravel提供的简便写法，比如whereAge这类的，属于你知道怎么用这个特性，但是新手看你的代码就一头雾水，不知道是哪里调用的。为了照顾新手，妥协很多地方。
统一开发标准用框架毋庸置疑，但是不深入原生PHP ，到头来也只会用Laravel了
@Littlesqx Laravel的蛇形其实是 Wrapper ， array_search 其实就是 Arr::search ， 不过为什么要保持这个，我猜是因为框架需要包容所有代码形式
@ibucoin 你说的魔法函数……额，我个人不推荐使用，Laravel还有更恐怖的魔法：
而且，魔法函数对性能及其不友好……所以，还是建议大家别挑战服务器的极限……
@Wi1dcard 同意，反正是团队决定，你函数要小驼峰，大驼峰，还是蛇形，都是标准。只不过我们团队很喜欢Laravel框架代码的写法，所以跟着了……他们的写法，和Java，还有C# （还有一些其他OOP语言）的标准相似，函数是小驼峰…… 但是我们是优先用框架提供的函数，想要追求那种原生的感觉和追求语法上的优美流畅。
@Caral 那是真的，我说的可能夸大了点，不过我在加拿大这边认识的很多Laravel开发，尤其是我这种90后的，很多有这种情况。不过讲真， 就比如说我，让写个index.php，收一个最简单的 POST 表格，一下子，我就愣住了……还是要想想， 哈哈哈。
@Shuyi
嗯嗯，赞同。尤其是 Laravel 的作者 Taylor 最早是一名 .NET 程序员，所以借鉴了一些其它语言的设计，并不局限于 PHP。再加上我本人早期做过 C#，刚接触 Laravel 的时候就喜欢上了它的风格，与其它 PHP 框架相比「更有面向对象的味道」，而且语法糖真是和 C# 一样众多。
@839891627 那你问他们，吃饭也会呛着，那不要吃饭了？喝水也会噎着，不喝水了？哈哈哈， 你同事也是滑稽
@Wi1dcard 语法糖还有自文档式代码风格都是我喜欢的。与其
return []我更宁愿写return response()->json([])，与其写function doSomething()我更愿意写function createUserAndPassword()， 毕竟我懒得写注释和文档，如果代码能一眼过去看得懂，长一点无所谓。 Laravel一大堆这些，每次看框架代码，都觉得是很享受的。@Shuyi 对对对，一直觉得 Taylor 是绝对的起名大师。如果了解英语语法的话，写起来会非常顺畅，一看名字就知道是什么意思，整行代码连起来就像标准的句子一样通俗易懂。
这标题起的
希望进一个这样的有规范的公司，，，
@Shuyi 魔法函数？魔术方法
函数和方法还是有区别的，感觉你说的很别扭，请别见怪
真的说出我的 :heart: 声 :joy: :joy:
laravel的辅助函数了解一下....
也是蛇形命名啊
还是想说，不要局限于语言，更不要局限于框架。。。。
集合没有交集函数 而php有
看这个帖子这么火，来来来打个广告了啊：RightCapital 招聘，喜欢规范的开发者们看过来了。
@lddtime 我其實是中文不夠好……哈哈哈， Magic Method 和 Magic Function ， 英文的說法，方法和函數是指的一個東西……
@ivothgle 心声？有什么委屈么……哈哈哈
标准有用，你所谓的标准 见仁见智
@839891627
队友讲的对啊
@839891627 告诉他们，担心挂就部署集群，实现高可用，全部容器化，弹性可伸缩……
@太空牛仔 先生，读东西不要读一半，看清楚了再开炮不迟。
@Jinrenjie 用 Kubernete 么？感觉很高大上呢
@Caral
实际上我个人一直以来的观点是,php并不值得深入.
我认为php的深入只有一个方面 便是阅读源码,阅读php的源码可能会带来三个层面的知识
编译原理层面
C语言层面
编程学习的一个观点是,学习一样新事物时 拆轮子是非常不推荐的做法,尤其是php这种堆彻了近10年的轮子.
如果你想学习编译原理,可以通过视频/书籍教程来学习.尤其是一些经典书籍 其比直接阅读源码更加的易于学习,甚至能够学的更好,C语言层面/计算机网络编程同理
php无论是性能,还是外部接口表现都被各种诟病.
而对于php的内部设计, 鸟哥曾表达过对php添加新功能举步维艰.
php被设计之初的目的只是一个c语言的扩展,后来被设计成了一个面向过程的编程语言. 由于面向对象的普及,php添加了面向对象的特性. 实际上从始至终从来没有站在一个语言的层面来进行设计.做过开发其实都清楚,这样的软件流程是非常致命的.
这篇文章我没有细看,但我的观点是相同的. laravel之于php,就像rails 之于 ruby. 实际上 如果你去知乎提问php和python谁更优秀,大部分人会说php是世界上最好的语言,所以我选python.
但是如果拿 laravel和diango(python的一个web开发框架)比较. laravel在生态/api/orm 等各方面都要优于diango的.
上面的所有说法都是基于php的深入是源码阅读层面, 如果说php的深入是 nginx/mysql/面向对象/设计模式/高并发 层面的深入,那当我没说.
关于编程语言的一点看法,编程语言本身只是一个软件,是对各种繁琐的细节进行层级封装暴露出更加简洁的api.
框架同理,也只是一个软件, 是对各种繁琐的细节进行层级封装暴露出更加简洁的api.
当然当然上面都是我的个人观点,大家没必要说服我同意你们的观点,让我一个人蒙在鼓里就好.:smile:
所谓的流式接口难道不是原生PHP写的吗?无非是返回了一个object
我再次发表一下我的观点：
少研究点框架和各种风骚的代码写法，以及绕来绕去的目录结构划分。
多研究下数据库和数据结构，以高效和高效率实现功能为核心思想以及唯一目标！
你们观察下那些生产力很高的程序员，他们都有个共同点： 十分重视数据库和数据结构的设计，很少纠结代码该怎么命名，代码该怎么换行，目录该怎么划分，做这些事的都是有点吃多了撑的。
当然了，也不是说标准不重要，只要一个团队功能遵守同一个标准就行，没有好坏之分。
@Shuyi 是啊，这个用起来省事很多，尤其是服务治理，无代码侵入
@Max 别忘了，PHP语言是设计来跑垃圾代码的 （忘了是哪位大佬说的了），你丢什么他都能跑。。。 像我本人是坚决反对触碰 WP 代码的，你想知道WP里面写了啥？一个函数你要找几十个文件还不一定有，因为人家是魔法函数。。。PHP创始人说他设计 PHP 7就是为了 WP 能跑得快些。。。我们做 Laravel 开发的，但是不一定会写 WP 的函数，也不定会写 Drupal 的函数， 因为 PHP 社区就是这么松散， Laravel 带动了大家标准化。
@jobsssss 重点是 生产能力很高的程序员 ， 代码形式啊，目录啊，是为了 生产能力很高的团队 ， 如果你就一个人写代码，还折腾这些，是的确过了。。。 不过标准的好处是，你把代码给别人了，别人还能继续工作下去。 我记得某位大大告诉我，记住，你代码写的不好，你的接班人不好维护，他可是知道你住哪里的...
@Jinrenjie 星星眼。。。我还在学，不敢把现在服务器弄成那样，不过以后肯定得，不是 Kubernete ， 就是无服务器技术
@Shuyi 关于标准这一块，我大概翻了一下评论，发现并没有人提到psr规范，只是围绕着团队规范。
psr规范规划了表层的代码规范，规定了类的自动加载规则，类/函数/变量的命名规范，结构语句规范，函数参数等一些地方的空格规范，较为细化。
必须要提的一点是，psr规范的每一条规则都有其理由，其参考了编码界的常用规范，尊重了历史。而不是凭空想象，拍拍脑袋出来的东西。(其实很多的团队规范，就是拍拍脑袋，或者以技术负责人的习惯来定)
psr规范最重要的一点是，使得composer能够推行，composer的意义我就不言而喻了。
当然laravel/symfony以及所有的composer包都是遵守psr规范
关于团队规范制定我的几点看法，当然laravel社区的laravel开发规范的第一点就已经提到了这些问题。
下面的几点不仅可以作为规范的制定，甚至可以将其作为个人的开发哲学，遇到问题时的指导思想
最佳实践，实际上任何问题，任何存在的东西，如文中，平均中提到的规范等，都有其现阶段的最佳实践，编程人员要做的事情无非就是尽量的接近，或者找到它！
官方推荐，这一点是找到最佳实践的首要参考依据，psr规范就是第一参考要素，团队需要做的就是拿来使用，并且把psr规范中的都可以，变成只可以。把psr规范中遗漏的进行补充，对深层规范进行细化
主厨精选，让有经验的人来为你做出选择。但是这个有经验的人并不是个人，最好是一个团队，并且是一个有经验的团队。如阿里团队的java开发手册，其除了表层规范外还规范了深层的一些规范，如逻辑流的写法/面向对象的规范/mysql规范， 其中大部分规范，对所有语言，所有团队都有指导意义 ，当然其中一些java特有的规范可以忽略。
尊重大多数人的想法，当上面两点都不能让你找到最佳实践时，那么大多数人的做法对你来说会是一个不错的选择。实际上官方制定一个新的规则时，也会反过来将大多数人的做法作为重要的参考依据
忽然发现字好多，可以水一篇博客了，不过我个人并不是很喜欢写这种情怀向的博客。
手机打字，所以没有做矫正，见谅。
要有敬畏之心
所谓你说的现在的业内标准是你们自己觉得的，标准不是一个团队指定出来的，每个团队在遵循psr前提下都有自己的标准，而且用la的不是php开发者，难道是java？
@Shuyi
@Max 讨论继续火热，想起来一张图：
@Caral 十分赞同，一个php开发者不认为自己是php开发者，这就非常致命了，要知道框架只是工具，语言才是本质
感觉还是不要自我设限比较好，laravel是用的，不是打标签的。
一般都是遵循团队的命名习惯 但书写习惯我一般都养成固定的了 我不倾向用ide的自动格式化代码功能快捷键 这样会破坏git对文件编辑的记录 在我git blame 找代码的具体信息的时候就找不到具体写的人了 我感觉我已经强迫症晚期了 :smiling_imp:
虽然我也喜欢laravel，但是奉劝你一句。不要学了点皮毛就到处秀智商，真理是
越是大佬越是谦虚，越是无知越是膨胀laravel再怎么牛逼还是php框架，什么叫做是Laravel 开发员，不是 PHP 开发员。学到点laravel皮毛就在这里装高大上。就像你嫌弃你爸一样
哈哈哈哈啊哈哈哈噢噢噢哦哈哈哈哈
@Shuyi 我以血泪经验告诉你，一份设计良好的数据库结构和业务数据结构，对于项目的可维护性而言，远远大于风骚的代码组织形式。
风骚的代码组织结构，在90%甚至是99%的场景下，带来的困扰远远大于收益。
我手中有一份7年前的php写的接口，这份接口代码超过了2万行，没有使用任何框架，变量命名各种风格都有，但是数据库结构完整的描述了业务逻辑，所以即便是新人，拿着源码只用了一天就可以进行开发工作了。
另一个项目则是前年用Laravel构建的，我也是手贱，被laravel灌了迷魂汤，各种DI，service,IOC,response都用上了，还自我吹嘘这是“优雅”，扩展性强，现在再看这个项目，没人愿意接手，我自己都特么想把那时候的我纠出来锤一顿。
最后奉上一句linus的话：Code is shit，Data structures are the soul.
代码都是垃圾，数据结构才是灵魂
@allen9009 认同，博主有点本末倒置了。
说点题外话：我现在招人的时候，都有点不敢用那些自称精通laravel和yii，zendframework的人了。好几个这样的人，都有一个共同点，活干不出来什么，却喜欢在项目中搞一大堆乱七八糟的设计，这样做给项目带来益处了吗？事实上并没有，比如我交代一个哥们，写一个代码，用来替换现有的金币查询逻辑，简简单单一个函数或者方法就完成了，结果这哥们儿搞了半天，测试的时候还老是不通过，我不信邪，看了下他的代码。我滴妈呀，就这么个简单的需求，这哥们又是单例，又是要解耦，还要弄成组件，业务先撇开不谈，一测试报错全是他这些设计带来的。什么问题没解决，他倒是又引入新的问题要解决，我愤怒的让他滚了。
@jobsssss 这个是另一个问题，叫过度工程。很多时候很简单的事情，一定要复杂地弄，这人也有。就是一个尺度拿捏的问题。。。你说的这种人我见过几个，空话很多，实干很少。比如说我们团队不用单例，能用一行写的，坚决不用两行。。。
@jobsssss 怎么说呢，我是觉得现在鼓吹框架的人和文章实在太多，导致大部分初学者糊里糊涂就开始学各种框架，对于其中框架怎么运行的不甚了解。不可否认框架在加速开发中起到的很大的作用，但这也导致他们在遇到问题时排查不了或是要花更多时间。
框架跟业务能力挂钩。原生跟技术能力挂钩。见仁见智吧。
@jobsssss @Shuyi
七年两万行也就是个很小的项目，这种程度不要说框架的单元测试，甚至连orm都可以不用
项目越大，变动越频繁框架的作用才会慢慢体现出来。合理地组织自动测试，orm model、原生数组、BO在工作量和清晰结构间的平衡，多终端多版本接口处理。
过度设计是人的问题，框架也不仅仅是一个mvc的分层器。
老兄这个话题很有前瞻性嘛，这个PR大概也是讨论这些东西的
https://github.com/laravel/framework/pull/26898
@willlin 嗯， 5.8已经把arr, str_踢掉了，哈哈哈
`单行代码`, 更多语法请见这里 Markdown 语法