抽象化を嫌う理性的な理由を少し考えてみた

過度の抽象化はダメ、とかアーキテクチャ宇宙飛行士がどうこう、っていうのはまぁ正しいとして、普通に抽象化してもいいかな、って局面でも、まだ抵抗がある時があって、それがなんでかなぁと考えたという話。

おぶじぇくとしこーでふわふあーとかでざぱたもげもえーとか、 DI でむにむいーとか、そういった抽象化されて整理されたコードは全般的にメンテしやすくなって、ソースを変更しても汚くなりにくい、とかそういうのは一応わかってはいるつもりなのですが、常に絶対必ずやるべきだ、と言われると強い反感を覚えるわけです。

まぁもともと「絶対暴力はいけない」とかそっち系の命題は嫌いなのもあると思うのですが、プログラムにおける抽象化の場合はそれ以外にもあるなぁと。

で、何かっていうと、ちゅーしょー化はたしかに、数百行の変更には強くなるのですが、数十行以下のダーティハックはしにくくなるよな、と。

こいう話の時は必ず私が出すのは nethack なのですが、 nethack はちょっとした改造はひじょーにやりやすいです。殴った時にダメージの値出してみたいなーと思ったら、殴った時のメッセージで適当に grep してひっかかったとこをいじる、というような感じで基本的に OK 。他の例としては TCC なんかも。 TCC はワンパスコンパイラなので構造を変えるとかはむっちゃやりにくいですが、ちょっと文法を加えるくらいならあっという間にできたりします。

無論逆に数百行規模とかの大きな変更には弱いわけで、言語に関して抽象化なんかロクにされてなかった nethack では jnethack にする時に凶悪な量の #ifdef が入った、と。

と、抽象化を絶対善として見ずに、トレードオフとして考えると、企業の取るべき選択は…まぁとりあえず必要な抽象化はやっとけ、ってなると思いますはいそれはそうだと思います。企業とかの場合はどうせある程度コードについて理解がある人しかいじらない、人的リソースが有限な中で作業してるのだから、ダーティハックの需要はほとんど無いし。

でもオープンソースとかだと事情も違うんじゃないかなと。なんていうかダーティハックがうまくいくとパッチとか投げてみちゃったりして、さらに深くいじってみるようになったりするっていうことがあるような気がする。逆にちょっといじってみてうーんこれはきちんと理解しないと改造できないなーと思ったオープンソースものとは疎遠になっていくように思う。

オリジナルの開発者としては、こう共同でやれる人とかが増えた方が開発が進むことが多いわけで、トレードオフとしては企業でやる場合より抽象化を控えた方がいいかもしれないかなぁと。

でもっと言うとコミュニティとか形成したい場合はお高く止まった完全なコードを書くより、隙だらけのコード書いて修正させて仲間を増やしていく方がいい場合すらあるかもしれない。

つまり phobos がグダグダなのは Walter たんの策略なんだよ!