はじめに
Joel Spolskyさんの記事「漏れのある抽象化の法則」を要約したのでシェアします。
結論
抽象化されたものは便利だけど、使う時は仕組みを知ってから使おう。
抽象化とは
TCP. It is what computer scientists like to call an abstraction: a simplification of something much more complicated that is going on under the covers.
→TCPは、コンピュータ科学者が「抽象化」と呼ぶもので、もっと複雑なことを単純化し、その下で行われています。
ざっくりいうと以下の意味かと思います。
- 中で行っている「複雑なこと」を、外からは単純な方法で使えるようにすること
- 外からは「複雑なこと」をどのように実現しているかは見えない
- 単純化されてるおかげで、本来気にしなくちゃいけないことも意識せず行えて便利
抽象化の漏れとは
上述の抽象化に漏れがあること。
これにより抽象化されたものだけじゃ問題に対処できなくなってしまう。
車の例が分かりやすかったです。
your car has windshield wipers and headlights and a roof and a heater, all of which protect you from caring about the fact that it’s raining (they abstract away the weather), but lo, you have to worry about hydroplaning (or aquaplaning in England) and sometimes the rain is so strong you can’t see very far ahead so you go slower in the rain, because the weather can never be completely abstracted away, because of the law of leaky abstractions.
→車にはワイパーも ヘッドライトも 屋根も ヒーターもついていて 雨が降っていることを気にしなくて済むようになっています （天候を抽象化しています） しかし、ハイドロプレーニング（イギリスでは アクアプレーニング）を心配しなければなりません 時には雨が強くて前がよく見えないので 雨では速度を落とします なぜなら天候は抽象化の漏れという法則により 完全に排除することができないためです。
抽象化の仕組みを理解して使おう
この記事では抽象化されたものをただ使うのではなく、
仕組みを理解して使うことが推奨されています。
抽象化されたものを思考停止して使っていると、
問題（抽象化の漏れ）が起きた時に対処できなくなるからですね。
問題というのは中で行っている「複雑なこと」のどこかのステップがコケてるということなので、
中で何が起きているのか知らないと原因を特定できないです。
僕は最近プライベートでDockerを触り始めたんですが、まさにこの状態になりました。
とりあえず設定ファイルを見様見真似で書いたはいいものの、依存関係やコンテナ内部の設定に問題が起きた時に、どこをイジればいいのか分からず困ることが多かったです。
もちろん全部の仕組みを網羅するのは厳しいと思います。
最初から全部理解しようとすると、
勉強のハードルが上がったり時間がかかったりするので、「とりあえず手を動かしてみる」というのが必要な場面もあるかと。
ですが初期コストをかけてでも仕組みを理解することで、開発トータルで見ると得するんじゃないかなと改めて感じました。
以下の言葉が本質をついているように思えます。
So the abstractions save us time working, but they don’t save us time learning.
つまり、抽象化によって作業時間は短縮されるが、学習時間は短縮されないのだ。
終わりに
「強いエンジニアは仕組みを理解してから手を動かす」
と耳にすることが多かったんですが、その理由が言語化できてよかったです。
本能に逆らって、仕組みの理解から入る習慣を少しずつ実践していこうと思います。