SOLID：不要成为只‘压平’函数的程序员 🛑

Source: Dev.to

你是否曾经害怕动一行代码，因为你知道系统的另一端会因此崩溃？我也有过这种经历。

很长一段时间，我只是在跟随设计不佳的代码继承；把一个功能“压平”在已有的代码上，既不改进也不优化，只是因为害怕或时间不足。但我学到，编程不仅要今天能运行，还要明天可维护。

S: Single Responsibility (单一职责)

这看起来很明显：一个类只能有唯一的存在理由。我们通常会认为 User 类不应该处理支付或发送大量邮件，对吧？但我们会陷入更微妙的陷阱。有时我们会把密码验证、登录逻辑甚至会话管理都塞进同一个类。

结果： 一个知道太多的类，变得难以测试或修改。用户是实体，而不是安全编排器。

代码的改变

与其拥有一个“瑞士军刀”式的类，我们把数据和基础设施逻辑分离：

// 实体：仅表示用户是什么以及其核心数据
class Usuario {
    public string $email;
    public string $passwordHash; 
}

// 服务：负责认证逻辑
class AuthService {
    private $hasher;

    public function __construct(PasswordHasher $hasher) {
        $this->hasher = $hasher;
    }

    public function login(Usuario $user, string $password) {
        if ($this->hasher->verify($password, $user->passwordHash)) {
            // 启动会话的逻辑...
        }
    }
}

不仅要写代码，还要做工程

我邀请大家停止只会“压平”代码的做法。当你发现一个函数写得糟糕时，不要只在上面再加一层。重构、清理并应用 SRP（单一职责原则）。

把代码恢复到你第一次看到时的那种美观和可读。可以放心，后来的开发者阅读你的工作时会说：“谢谢”。

你是否也遇到过类似的遗留代码问题？欢迎在评论区分享！ 👇