以前に思いついたジョークでこんなものがある。
初級プログラマへのアドバイス
コードを読みやすくするために、もっと抽象度を上げよう。
上級プログラマへのアドバイス
コードを読みやすくするために、もっと抽象度を下げよう。
これはジョークなんだけど、抽象度が低すぎても高すぎてもコードは読みにくくなる、というのはある程度当たっていると思う。
抽象化が低すぎるケースを考えてみよう。数百行もある長大な関数に何十もの変数があり、ループのネストはやたら深いし、しかも変数は途中で別の用途に再利用されちゃっている、なんていうとんでもないことになっているコードを見たことがはないだろうか？私はある。というのも私は長いこと、そんなコードばかり書いていたからだ。複数の関数に分割するなり、状態を構造体にまとめるなり、変数のスコープを制限するなり、抽象度をあげることでコードを読みやすくできる、ということを学んだのはだいぶ後になってからだ。
一方、抽象度が高すぎるケースとはなんだろうか？上級者となったプログラマは、関数やら構造体よりも抽象度の高い道具をたくさん持っている。リフレクションやら、コンティニュエーションやら、なんやらである。こういった技は適切な場所で使えば強力な武器となるが、乱用するとコードの見通しが悪くなるだけだ。これみよがしに乱用しているのでは上級者といえないのだろうが、適切な利用と乱用を区別するのは難しい。ある人にとって空気のように使える道具が、他の人にとってはそうとは限らないからだ。
ではどのくらいの抽象度が好ましいのかというと、それはプロジェクトによって異なると思う。ここでは仮に抽象度許容度なるものを考えてみよう。配列って一体なんなんですか！という人を１、C言語のポインタを普通に使いこなせる人を５、あらゆるプログラミングの奥義をマスターした、みたいな導師を１０、としよう。
まず、抽象度許容度１０のメンバーが集まったチームなら、やりたい放題だろう。この人たちのことは放っておこう。実際のところ、チームの中に許容度のばらつきがあるほうが普通である。この場合、一体、どのくらいの抽象度が好ましいのだろうか？直感的には、チーム全体でおおむね許容できるレベル、あるいはその少し上（慣れれば許容度は上がるから）、くらいでコードを書くのが好ましいように思える。しかし、Brian Kernighan の言葉によれば、少し下くらいの方がいいのかもしれない。
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." --Brian Kernighan
「デバッグは最初にコードを書くより２倍難しい。ゆえに、もし限界まで巧妙なコードを書いたなら、定義により、あなたはデバッグできるほど賢くないということだ」