そこにいるプログラマの動機

わたしは、プログラマとしてはたぶん中級レベルだ。
業務仕様を理解し、コーディングし、テストしリリースし、運用サポートする。

良いソリューションを作るためにはどうしたらよいかを考えて、その考えを実行する。
顧客の要件を聞いて、モックアップを作り同意を得て、要件定義をFixする。

コーディングは他の開発者に比べて早いみたいだがバグを出す。
明示的バグではなく、拡張性、応答性、安全性に支障をきたすコーディングバグがしばしばある。いわゆる、アスペクト領域のバグだ。
要件定義にそんなアスペクトが記銘されていなかったというのは理由にしたくない。

わたしはトッププログラマになろうとか、不可能を可能にするソリューションを提供するとか、そんなことは望んでいない。
良質のコードを書きたいという動機は、誰よりもよい報酬をもらいたいという理由ではない。
これを現場のプログラマに仄めかすと、ぽかんという顔をされる。
お前は、職人でもなく、労働者でもない、じゃあなんなんだ、ということだろう。

J2EEや.NETの技術が素晴らしいものであるとして、わたしはそういうものを作るという動機はない。宇宙に行って月を直にみてみたいと思う人がいる一方で、そんなことをしたいと思わないともいる人がいるだろう。それよりも、その成果で実現されたガンダニウム合金を使って何かを作りたいというほうが、わたしには面白そうに思えるというだけだ。

デザインパターンの本には、書かれていない素晴らしいことが書かれている。
デザインパターンをカタログ化し、それがどのような動機で適用されるべきで、どのような効果があり、どのような副作用があるか。
それはとても洞察に富んでいる。そしてそれはとても興味深く観察できるだろう。
そして、読み終わるとき、デザインパターンの本は黙ってプログラマを見ている。だぶん、読み終わってしまった以上、彼は何もいわないだろう。たとえ、読者が何か言ったとしてもそれ自体はなんら返答しない。
注意深い優秀なプログラマはこう説明するだろう。
このクラスは、利用者が将来カスタマイズし、そこでの固有のアルゴリズムだけをカプセル化するためにtemplate methodにしたいと。
懐疑的な実存的人間としてのプログラマはこう誰に向かってでもなく説明するだろう。
このパターンを適用する動機は、これで当初の問題は解決し、コーディングもうまくいく。なにより楽ができる。これはわたしの動機で、このパターンの動機を貶めるものではない。もし、このパターンを貶めると感じるのであれば、空いた時間をこのパターンの有用性について宣伝してもいい。そのほうが、無駄なコーディングをしているよりも少しはマシだ。