数日前に、Evan Priestley氏への質問「どうやってプログラミングを覚えましたか」への回答を久々に見て、改めて思うことがあったので書いておく。読んでない方は是非読んでみてほしい。
https://web.archive.org/web/20121111232231/http://ktamura.com/epriestley.html
日々ビジネスに関わるシステムのデザインを生業としていると、自分の設計がその後に大きな影響を与えることを感じられる。この文章では端的に、作り込みすぎる「オーバーエンジニアリング」について語られている。これが実に面白い。
PHPについてのフレーズも実に良い。
> フェイスブックでは、ぼくは「一番PHPを嫌っていないエンジニア」と自称していた。ぼくのことを「PHPバカ」と呼ぶ同僚もいた。ぼくは別にPHPのファンではないが、PHPに関しては膨大な知識を持っているので、他の言語を学ぼうと一念発起するには、それこそ膨大なエネルギーがいるのだ。それに、どのプログラミング言語を使うかってのは、多くの人が考えるほど重要ではないと思う。ぼくの経験上、一番PHPをバカにし、言語の重要性をうそぶく連中は、大体自分たちが提唱する言語でもロクな仕事ができないことが多い。
相変わらずPHPというのは嫌われがちな言語だ。僕は10年近く（気がつけばもう10年もプロダクションでPHPを書いている）この嫌われがちな言語を書いていて、給料をもらってきた。ああ、こんな端的にロクな仕事もできないだなんておこがましくて言えないんだけど、これはよくある話だ。これまた最近話題になったWorse is Betterだって、言語それ自体ではなくあるシステムに関するアプローチを話しており、ところでどの言語でも過剰に書く人あり、「複雑巨大システム」は生まれる。実践、あるいは仕事のなかで複雑巨大システムに触れ、その問題に気がついていて、少しずつでも改善をできるならば、そのコードに食らいついて改善できるならば、「判断力をつける」ことにつながっているのだ。
> ぼくが知る限り、判断力をつける一番の方法は、自分で設計したシステムを長い間メンテすることだと思う。
例えば自分の設計したシステムを半年後に関われないなら、設計から得られるフィードバックは限られてしまう。特にデータモデリングの問題は時間が経てば経つほど設計判断の良し悪しがでてくる。果たして設計時点でどの程度システムにまつわる変化を想像できていたか。あるいは変化に備えすぎていないか。自分の設計したシステムでなくとも、当時の設計判断がどうしてそうなされたのかを汲み取り、自分の次の設計に活かすことができるか。判断力をつけるヒントは身近にあるが、それを拾って力にするのはなかなか難しい。
> 限りなくシンプルなデザイン(as simple as possible but not simpler)というのはなかなか教えられるものではなく、大方経験を重ねて覚えるものだ。
僕が働いていて最も素晴らしいと感じるエンジニアはすべて、限りなくシンプルなデザインを骨の髄まで染み込ませている。彼らの書くコードは常に「読みやすく」「わかりやすい」。なぜなら向かっているコトに対して向き合い、率直に問題を解いているからだ。何が問題であり、何をすべきであり、なぜそうしたかがわかるようにかかれている。コードコメントからは「なぜそうしなかったか」もわかるようになっている。コードそれ自体がシンプルであることは、システムを掘り下げ、理解し、必要な複雑さを計算し、感じ、噛み砕かなければ実現できないものだ。
シンプルなデザインを実現するための判断力を育てる一番の方法はペアプログラミングだ。なぜその方法で書かれたのかを、コードレビューで気がつくことは難しい。気がつけるならば、その実現方法の素晴らしさをわかるならば、自ら体現できるからだ。しかしシンプルさは、見た目のシンプルさ故に、簡単にみえる。簡単に表されているコードでも、その簡単さを実現するための設計プロセスを知るには時間がかかる。すばやく判断を積み重ね、あるいは無意識に良い方向に向かう程にそれを繰り返し、意識的な判断の必要な層を少なくしていった先に、頭に積み込めるスタックの範囲をスイートスポットにたどり着けるところまで縮めていって初めてシンプルな設計が現れる。次元の違う設計を体感するには隣で考えをトレースしようとすることが最も近道だ。しかしながら、あくまでそれは過程の体験であり、運用した時間をショートカットすることはできない。
力をつける方法は継続しかない。好奇心を持ち続け、思考し、実験し、これを繰り返すことでしか血肉にならないのだ。