我是 Laravel 开发员,不是 PHP 开发员
国外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 语法