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


我之前写过关于抽象成本的文章。一旦你在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

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