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

banq發表於2019-01-27
抽象

我之前寫過關於抽象成本的文章。一旦你在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


掌握正在發生的事情要困難得多，但至少他們會欣賞作者的聰明才智。
或者也許他們不會。

相關文章