ご紹介

はじめに

 皆さんの仕事は何でしょうか。この記事が目についたということは少なからず、仕事でコードと関わる機会がある方が多いと思います。
 私は、コードを書く・読むということが中心の仕事をしています。プログラマ 35 歳定年説というものを聞いたことがあるかもしれませんが、もうその定年をすぎました。この位の年齢になると、マネジメントに専念しコードをほとんど書かない・読まないという友人・知人もいます。この本では、個々人のキャリアがどうあるべきか、という話は一切しません。
 ここでは「なぜこれを書くにいたったか」の簡単な経緯を述べたいと思います。私の仕事人生は、新規でシステムを構築するということももちろんありましたが、既に構築されたシステムに対してあれこれをする、ということがほとんどでした。これからもそういう時間のほうが多いだろうと思います。
 これまで様々なコードに出会いました。残念なことに、そのほとんどが修正する・理解することが難しいコードでした。"ぼや"かもしれませんが何かしらの炎上を経験したコードです。
 これにはプログラマの責任もありますが、状況がそうさせていることの方が多いと思います。
 プログラマの悩みは尽きません。アーキテクチャをどうするか、設計・コーディングをどうするか、この顧客とはどう接するべきか。そして、納期と自分の書くコードの間で悩む時間があります。
 これはプロジェクトを進めていく上で、品質・納期・コストのバランスを取ることに似ているかもしれません。これらは"プロジェクト"という単位で考えた場合、プロジェクトマネジメントの力で解決することがほとんどです。しかし、プロジェクトは必ず終結しますがシステムは継続します。しかも価値が高いシステムほど継続し、規模は大きくなります。
 つまり、納期とこれからのシステム(別の言い方をすれば今後コードを読む人々)とのバランスをいかに良い状態に保つか、その方法を選択することがプログラマの悩みと言えます。
 そして納期を優先して生み出されたコードがシステムを運用・保守をする人々の時間を奪っていきます。
 例えば以下の処理をみてください。 

/**
 * ◯◯をする処理です。
 * この処理は重いのでループなどで呼び出さないでください。
 */
 public void xxxxx() {
   //...ものすごく長く重いであろう処理。
 }

 一見、コメントには優しさのようなものが見えます。
 しかし、調査を進めてみると、このコードは実際にはループで呼ばれていました。どうでしょうか?
 既に何を信じれば良いのかわからなくなりました。コードを理解するのに悩まされている間に、ベストな方法を選択するための時間が消費されました。このようなことの小さな積み重ねで悪循環のでき上がりです。
 しかし誰にも、システムを止めることも機能追加を止めることもできません。
 私は、このコードを読む・書くという時にプログラマが悩む時間を減らす事ができないだろうかと考えました。
 コードに関わらない部分のソリューションももちろんあります。しかし私が一番時間を使ってきたのは間違いなく、コードを読んで理解し、どうすれば読む人にとって負担が少ないコードになるかを考え、どうやってそれを書き上げるか、ということでした。
 私が悩んでいた細々とした悩み事の解決策を提示することで、選択肢を増やし・余計な時間を取るコードが減ることを願い、「これ」を書いてみようと思いました。
 私は日々、地味にコードと向かい合っています。今まで、多くの素晴らしいプログラマが私を助けてくれました。例えば Java や(少し古いですが)StrutsSeasar などを作ったプログラマたちです。身近にいるプログラマの方々もそうです。そして、自分にも「少しでも恩を返せることがないか」と考えました。
 実際、これらのことを述べた名著は多くあります。地味な目線から、私なりに「より現場に近い」そして実践的なことを、「これ」で伝えられればと思います。