漏れのある抽象化の法則（The Law of Leaky Abstractions）

先日、同僚との会話のなかで「漏れのある抽象化の法則」が話題にあがった。 初耳法則だったので、原文を読み自分なりの言葉でまとめたい。

原文と異なる解釈があるかもしれないので、Joel氏の記事を読むことをオススメする。

ざっくり3行要約

• 抽象化で便利になるけど、すべてのケースを完璧に網羅できない（= 抽象化の限界）
• 抽象化で作業時間は節約できるが、学習時間を節約できるわけではない
• どのような仕組みで動いているか理解できるようにちゃんと基礎を学ぼう

抽象化の力

OSI参照モデルやTCP/IPモデルなどで目にする「TCP/IP」を例にあげて「抽象化とは」について語られている。

Internet Protocol Suite
+-------------+
| Application | ← HTTPなど
+-------------+
| Transport   | ← TCPなど
+-------------+
| Internet    | ← IPなど
+-------------+
| Interface   | ← Ethernetなど
+-------------+

IP（Internet Protocol）は信頼性が低く、データが届かないことがある。TCP（Transmission Control Protocol）はそんなIPに関する処理を抽象化（隠蔽）し、データ転送の信頼性を高めている。 TCPのさらに上にあるHTTPを使うことで、我々はデータ転送そのものや信頼性を高める手法などを意識しなくても、 https://www.example.com というURLを使ってデータのやりとりができている。

抽象化の限界

TCPはIPを信頼性のある通信にするための抽象化だが、パケットロスや遅延などIPの特性を完全には隠蔽できず表面化してしまう。 そういったネットワークの問題を解決するためには、TPCの仕組みだけでなく、低いレイヤーにあるIPの仕組みも同時に理解しなければならない。

抽象化により細かな仕組みを意識しなくても使えるようになるため、作業時間が大幅に短縮できる。しかし、ソフトウェアエンジニアはHTTPを使うからTCPやIPの知識がなくて良いかというとそうではない。隠蔽された部分の仕組みを知らないと、問題が発生したときに解消できないからだ。