我是 Laravel 开发员,不是 PHP 开发员
40

国外DISS PHP 的人很多很多,但是说Laravel坏话的没有。我发现很多Laravel 开发者不会想去 php.net 找答案,因为里面你所能看到的大部分函数, Laravel 有一个(或者多个)对应包裹 (Wrapper) 或者 函数。 做Laravel多了,甚至有种没有在写PHP的感觉。 我尽量不用PHP函数,理由如下:

  1. 保持代码标准。比如说函数应该是小驼峰,但是 PHP的函数都是蛇行 (snake_case)。现在业界的标准是,所有函数都应该是小驼峰 (camelCase),所有类都应该是大驼峰(CamelCase) , 所有常量 都应该是全大写 。 Laravel 本身的函数都是跟这个标准的, ( arr_search, str_replace 那类是例外,我基本上也不用他们)
  2. 流式接口 ( 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官方的标准非常相似。

Software Engineer Practices above all
软件开发标准高于一切

附言 1  ·  2周前

对不起各位,我有点标题党了。本文意思绝非贬低php原生

本帖由系统于 3周前 自动加精
《L02 从零构建论坛系统》
以构建论坛项目 LaraBBS 为线索,展开对 Laravel 框架的全面学习。应用程序架构思路贴近 Laravel 框架的设计哲学。
《L04 微信小程序从零到发布》
从小程序个人账户申请开始,带你一步步进行开发一个微信小程序,直到提交微信控制台上线发布。
讨论数量: 64
Summer

开发标准是团队的凝聚力表现 :+1:

3周前
feiffy

坚守同一个开发标准这一点很赞!

3周前

新接触的团队,总是排斥 laravel,虽然在用,
但是laravel的 定时任务不用,job不用等等,总说如果redis或者xx挂了咋办
我该怎么反驳?

3周前
Littlesqx

没必要这么吹,函数(不是方法)命名 Laravel 也是蛇形(https://github.com/laravel/framework/blob/5.7/src/Illuminate/Support/helpers.php );流式接口更不是 Laravel 独有,甚至其实是其他主流语言都常见的;至于 Collection,只不过是一种尴尬,只是因为 PHP 没有实现 scalar object,仅此而已。坦白讲,我不相信熟悉 Laravel 比 熟悉 PHP 好,我相信框架相比于语言更是工具。

3周前

函数本来就应该是蛇行,类的名称是大驼峰,类的方法和属性是小驼峰,命名是为了便于识别,你看看laravel的辅助函数是不是也是有蛇行的?

3周前
小无力

我相信框架相比于语言更是工具。

3周前
TimJuly

@839891627
哈哈,你问问他们 MySQL 挂了怎么办,要不也不要用了,直接往文件里写吧。

3周前
孙坤峰

不要用php 函数 【大写滑稽】

3周前

@839891627

新接触的团队,总是排斥 laravel,虽然在用,
但是laravel的 定时任务不用,job不用等等,总说如果redis或者xx挂了咋办
我该怎么反驳?

这么反问:自己造的轮子难道比社区开源一起维护的项目还要稳定吗。

3周前
BradStevens

对啊,标准能提升可读性和维护性,也能增加团队凝聚力

3周前

函数(不是方法)命名 Laravel 也是蛇形(https://github.com/laravel/framework/blob/5.7/src/Illuminate/Support/helpers.php );流式接口更不是 Laravel 独有,甚至其实是其他主流语言都常见的;

赞同。

坦白讲,我不相信熟悉 Laravel 比 熟悉 PHP 好,我相信框架相比于语言更是工具。

个人想法:两者没什么可比性。「熟悉 Laravel」能够让你在开发业务时游刃有余;「熟悉 PHP」,可以帮助你更加快速理解框架某些模块的实现原理。可以说是相辅相成的。

不过,在实际开发中,还是要尽量统一一套开发标准,不能部分人喜欢使用原生实现,部分人喜欢使用 Laravel 的辅助函数,就像 Summer 提到的 开发标准是团队的凝聚力表现

对此,我更倾向于:

  • 能够直接一条原生实现的需求,使用原生函数;
  • 不能直接原生实现,或存在一定损失的(例如使用数组函数操作 Collection)使用 Laravel 提供的函数 / 方法,以此避免重复造轮子;
  • Laravel 也没有提供实现的,或需要进行一定程度的修改定制的,尽量尝试继承、覆盖、重新注入等方式,以此尽量避免复制代码。
3周前
ibucoin

目前有些写法我会少用部分laravel提供的简便写法,比如whereAge这类的,属于你知道怎么用这个特性,但是新手看你的代码就一头雾水,不知道是哪里调用的。为了照顾新手,妥协很多地方。

3周前

统一开发标准用框架毋庸置疑,但是不深入原生PHP ,到头来也只会用Laravel了

3周前
Shuyi

@Littlesqx Laravel的蛇形其实是 Wrapper , array_search 其实就是 Arr::search , 不过为什么要保持这个,我猜是因为框架需要包容所有代码形式

3周前
Shuyi

@ibucoin 你说的魔法函数……额,我个人不推荐使用,Laravel还有更恐怖的魔法:


User::whereUserIdAndName(12, 'test user');

而且,魔法函数对性能及其不友好……所以,还是建议大家别挑战服务器的极限……

3周前
Shuyi

@Wi1dcard 同意,反正是团队决定,你函数要小驼峰,大驼峰,还是蛇形,都是标准。只不过我们团队很喜欢Laravel框架代码的写法,所以跟着了……他们的写法,和Java,还有C# (还有一些其他OOP语言)的标准相似,函数是小驼峰…… 但是我们是优先用框架提供的函数,想要追求那种原生的感觉和追求语法上的优美流畅。

3周前
Shuyi

@Caral 那是真的,我说的可能夸大了点,不过我在加拿大这边认识的很多Laravel开发,尤其是我这种90后的,很多有这种情况。不过讲真, 就比如说我,让写个index.php,收一个最简单的 POST 表格,一下子,我就愣住了……还是要想想, 哈哈哈。

3周前

@Shuyi

只不过我们团队很喜欢Laravel框架代码的写法,所以跟着了……他们的写法,和Java,还有C# (还有一些其他OOP语言)的标准相似

嗯嗯,赞同。尤其是 Laravel 的作者 Taylor 最早是一名 .NET 程序员,所以借鉴了一些其它语言的设计,并不局限于 PHP。再加上我本人早期做过 C#,刚接触 Laravel 的时候就喜欢上了它的风格,与其它 PHP 框架相比「更有面向对象的味道」,而且语法糖真是和 C# 一样众多。

3周前
Shuyi

@839891627 那你问他们,吃饭也会呛着,那不要吃饭了?喝水也会噎着,不喝水了?哈哈哈, 你同事也是滑稽

3周前
Shuyi

@Wi1dcard 语法糖还有自文档式代码风格都是我喜欢的。与其 return [] 我更宁愿写 return response()->json([]) ,与其写 function doSomething() 我更愿意写 function createUserAndPassword() , 毕竟我懒得写注释和文档,如果代码能一眼过去看得懂,长一点无所谓。 Laravel一大堆这些,每次看框架代码,都觉得是很享受的。

3周前

@Shuyi 对对对,一直觉得 Taylor 是绝对的起名大师。如果了解英语语法的话,写起来会非常顺畅,一看名字就知道是什么意思,整行代码连起来就像标准的句子一样通俗易懂。

3周前

这标题起的

3周前
largezhou

希望进一个这样的有规范的公司,,,

3周前

@Shuyi 魔法函数?魔术方法
函数和方法还是有区别的,感觉你说的很别扭,请别见怪

3周前

真的说出我的 :heart: 声 :joy: :joy:

3周前
aen233

laravel的辅助函数了解一下....
也是蛇形命名啊
还是想说,不要局限于语言,更不要局限于框架。。。。

3周前

集合没有交集函数 而php有

3周前

看这个帖子这么火,来来来打个广告了啊:RightCapital 招聘,喜欢规范的开发者们看过来了。

3周前
Shuyi

@lddtime 我其實是中文不夠好……哈哈哈, Magic Method 和 Magic Function , 英文的說法,方法和函數是指的一個東西……

3周前
Shuyi

@ivothgle 心声?有什么委屈么……哈哈哈

3周前

标准有用,你所谓的标准 见仁见智

3周前
tiegemen

@839891627
队友讲的对啊

3周前

@839891627 告诉他们,担心挂就部署集群,实现高可用,全部容器化,弹性可伸缩……

3周前
Shuyi

@太空牛仔 先生,读东西不要读一半,看清楚了再开炮不迟。

3周前
Shuyi

@Jinrenjie 用 Kubernete 么?感觉很高大上呢

3周前
Max

@Caral

实际上我个人一直以来的观点是,php并不值得深入.
我认为php的深入只有一个方面 便是阅读源码,阅读php的源码可能会带来三个层面的知识

  • 编译原理层面

  • C语言层面

  • 网络模型层面

编程学习的一个观点是,学习一样新事物时 拆轮子是非常不推荐的做法,尤其是php这种堆彻了近10年的轮子.

如果你想学习编译原理,可以通过视频/书籍教程来学习.尤其是一些经典书籍 其比直接阅读源码更加的易于学习,甚至能够学的更好,C语言层面/计算机网络编程同理

php无论是性能,还是外部接口表现都被各种诟病.
而对于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:

3周前

所谓的流式接口难道不是原生PHP写的吗?无非是返回了一个object

3周前

我再次发表一下我的观点:
少研究点框架和各种风骚的代码写法,以及绕来绕去的目录结构划分。
多研究下数据库和数据结构,以高效和高效率实现功能为核心思想以及唯一目标!

你们观察下那些生产力很高的程序员,他们都有个共同点: 十分重视数据库和数据结构的设计,很少纠结代码该怎么命名,代码该怎么换行,目录该怎么划分,做这些事的都是有点吃多了撑的。

3周前

当然了,也不是说标准不重要,只要一个团队功能遵守同一个标准就行,没有好坏之分。

3周前

@Shuyi 是啊,这个用起来省事很多,尤其是服务治理,无代码侵入

3周前
Shuyi

@Max 别忘了,PHP语言是设计来跑垃圾代码的 (忘了是哪位大佬说的了),你丢什么他都能跑。。。 像我本人是坚决反对触碰 WP 代码的,你想知道WP里面写了啥?一个函数你要找几十个文件还不一定有,因为人家是魔法函数。。。PHP创始人说他设计 PHP 7就是为了 WP 能跑得快些。。。我们做 Laravel 开发的,但是不一定会写 WP 的函数,也不定会写 Drupal 的函数, 因为 PHP 社区就是这么松散, Laravel 带动了大家标准化。

3周前
Shuyi

@jobsssss 重点是 生产能力很高的程序员 , 代码形式啊,目录啊,是为了 生产能力很高的团队 , 如果你就一个人写代码,还折腾这些,是的确过了。。。 不过标准的好处是,你把代码给别人了,别人还能继续工作下去。 我记得某位大大告诉我,记住,你代码写的不好,你的接班人不好维护,他可是知道你住哪里的...

3周前
Shuyi

@Jinrenjie 星星眼。。。我还在学,不敢把现在服务器弄成那样,不过以后肯定得,不是 Kubernete , 就是无服务器技术

3周前
Max

@Shuyi 关于标准这一块,我大概翻了一下评论,发现并没有人提到psr规范,只是围绕着团队规范。

上述提到的一些命名问题都属于表层代码规范

psr规范规划了表层的代码规范,规定了类的自动加载规则,类/函数/变量的命名规范,结构语句规范,函数参数等一些地方的空格规范,较为细化。

在phpstorm中 command+option+l,会默认把
代码按照该规范化格式
但是我从来没有按过该快捷键,因为我写的代码就是按着psr规范来的,连什么地方应该空格都是精准的😁

必须要提的一点是,psr规范的每一条规则都有其理由,其参考了编码界的常用规范,尊重了历史。而不是凭空想象,拍拍脑袋出来的东西。(其实很多的团队规范,就是拍拍脑袋,或者以技术负责人的习惯来定)

比如我曾经有一个团队 $_ 来命名变量,但是这真的有意义吗?

psr规范最重要的一点是,使得composer能够推行,composer的意义我就不言而喻了。

laravel的产生很大程度就是因为php社区有symfony这样优秀的composer扩展

当然laravel/symfony以及所有的composer包都是遵守psr规范

关于团队规范制定我的几点看法,当然laravel社区的laravel开发规范的第一点就已经提到了这些问题。
下面的几点不仅可以作为规范的制定,甚至可以将其作为个人的开发哲学,遇到问题时的指导思想

  • 最佳实践,实际上任何问题,任何存在的东西,如文中,平均中提到的规范等,都有其现阶段的最佳实践,编程人员要做的事情无非就是尽量的接近,或者找到它!

  • 官方推荐,这一点是找到最佳实践的首要参考依据,psr规范就是第一参考要素,团队需要做的就是拿来使用,并且把psr规范中的都可以,变成只可以。把psr规范中遗漏的进行补充,对深层规范进行细化

    psr自身制定时的官方就是php团队,psr规范也尊重了php本身

  • 主厨精选,让有经验的人来为你做出选择。但是这个有经验的人并不是个人,最好是一个团队,并且是一个有经验的团队。如阿里团队的java开发手册,其除了表层规范外还规范了深层的一些规范,如逻辑流的写法/面向对象的规范/mysql规范, 其中大部分规范,对所有语言,所有团队都有指导意义 ,当然其中一些java特有的规范可以忽略。

  • 尊重大多数人的想法,当上面两点都不能让你找到最佳实践时,那么大多数人的做法对你来说会是一个不错的选择。实际上官方制定一个新的规则时,也会反过来将大多数人的做法作为重要的参考依据

  • 简洁之道, 这是贯彻我个人整个编程生涯的一点,简洁之道并不特指编码,其包含测试流程,整个开发流程,逻辑流程,发布流程等等。其在各个专业可能都有相应的书籍,编码类的经典书籍,如《代码简洁之道》

忽然发现字好多,可以水一篇博客了,不过我个人并不是很喜欢写这种情怀向的博客。
手机打字,所以没有做矫正,见谅。

3周前
MushishiXian

要有敬畏之心

3周前
allen9009

所谓你说的现在的业内标准是你们自己觉得的,标准不是一个团队指定出来的,每个团队在遵循psr前提下都有自己的标准,而且用la的不是php开发者,难道是java?

3周前

@Shuyi
@Max 讨论继续火热,想起来一张图:

file

3周前
allen9009

@Caral 十分赞同,一个php开发者不认为自己是php开发者,这就非常致命了,要知道框架只是工具,语言才是本质

3周前

感觉还是不要自我设限比较好,laravel是用的,不是打标签的。

3周前
panda-sir

一般都是遵循团队的命名习惯 但书写习惯我一般都养成固定的了 我不倾向用ide的自动格式化代码功能快捷键 这样会破坏git对文件编辑的记录 在我git blame 找代码的具体信息的时候就找不到具体写的人了 我感觉我已经强迫症晚期了 :smiling_imp:

3周前
等车的猪

虽然我也喜欢laravel,但是奉劝你一句。不要学了点皮毛就到处秀智商,真理是越是大佬越是谦虚,越是无知越是膨胀

3周前

laravel再怎么牛逼还是php框架,什么叫做是Laravel 开发员,不是 PHP 开发员。学到点laravel皮毛就在这里装高大上。就像你嫌弃你爸一样

3周前

哈哈哈哈啊哈哈哈噢噢噢哦哈哈哈哈

3周前

@Shuyi 我以血泪经验告诉你,一份设计良好的数据库结构和业务数据结构,对于项目的可维护性而言,远远大于风骚的代码组织形式。
风骚的代码组织结构,在90%甚至是99%的场景下,带来的困扰远远大于收益。
我手中有一份7年前的php写的接口,这份接口代码超过了2万行,没有使用任何框架,变量命名各种风格都有,但是数据库结构完整的描述了业务逻辑,所以即便是新人,拿着源码只用了一天就可以进行开发工作了。

另一个项目则是前年用Laravel构建的,我也是手贱,被laravel灌了迷魂汤,各种DI,service,IOC,response都用上了,还自我吹嘘这是“优雅”,扩展性强,现在再看这个项目,没人愿意接手,我自己都特么想把那时候的我纠出来锤一顿。

最后奉上一句linus的话:Code is shit,Data structures are the soul.
代码都是垃圾,数据结构才是灵魂

3周前

@allen9009 认同,博主有点本末倒置了。

2周前

说点题外话:我现在招人的时候,都有点不敢用那些自称精通laravel和yii,zendframework的人了。好几个这样的人,都有一个共同点,活干不出来什么,却喜欢在项目中搞一大堆乱七八糟的设计,这样做给项目带来益处了吗?事实上并没有,比如我交代一个哥们,写一个代码,用来替换现有的金币查询逻辑,简简单单一个函数或者方法就完成了,结果这哥们儿搞了半天,测试的时候还老是不通过,我不信邪,看了下他的代码。我滴妈呀,就这么个简单的需求,这哥们又是单例,又是要解耦,还要弄成组件,业务先撇开不谈,一测试报错全是他这些设计带来的。什么问题没解决,他倒是又引入新的问题要解决,我愤怒的让他滚了。

2周前
Shuyi

@jobsssss 这个是另一个问题,叫过度工程。很多时候很简单的事情,一定要复杂地弄,这人也有。就是一个尺度拿捏的问题。。。你说的这种人我见过几个,空话很多,实干很少。比如说我们团队不用单例,能用一行写的,坚决不用两行。。。

2周前

@jobsssss 怎么说呢,我是觉得现在鼓吹框架的人和文章实在太多,导致大部分初学者糊里糊涂就开始学各种框架,对于其中框架怎么运行的不甚了解。不可否认框架在加速开发中起到的很大的作用,但这也导致他们在遇到问题时排查不了或是要花更多时间。
框架跟业务能力挂钩。原生跟技术能力挂钩。见仁见智吧。

1周前
Kamicloud

@jobsssss @Shuyi
七年两万行也就是个很小的项目,这种程度不要说框架的单元测试,甚至连orm都可以不用
项目越大,变动越频繁框架的作用才会慢慢体现出来。合理地组织自动测试,orm model、原生数组、BO在工作量和清晰结构间的平衡,多终端多版本接口处理。
过度设计是人的问题,框架也不仅仅是一个mvc的分层器。

5天前

老兄这个话题很有前瞻性嘛,这个PR大概也是讨论这些东西的
https://github.com/laravel/framework/pull/26898

3天前
Shuyi

@willlin 嗯, 5.8已经把arr, str_踢掉了,哈哈哈

2天前

  • 请注意单词拼写,以及中英文排版,参考此页
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`, 更多语法请见这里 Markdown 语法
  • 支持表情,使用方法请见 Emoji 自动补全来咯,可用的 Emoji 请见 :metal: :point_right: Emoji 列表 :star: :sparkles:
  • 上传图片, 支持拖拽和剪切板黏贴上传, 格式限制 - jpg, png, gif
  • 发布框支持本地存储功能,会在内容变更时保存,「提交」按钮点击时清空
  请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!