一个月的清洁代码

过去一个月里，我每周都会发布一些代码示例的前后对比，分享一些清理代码的方法。这些示例的反响非常热烈，很多都获得了数百个赞。虽然我会继续分享这些每周清理代码的示例，但我想把之前分享的都整理成一篇帖子。

分解长方法

在第一条推文中，一位开发人员提交了一个冗长的 Laravel 控制器操作，他们想要对其进行清理。从高层次来看，该控制器操作处理了一个课程注册请求。从低层次来看，该代码有两个用于注册用户的路径。

在评估一个长方法时，主要要问的问题是谁负责这段代码？这个问题的答案将有助于确定代码是否可以移到其他地方。在本例中，用户的创建可以移到模型中。我们还可以通过创建一个私有的条件方法来简化这两条路径。此方法会在必要时执行创建用户的分支逻辑。

最终结果是方法体量大大减小。有人可能会说我们只是移动了代码。然而，我们原始方法的目的更加简洁，其组成部分也更加易于理解。两者都改善了代码的沟通——而这正是衡量代码整洁的标准。

正如 Twitter 上指出的那样，after代码确实存在一些错误，例如缺少参数createUserIfUnauthenticated。不过，这些都是小错误，不会影响清理工作。

利用对象

第二条推文是一位开发者提交的 Laravel 控制器操作。从高层来看，该控制器操作负责存储上传的图片。从底层来看，控制器自己处理所有事情——验证、图片处理、存储。

为了简化这段代码，策略是利用其他对象来处理所有事情。Laravel表单请求对象可以用来进行验证。我们可以采用存储库模式来引入一个对象来协调图像的存储。

与之前类似，结果是一个更小的方法。这次的不同之处在于利用了框架中现有的对象。我们还应用了一个适合我们代码的模式。开发人员常常反过来做这件事——让代码适应模式。让模式从代码中自然而然地显现出来，是一种更简洁的方法。

清理条件代码

第三条推文重点关注了清理构成我们代码库大部分的条件代码。这是迄今为止最受欢迎的清理工作。可能是因为其基本代码使其能够应用于多种语言。

这些清理工作大多属于“编写整洁代码”实践的第三条——避免嵌套代码。任何时候，当你想清理条件代码时，都要问自己两个问题：

1. 我可以直接退回条件吗？
2. 反转条件逻辑是否可以改善沟通？

发现原始的痴迷

第四条推文重点关注如何发现“原始数据类型痴迷”。我们对使用原始数据类型的痴迷常常导致相关代码的重复。由于代码并非完全相同，因此更难发现。随着时间的推移，这些代码会渗透到系统中，越来越难以清理。

这些技巧并未详细阐述这些值对象的一些额外特性。几乎与它们提供的封装同等重要的是，它们是不可变的。这限制了状态，使得它们相对轻量级地添加，甚至更易于维护。有关 的更多详细信息和示例Range，请阅读Martin Fowler 撰写的 RangeObject。

是的，我绝对会重构limit()，利用数组过滤。接下来的清理工作如下：

function limit($items, Range $range)
{
    return array_filter($items, function ($item) use ($range) {
        return $range->includes($item);
    });
}

想要更多清洁技巧？ 关注我的推特，获取每周小贴士，或订阅我即将发布的现场指南。