c# - 从简单方法中删除重复代码 - 做得太过分了吗？

Question

我有一个 WCF 服务，其中包含许多(~30)种方法，如下所示:

public Foo GetFooById(string id)
{
    try
    {
        return FooLogic.GetById(id);
    }
    catch (Exception ex)
    {
        throw LogAndThrowFaultException(ex);
    }
}

除了 try block 中的一行之外，这些方法中的代码完全相同。这已经很简单了，我什至已经抽象了日志记录和抛出异常。

本着 DRY 的精神，我可以走得更远:

public Foo GetFooById(string id)
{
    return PerformServiceOperation<Foo>(() => FooLogic.GetById(id));
}

为此，此方法将处理重复的 try/catch 代码并调用每个函数:

private T PerformServiceOperation<T>(Func<T> func)
{
    try
    {
        return func.Invoke();
    }
    catch (Exception ex)
    {
        throw LogAndThrowFaultException(ex);
    }
}

这会不会太过分了？代码是否已经尽可能简单了，是否应该保留它？还是将 func 传递给辅助方法并让该方法处理重复的 try/catch 是个好主意？我也关心可读性。我认为对辅助方法的调用有点难看。

Answer 1

我不得不说，一般来说，在生产代码中，我倾向于认为应该将 DRY 发挥到极致。在过去的几十年里，我有几个原因。

1) 传播一个地方的“修复”。您建议的像这样的简单修复可以节省数小时的 QA 弹跳代码，因为另一种方法无法通过简单测试。这也许是一个极端的案例，但我已经看到它发生了。此外，尽管您知道此代码已被复制并且您必须在多个地方进行修复，但下一位工程师是否知道这一点？

顺便说一句，一个可行的替代方案是记录每个位置代码被复制以引用其他位置，以便维护者知道去哪里。

2) 程序员能力。通过坚持绝对 0 代码重复，您将学习到使您成为更好工程师的技术。我见过很多代码，工程师坚持认为他们不能让它变得更干——但我自己做了十几次(可能使用了像你在这里使用的那样的技巧)因为我d 不得不在某个时候弄清楚它。

3) 可能是最不明显但最重要的——迭代重构。重构通常只能分层进行。您肯定看过一堆困惑、难以理解的代码，并且只看到了最次要的重构——但是在重构之后，其他的变得清晰，并且使其他的成为可能。我采用了每个人都不敢触摸的巨大方法，并通过这种方式将它们缩小到原始尺寸的 1/10。

4) 数据提取。如果你坚持 DRY，你最终会得到很多批数据，因为最基本的重构之一是从相似的代码中提取不同的数据，然后组合代码。这使您的代码更易于维护——过去我经常能够通过更改字符串数组来解决问题，而在重构之前通常需要数小时或数天。

无论我到过哪里，我都必须让人们相信这一点(你只要看看对这个问题说“不”的人数就可以看出这一点)。 Extreme DRY 一开始通常很难推销——直到他们看到结果。我认为您个人可以做的最重要的事情就是尽您的才能让您尽可能地干(随着您的练习，干得更多)。

如果您列出的特定重构结果导致问题，那么，您已经学到了一些东西，下次可以采用不同的方法。您学到了，时间没有浪费。

顺便说一下，你会了解到以一种其他人可以理解和使用的方式编写你的极度枯燥的代码是至关重要的——这并不总是那么容易，并且可能会导致一些人讨厌“重构”和“过度工程”，直到他们发现编写代码的人在沟通(通过代码)方面不够好。

PS:我应该提到另一个 - 因为编码 DRY 很有趣。复制和粘贴代码(并修复该代码)是作为程序员可以做的最痛苦的工作，但是创建仍然可用和可维护的简短 DRY 代码是一种精神挑战，是任何称职的工程师都应该享受的难题。