对抽象方法仇恨的自白 - 250bpm

19-01-27 banq

我之前写过关于抽象成本的文章。一旦你在IT行业工作了几十年，一旦你在遗留代码上阅读了数百万行，你就会对任何一种抽象产生正常的怀疑。并不是说我们可以不做抽象。我们需要它能够编写代码。但是，每次在代码中遇到可以避免的抽象时，您都会感到更加悲伤。有些代码库比罗密欧与朱丽叶和李尔王结合起来更悲伤。
还记得上次读一个不熟悉的代码库吗？还记得你是怎么认为作者是一群无能的白痴？
人们可能会争辩说这是因为遗留的东西必然是错综复杂的，但是嘿，那时候你只是浏览代码库而你并没有深入了解它，你生气的原因是因为你被大量不熟悉的抽象所淹没。（为了证明这一点，考虑一下你对代码库的看法是几个月之后，在熟悉之后。看起来好多了，不是吗？）
牢记这种感觉。在编写新代码时可以考虑它。一个不了解这个代码库的人在阅读时会有什么感受？
选项不合适。要么你想要聪明，要么使用抽象，他们会认为你是个白痴。或者你摆脱了所有不必要的抽象。你会让他们的生活变得更加沮丧，但他们会认为你是某种傻瓜。（他们可能会重构代码，使其看起来更聪明。）
我想给出一个非常基本的例子。
想象一下，要求是你的程序按顺序执行A，B，C，D和E.
你可以用最愚蠢的方式做到这一点：

void main() {
    // Do A.
    ...
    // Do B.
    ...
    // Do C.
    ...
    // Do D.
    ...
    // Do E.
    ...
}

或者你可能注意到B，C和D是相关的，并构成一个逻辑工作单元：

void foo() {
    // Do B.
    ...
    // Do C.
    ...
    // Do D.
    ...
}

void main() {
    // Do A.
    ...
    foo();
    // Do E.
    ...
}

但是C作为一个独立的功能可能会更好。您可以想象一下某人想要从其他地方调用它的情况：

void bar() {
    // Do C.
    ...
}

void foo() {
    // Do B.
    ...
    bar();
    // Do D.
    ...
}

void main() {
    // Do A.
    ...
    foo();
    // Do E.
    ...
}

现在从休闲读者的角度来考虑它，一个只是浏览代码的人。
当他们查看代码的第一个版本时，他们可能认为作者是一个简单的东西，但他们可以轻松地阅读它。它看起来像一个故事。你可以把它看成是一部小说。那里没什么好混淆的。部件的顺序正确：

A
B
C
D
E

但是，当浏览重构的代码时，不再是这种情况。你看到的是：

C
B
D
A
E

掌握正在发生的事情要困难得多，但至少他们会欣赏作者的聪明才智。
或者也许他们不会。