あなたも見たことがある光景かもしれませんが、新しいプロジェクトが立ち上がる時というのは、みんな「抱負」を持つものです。ああも使用、こうもしよう、と希望に燃えるのです。そういう抱負は、多くの場合ドキュメントにまとめられます。たとえば「このプロジェクトでは、一定の規約に従ってコーディングをする」ということが決定され、その規約がドキュメントにまとめられたりするのです。キックオフミーティングでは、プロジェクトリーダーがドキュメントの内容を承認し、プロジェクトのメンバーの多く、時には全員が、その規約を守ることに賛成します。しかし、いざプロジェクトが開始されると、こうした最初の抱負は徐々に顧みられなくなっていきます。そしてプロジェクト完了時には、規約など全く無視された無秩序なコードが、なぜそうなったのか誰にも理由がわからないまま、納品されてしまいます。
一体、どこでおかしくなってしまうのでしょうか。おそらく、すでにキックオフミーティングの時点でおかしくなっていたのだと思います。プロジェクトチームの中に、実はコーディング規約に無関心な人や、なぜ規約が必要なのかを理解していない人がいたのでしょう。もっとひどい場合には、内心全く規約に賛同しておらず、はじめから守らずに作業をするつもりでいた人もいるかもしれません。規約には賛成で必要な理由もわかっていたけれど、納期に間に合わせなくては、というプレッシャーに負けて、守ることをあきらめた、という人もいたでしょう。規約に従い「美しい」コードが書けても、高機能を求める顧客の歓心を買うことはできません。それに、一定の規約に従ってコードを書くというのは、自動化をしない限り、かなり面倒なことです。クラスのインデントを整え、見やすく混乱しにくくするというだけでも、手作業でやろうとすれば意外に大変なことは、自分のでやってみればすぐに分かります。
では、そういう問題がありながら、そもそもなぜ、コーディングに規約を設けようなどと思うのか。その目的の1つは「誰も、自分の書いたコードを「私物化」できないようにする」ということです。みんなが、自分の担当部分のコードを好き勝手な形式で書くと、どうしてもその箇所はその人のコードになってしまいます。逆に、その箇所も均一な形式で書いてあれば、私物化という事態にはなりにくいでしょう。その他、開発者がアンチパターンを使ってしまうことでしょう実、ありがちなバグを防ぐという目的もあります。コーディング規約に従うことで、プロジェクトの全体としての進行を円滑にし、開発速度を一定に保ちやすくします。ただし重要なのは、プロジェクトに参加する全員が同じ規約に従わなくてはならないということです。―他の開発者が皆4タブのインデントを使用しているのに、1人だけ3タブのインデントを使ったのでは意味がありません。
コーディング規約の遵守に役立つツールは多数存在します。そうしたツールには、規約をドキュメント化する機能、規約からの逸脱を報告する機能などがあります。ただし、そういうツールを使えば問題が全て解決するわけではありません。コーディング規約は可能な限り、自動的、かつ強制的に守られるようにすべきでしょう。具体的には次のような方法が有効です。
- コードの整形処理をビルドプロセスに含めてしまう。コードのコンパイルをする度に、誰もが必ず、自動的に整形することになる。
- 静的なコード解析ツールを使用してコードを解析し、望ましくないアンチパターンがないかを探す。もし見つかれば、ビルドを中止する。
- ツールの設定により、プロジェクト固有のアンチパターンも見つけ出せるようにする。
- テストカバレッジをただ計測するだけで終わらせるのではなく、計測結果の判定も自動的に行われるようにする。そしてテストカバレッジが低すぎる場合は、ビルドを中止する。
以上のことを、重要なプロジェクトでは必ず実践するようにするのです。ただし、守るべき規約が全て自動的に守られるような仕組みを作ることはほぼ不可能でしょう。警告や修正を自動化出来ないルールがある場合は、自動化の仕組みに加えて、ガイドラインの準備が重要になってきます。とはいえこの場合は、自分を含めチームのメンバーたちが、おそらく規約を忠実には守らないだろうと考えておくべきでしょう。
もう1つ大切なのは、コーディング規約は固定的ではなく、変化していくべき、ということです。プロジェクトが進行していけば、そのプロジェクトで求められるものも変わってきます。はじめのうちは懸命と思えたことが数カ月後にはそうでなくなっている、ということもあるのです。