コーディングスタンダードのススメ

James Polanco

今月号の記事

Web のフロントエンドの開発といえば、以前は、HTML ページに Flash や JavaScript を取り入れるといった、シンプルで分かりやすいデザイン手法でした。しかし、ここ数年の間に、Ajax / Flex / Adobe AIR といったより複雑でアプリケーションベースのデザイン手法へと進化しています。さらにその複雑さはデスクトップソフトウェア・デベロッパーたちに求められるレベルにまで達しています。しかし、フロントエンド開発が複雑化しているにも関わらず、未だ多くのフロントエンドデベロッパーたちは従来の古いスタイルで開発を行い、アプリケーションに「コーディングスタンダード」を取り入れようとしていません（あるいは、取り入れ方を知らないのかもしれません）。　

この記事では、コーディングスタンダードとは何か、そしてなぜコーディングスタンダードを取り入れるべきなのか、実例を交えながら解説します。この記事をきっかけに、みなさんのグループにおいて、より統一されたコーディング手法を確立することへの意識が高まるとうれしいです。本記事は、私が慣れ親しんでいる技術ということもあり、Flex を中心に話をしていますが、ここで解説するコーディングスタンダードは、他の手法によるアプリケーション開発にも当てはめることができます。

コーディングスタンダードとは？

コーディングスタンダードとは、デベロッパーがコードを一貫して書き続けることを手助けするガイドラインです。一貫したコードを書くということは、コードを書くデベロッパー自身の役に立つだけでなく、同じコードベースで共同作業をする他のデベロッパーの役にも立つのです。このガイドラインでは、コーディングプロセスにおける2つの基本事項が対象となります。

1つ目は、みなさんのコードの見た目に関すること、つまり「コーディング規約」です。コーディング規約とは、変数、メソッド、クラス、パッケージやコメントなどの名前の付け方、そしてファイル構造の構成などについて定義したものです。みなさんのコードが、デベロッパーの目にどのように映るのかを決めているといっていいでしょう。2つ目は、コードデザインパターンの採用と実装です。デザインパターンは、デベロッパーたちが共通して直面する問題に対する解決方法を抽象的にまとめたガイドです。代表的なデザインパターンとして、「Model-View-Controller（MVC）」があります。このデザインパターンとコーディング規約を取り入れることで、みなさんのコードにも一貫した経験や構造を作り出すことができます。会社やチームで、あるいはプロジェクト単位でコーディングスタンダードを設けていることがありますが、多くの場合、コーディング規約のみを重視しているようです。しかし、プロセス全体を標準化する上で、コードの書き方同様に、デザインパターンの採用と実装方法を考えることも重要なのです。

コーディングスタンダードを使うべき理由

コーディングスタンダードの説明をしたところで、次になぜコーディングスタンダードをプロジェクトに取り入れるべきなのかを説明します。コーディングスタンダードの有用性を説明する上で最も分かりやすい例は、Adobe Media Player のようなプロジェクトやオープンソースプロジェクトといった複数のデベロッパーが開発に携わるケースでしょう。

多くのデベロッパーたちがそれぞれ別々の名前の付け方やファイル構造でコーディングしており、そのコードを管理しなければならないというシチュエーションを想像してください。新しいメンバーがプロジェクトに参加した時、みなさんはどうやってコードを説明しますか？コードに変更を加えたり、新しいクラスを追加したい時、どのようにするのが一番いい方法なのでしょうか？他のメンバーが書いたコードのバグを修正しなければならない時、どのようにしますか？みんなが自由にコーディングしてもいいという環境で作成されたコードは、スパゲッティコードになりがちです。そうしたコードでは、行ごと、メソッドごと、クラスごとに構造が変わったりするので、内容を理解するのが非常に困難です。まったくもって予測できない内容のコードを理解して、管理やデバッグをしなければならないとなると、まさに悪夢です。

コーディングスタンダードが有用なのは、大きなプロジェクトだけではありません。個人のデベロッパーが手がける小さなプロジェクトでも、コーディングスタンダードは役に立ちます。デベロッパーなら誰しもあることですが、プロジェクトの進行中、数ヵ月前、あるいは数年前に自分で書いたコードを見直さなければならないことがよくあります。しかし、当時、時間が無くてコメントを残していなかったり、所定のコード構造に従わずにコーディングしていたりすると、昔のコードを見て何をしていてどのように実行されるのかを理解するのは面倒でつらい作業になってしまいます。

残念なことに、Flash のデベロッパーコミュニティの中では、ちょっとした一匹狼精神が存在します。特に、契約プロジェクトや代理店経由によるプロジェクトでは、その一匹狼精神が顕著に見受けられます。そうしたプロジェクトでは、非常識な締め切り設定で、みんな呪文のように「とりあず、仕上げよう」と呟いています。このような状況にいるデベロッパーたちから「コーディングスタンダードに沿って作業している時間がない」という言葉を何度も聞いたことがあります。さらに、「コードにコメントは入れないようにしている。そすうれば、何か問題があって修正が必要な時に、また仕事をもらえるじゃないか」と言う人もいました。驚くことに、この言葉を聞いたのは一度だけではありませんでした。

誰にも分からないようなコードを書くことで仕事を維持しようという考えは、複雑混乱な仕組みにしてセキュリティを確保しようという考えと同じくらい馬鹿げています。そうした仕事の考え方は、短期的に見れば通じるかもしれませんが、長期的な展望でみると、自分で自分の首を締めることになるでしょう。たとえ大規模なコードを必要とするプロジェクトの仕事を得たとしても、コーディングスタンダードに沿ったコーディングでなければ、どんなベテランが書いたコードだとしてもチームに不利益をもたらしかねません。他にも、コーディングを少しでも知っているクライアントであれば、いい加減なコードを見て、次のプロジェクトからそのデベロッパーを外してしまうこともあり得るでしょう。

