Laravel 项目开发规范 过于灵活是一件糟糕的事情

举例说明

Laravel 文档和网上的各种教程，会教授我们同一个任务，可以使用好几种方法来完成。

对于框架设计而言，灵活是件好事，能提供给开发者不同的选项，能让框架适用更多的用户场景。

但对于团队开发来说，大部分时候，更多的选项反而是累赘。因为每个人都可能写出不一样的代码，这无疑增加了项目维护的难度，影响效率。

重点： 规范化，其实就是在减少这些选项。选择一个最优的方案，然后所有人遵循，即可让所有人编码思维统一起来。

下面来举一个例子说明，假如你在为项目开发 用户授权 相关功能，仅 注册用户权限 这块你就会有以下三个选项：

选项 1. 闭包：

你可以在 AuthServiceProvider 中使用 闭包注册用户权限

Gate::define('update-post', function (User $user, Post $post) {
    return $user->id === $post->user_id;
});

选项 2. 类方法：

你可以在 AuthServiceProvider 中指定 类方法注册用户权限

Gate::define('update-post', [PostPolicy::class, 'update']);

这个时候又有决策需要你去做：

• ​SomeClass.php​ 放在哪个文件夹合适呢？
• 方法应该怎么取名合适呢？
• 我放在这里是对的吗？
• 大家都是怎么做的呢？

选项 3. Policy 授权策略类：

你可以使用 Policy 授权策略类 来实现。如：

<?php

namespace App\Policies;

use App\Models\Post;
use App\Models\User;

class PostPolicy
{
    /**
     * 确定用户是否可以更新给定的帖子
     *
     * @param  \App\Models\User  $user
     * @param  \App\Models\Post  $post
     * @return bool
     */
    public function update(User $user, Post $post)
    {
        return $user->id === $post->user_id;
    }
}

结论

上面的例子，如果你独自开发个人项目倒是问题不大，最多一两年后回来看你的项目需要浪费点时间熟悉而已。

然而，如果是在一个中大型的商业项目开发中，团队中有着几个甚至十几个开发者，没有规范的情况下，开发者会根据各自的喜好去选择，有时甚至出现一个开发者尝试多个选项的可能，就会造成整个团队产出的代码可读性极低，代码结构混乱，也为后面的项目代码的维护带来了难度。

与其无休止的争论哪种选项最好，还不如只知道 一种选项。这 一种选项 能覆盖大部分的用例，且兼备开发效率、程序执行效率、扩展性、安全性等最佳实践，当再次遇到此类需求时，毫不犹豫地使用这 一种选项 直接了当地解决问题。

决策已提前做好，没必要浪费时间多次决策，节省时间，提高效率。

开发规范一旦统一，所有团队成员严格遵守，你会发现，你的队友写的代码就如你自己写的一样，编码愉悦感提高了，整个项目代码阅读起来更加流畅，工作效率自然也会因此提高，同时代码的健壮性也得到了保障。