过于灵活是一件糟糕的事情
优质
小牛编辑
132浏览
2023-12-01
举例说明
Laravel 文档和网上的各种教程,会教授我们一个任务可以使用好几种方法来完成。对于框架设计来说,灵活是件好事,能提供给开发者不同的选项,能让框架适用更多的用户场景。但是对于团队的协同开发来说,大部分时候,更多的选项反而是累赘。
下面来举一个例子说明,假如你在为项目开发 用户授权 相关功能,仅 注册用户权限
这块你就会有以下三个选项:
选项 1. 使用闭包:
你可以在 AuthServiceProvider
中使用 闭包注册用户权限
$gate->define('update-post', function ($user, $post) {
return $user->id === $post->user_id;
});
选项 2. 自定义类方法:
你可以在 AuthServiceProvider
中指定 类方法注册用户权限
$gate->define('update-post', 'SomeClass@method');
这个时候又有决策需要你去做:
SomeClass.php
放在哪个文件夹合适呢?- 方法应该怎么取名合适呢?
- 我放在这里是对的吗?
- 大家都是怎么做的呢?
选项 3. Policy 授权策略类:
你可以使用 Policy 授权策略类 来实现。如:
<?php
namespace App\Policies;
use App\User;
use App\Post;
class PostPolicy
{
/**
* 判断指定的文章是否可以被该用户更新。
*
* @param \App\User $user
* @param \App\Post $post
* @return bool
*/
public function update(User $user, Post $post)
{
return $user->id === $post->user_id;
}
}
结论
上面的例子,如果你独自开发个人项目倒是问题不大,最多一两年后回来看你的项目需要浪费点时间熟悉而已。然而,如果是在一个中大型的商业项目开发中,团队中有着几个甚至十几个开发者,没有规范的情况下,开发者会根据各自的喜好去选择,有时甚至出现一个开发者尝试多个选项的可能,就会造成整个团队产出的代码可读性极低,代码结构混乱,也为后面的项目代码的维护带来了难度。
与其无休止的争论哪种选项最好,还不如只知道 一种选项
。这 一种选项
能覆盖大部分的用例,且兼备开发效率、程序执行效率、扩展性、安全性等最佳实践,当再次遇到此类需求时,毫不犹豫地使用这 一种选项
直接了当地解决问题。
决策已提前做好,没必要浪费时间多次决策,节省时间,提高效率。
开发规范一旦统一,所有团队成员严格遵守,你会发现,你的队友写的代码就如你自己写的一样,编码愉悦感提高了,整个项目代码阅读起来更加流畅,工作效率自然也会因此提高,同时代码的健壮性也得到了保障。