リッチインターネットアプリケーション（RIA）時代に突入した今、バナー広告や1～6ヵ月間しか公開しないインタラクティブマーケティングコンテンツは話題の中心ではなくなりました。RIA は Web 上のソフトウェアで、定期的にアップデートや新バージョンの開発が必要となります。「使い捨てのコードでいい」という考えは見直すべきです。新しいバージョンをリリースするたびに、コード全体を書き直すのは、経済的ではありません。コーディングスタンダードを取り入れれば、クリーンでスケーラブルなコードを作成でき、それを何年もの間利用し続けることが可能となるのです。

コーディングスタンダードの例

コーディングスタンダードは、「すべてのデベロッパーに何から何まで同じ方法でコーディングをさせる」といった厳格なものでなくてもいいのです。まずは、コミュニティで公開されているオススメの例を見てみましょう。

アドビオープンソースにある記事「Flex SDK Coding Conventions and Best Practices*」を見てください。オープンソースプロジェクトでは誰もがコードベースを拡張してそれをフィードバックできます。そのため、コーディング規約や事例について解説しているこの記事は、オープンソースプロジェクトにおいて重要な役割を果たしています。記事は「明瞭なコード」に関する内容が中心となっています。略語の使用を避けること、丁寧にコメントすること、一定のパッケージ構造にすることなど。これらの規約に沿ってコーディングしておけば、参加者は既存のコードにシームレスにフィットするコードを投稿でき、他の参加者はそのコードがどのようなものかが理解できるのです。

コーディングスタンダードは、デベロッパーたちにとって理解しやすい、従いやすい内容であるべきです。少し練習が必要でも、すぐに身につくような簡単な例としては、コードにコメントを入れることです。長い文章を書く必要はありません。何をしているのかを、短い言葉で書くだけでもいいのです。以前、一緒に仕事をしたデベロッパーが、以下のようなコメント付きでプロトタイプを見せてくれました。


Public function parseData(data:Object):void
{
  // 引数を確認後、
  // dataオブジェクトに変換し、
  // リスナーに渡す
}

このようにコメント付きでプロトタイプを作れば、コードのフローや内容を示すことができます。そして、実際にコードを書く際に、必要に応じてコメントを変更したり追加したりすればいいのです。シンプルなコメントを追加するだけで、他のデベロッパーにも、そして自分自身が将来振り返る際にも、理解しやすいコードとなるのです。これは、コーディング規約の取り入れ方の基本的な例です。

では、コードデザインパターンは、コーディングスタンダードの中でどのような役割を担うのでしょうか？最近、私は「Flex code-behind pattern*」という記事を書きました。この記事で紹介しているパターンは、初期の Flex デベロッパーたちによって ASP.NET のモデルから導入されたものです。このパターンでは、レイアウトに MXML を使い、すべてのスクリプトロジックは MXML が拡張するクラス内に格納します。Flex 1 と 1.5 では、コンパイラが自動でクラスと MXML を混在してしまうというバグがあり、デベロッパーたちはそのバグを利用していました。しかし、 ActionScript 3.0 ではそうした混在をサポートしていません。同じような code-behind プロセスを使いますが、継承拡張機能として使用します。

以前私が手がけたプロジェクトでこの code-behind プロセスを採用して以来、既存のコードベースや将来のプロジェクトのコーディングスタンダードとなりました。この手のデザインパターンは、コード構造や読みやすさに関するものなので、簡単にコーディングスタンダードに採用することができます。Cairngorm、Dojo、Spry といったマイクロアーキテクチャやフレームワークを実装することもまた、コーディングスタンダードを採用するのと同じです。アプリケーションにマイクロアーキテクチャを導入すると、自動でそのデザインパターンに従うこととなり、デフォルトですべてのコードに一貫した構造を持たせることができます。

マイクロアーキテクチャを導入するメリットは、たとえば、新しいデベロッパーがプロジェクトに参加することとなった場合、そのアーキテクチャを経験していればコードの全体構造や開発プロセスに慣れ親しんでいるため、すばやくプロジェクトに取りかかり貢献してもらえる点です。

コーディングスタンダードを始めよう

この記事では、コーディングスタンダードのほんのさわりのみを紹介しましたが、コーディングスタンダードを使うメリットを少しでも感じてもらえたらうれしいです。コーディングスタンダードの開発がさらに進み、コミュニティで公開されるようになれば、プロセス開発やワークフローについてもっと考えられるようになるでしょう。

プロセスやワークフローのことを話し合いはじめると、コーディングスタンダードがデベロッパーだけでなく、チームや部署、あるいは会社というスケールから見ても重要な存在であることが分かると思います。コーディングスタンダードは、ワークフロープロセスの一要素ではありますが、チームやプロジェクトを容易に発展させることができます。

上記で紹介したコーディングスタンダードの例はシンプルな内容ですが、将来作成するスタンダードを考えるきっかけにしてもらえるとうれしいです。このスタンダードはあくまでもガイドラインであって、誰もが遵守しなければならないルールではありません。コードそのものの記述方法についてはお任せします。ただし、どのようにコーディングスタンダードを利用すれば、開発時間を短縮し、既存のプロジェクトや今後手がけていくプロジェクトをうまくまとめていけるかを考えるようにしましょう。

‹ 戻る