一部の「抽象化」は実際には単なる間接参照の層だと論じるエッセー

# 一部の「抽象化」は実際には単なる間接参照の層だと論じるエッセー

発生日：2024-12-25

ソフトウェア設計についての新たなエッセーが、この分野で最も使い古された言葉の一つを批判している。主張は単純だが鋭い。すべてのラッパー、クラス、インターフェースが抽象化と呼ぶに値するわけではない。中には本当に役立つ抽象化もある。だが、コードをたどりにくくし、理解のための思考を遅らせ、保守費用を高めるだけの間接参照の層もある。

この投稿は、明快な例としてTCPを挙げている。TCPは、パケット損失、再送、順序制御という煩雑な詳細を隠すため、優れた抽象化だと説明されている。大半の開発者はその内部を見る必要がほとんどなく、その見えなさこそが肝心だ。抽象化が機能しているなら、その利用者は、下層の複雑さがなくなったかのように操作できるはずだ。

続いてエッセーは、同じ考えの暗い側面へと話を転じる。単にデータを転送するだけの薄いラッパー、処理を次へ渡す以上のことをほとんどしないメソッド、意味を加えずに形式的な手順だけを増やすクラス階層は、洗練された設計ではなく負担として扱われる。人間の読み手は、新たな利益を何も得られないまま、確認すべき場所と把握すべき関係を増やされるため、認知負荷が高まる。

この批判は性能にも及ぶ。著者は、層を一つ余分に加えるたびに、概念上のコストだけでなく計算上のコストも生じると主張する。システムをデバッグしたり最適化したりする際、エンジニアは実際の処理にたどり着くまで、それらの層を一つずつ剥がさなければならないことが多い。間接参照が増えるほど、チームはハードウェアから遠ざかり、プログラムが実際に何をしているのかを把握しにくくなる。

エッセーで特に鋭い指摘は、抽象化が、それと共に生きなければならない人々よりも、それを作った人に多くの恩恵を与えがちだという点だ。著者は、最初の開発者はすぐに見た目のすっきりしたコードを享受する一方、保守の負担は、バグを修正したり、性能を改善したり、機能が期待どおりに動かない理由を理解したりしなければならない次の人にのしかかると示唆する。その意味で、悪い抽象化は一種の先送りされたコストである。

このエッセーは、抽象化そのものに反対しているわけではない。実際、その論旨は、優れた抽象化がソフトウェアエンジニアリングに不可欠だという考えを前提としている。その主張はより限定的かつ実践的だ。設計が本当の複雑さを隠さず、コード内の経路だけを隠しているのであれば、それを抽象化として称賛すべきではない。それは単なる余分な層だ。著者が提案する試験は、ほとんど会話的な問いである。「どれほど頻繁に内部をのぞかなければならないのか」。その頻度が低いほど、抽象化が役割を果たしている可能性は高い。

この捉え方は、多くのエンジニアが感じていながら必ずしも口に出さないことと一致するため、共感を呼びそうだ。システムはモジュール化されているように見えても、その中で作業するのがひどく苦痛な場合がある。このエッセーの真の貢献は、その問題を明快に名付け、単なる構造ではなく明瞭さこそが、抽象化を評価する基準であるべきだと主張したことにある。