分かりやすいコード

業界動向

» 2010/11/25

　私は、恐ろしく物覚えが悪い。例えば、人の名前を覚えるのに苦労する。また、いったん覚えた人の名前も、数カ月会わないと忘れてしまっていることが多い。場所の名前なども同じだ。電話番号も、自分の家の電話番号さえいまだに覚えられない。現在、私の頭の中にある電話番号は、私が生まれた家、つまり今は両親が住んでいる家の電話番号だけだ。

　映画『博士の愛した数式』で、主人公の数学博士（映画では寺尾聰）は、記憶が80分しか持たないという設定だが、私も、それに近いかもと思ったりする。もしかしたら若年性アルツハイマーかと思うことさえある。しかし、この物覚えの悪さは若いころからなので、多分そうではないだろう。単に私の頭が、生まれつきそういう作りなのだと思っている。

　「覚えられない」という頭の構造は、たぶん他の職業の人にとっては大変なハンディキャップになるかもしれない。しかし、プログラマという職業では、それが逆に都合がいいのではないかと思う。

　「都合がいい」のである。つまり、物覚えが悪くとも仕事をやっていけると言っているのではなく、物覚えが悪い方がいいと言っているのだ。開発ツールの発展が著しい現在、その傾向はどんどん高まっている気がする。

　その辺りについて、私の考えを少し書いてみたい。

　物覚えが悪いプログラマが、プロジェクトで使っているフレームワークで用意されている、何かのクラスの何かのメソッドを使う必要があると気付いたとしよう。昔なら、そのクラスライブラリの書籍を探して、そこで詳細を調べて、コーディング再開となるところだろう。かなりの時間ロスになっていたのは確かだ。物覚えのよいプログラマなら、頭に入っているクラス名、メソッド名をそのまま一気に使ってコーディングを続けることができただろうからだ。

　ところが、最近の開発ではなんとなくうろ覚えでも、そのクラスの存在さえを覚えていれば、開発に使っているエディタが持つインテリセンスなどを使い、中断することなくコーディングを続けられる。そうでなくとも、検索エンジンを使って、一瞬にしてその情報を入手できる。クラス名が頭に入っていないということによるオーバーヘッドはほとんどない。

　さて、物覚えが悪いプログラマでも、さすがに前の日に書いたコードぐらいは覚えている。しかし、1週間前に自分が書いたコードのことはすべて忘れていることが多い。作成するプログラムの単位が小さいもので、1週間以内で終わるならそれもあまり問題にならない。しかし、かなりの大きさのコーディングで、まとまったコーディングが1～2週間続くようなものだと、物覚えの悪さは困ることになる。長いコーディング中に、前に書いた部分を完全に忘れてしまっているからだ。最初は、それで痛い目に合うだろう。忘れてしまった自分が書いたコードを、いちいちリバースエンジニアリングしながら、コーディングすることになるからだ。効率が悪いこと甚だしい。

　何度もそれで痛い目にあった後、そういう場合の対処法を自分で悟ることになる。なんのことはない。1週間後の自分が、自分のコードを読む際に一瞬にして分かるように、分かりやすいコードを書くように努力するということだ。さらに、その努力を積み重ねていくうちに、分かりやすいコードを書く技術も向上していく。

　人は評価してくれる人がいて初めて努力するものだ。いくら「読みやすいコードを書け」と偉い人の本に書かれていても、プロジェクトマネージャや顧客が要求しても、そのコードをリアルタイム、つまりプロジェクトの期間中に見る人がいない状況なら、努力する気持ちは忘れ去られていく。結果、数年先に行われるエンハンスのプロジェクトでまったく異なる人から構成されたチームが立ち上がり、そのプロジェクトに運悪く従事することになったデベロッパーが困ることになる。

　しかし、物忘れの極端に悪い私の場合は、自分のため、つまり1週間後の自分のために読みやすいコードを書くわけで、このための努力が廃れることは絶対にない。

　今の日本の開発現場はよく分からないが、他の人のコラムを読んでいると、まだまだコードの可読性に注意が払われることは少ないようだ。やはり日本の現場でのコードの質は「バグがない」ことが最大の評価基準で、それだけが評価基準のように見える。

　バグがないコードと可読性のあるコードは、単純に考えると相関がありそうに思える。「きれいに書かれたコードならバグがないだろう」と。しかし、現実にはそうはならない。というのは、きれいなコードはリファクタリングを繰り返すことによって達成されるのが普通だからだ。

　普通、きれいなコードでは、共通ロジックのコピーペーストは徹底して排除されている。ところが、リファクタリングの対象に、そういう完ぺきに動作している共通ロジックも容赦なく含まれる。共通ロジックは、それが重要なものであればあるほど、大量の他のコードに使われている。大量であるゆえ、修正を入れたからといってすべての呼び出し側コードからのテストを実行することは不可能だ。

　そういう問題があるから、修正を入れるときは、呼び出し側とのインターフェイスは変更せず、共通コードの内部の実装だけに変更を入れることになってはいる。しかし、現実問題として、インターフェイスの変更をどうしても入れたくなることもある。また、インフラ系の共通コードによくあるが、インターフェイスが変わらずとも、内部の処理が変わることによってタイミングが変わり、動作がおかしくなることもある。トランザクションとロックが絡むような共通処理は注意が必要だ。また、TDDのプラクティスを実施していれば、かなりのデグレを少ない工数で防ぐことができるが、もちろん100％完ぺきではない。

　そのため、日本の100％のバグフリーを要求される現場では、なかなか勇気を出して、リファクタリングを行えない。

　その点、シンガポールの開発では、プログラマレベルのバグは、頻度が異常に多くない限り、それほど問題にはならない。そのため、ためらいなくリファクタリングを進められる。また、テスト専門のスタッフがテストしてくれる体制が整っていることが普通のため、気が楽だ。

　テスト担当者が見つけてくれたバグをつぶす時、重宝するのが「コードのきれいさ」だ。チームの方針として、きれいなコードを書くことが徹底されている現場なら、他のデベロッパーの書いたコードも、比較的簡単に読むことができる。そのため、他のデベロッパーのコードのバグ対策も簡単だ。チームとして品質を高める努力をしていれば、バグフリーのレベルは「根性と超保守主義」で品質が維持されている日本の開発と、それほど変わらないのではないかと思う。