あなたはきれいなコードが書けますか？ 　 チームを幸せにするコーディング手法教えます

　プログラマの会話や文章には、“きれいなコード”という言葉が頻繁に出てくる。きれいなコードが書けるプログラマは尊敬の対象である。“上手な文章”と同じく明確な法則があるわけではないが、きれいなコードとは、無駄な構造がなく、体裁が整っていて誰が読んでも分かりやすいことだろう。きれいなコードはシンプルで高速だ。

　プログラマ必読の入門書といわれる『珠玉のプログラミング』（ジョン・ベントリー著）や『プログラミング作法』（ブライアン・W・カーニハン著）などを読むと、きれいなコードを書くには「アルゴリズム」「データ構造の選択」のセンスを磨き、「基本作法」を身に付けることが重要だと分かる。これは時代や開発言語を問わず、普遍的な真理である。

　問題解決の手順を示したアルゴリズムは、プログラムの根幹になる。優れたアルゴリズムが必ずしも分かりやすいとは限らないが、そのデザインパターンを引き出しに多く持っていれば、より明快なコードを記述できる場面は少なくない。また、先入れ後出しの「スタック」や先入れ先出しの「キュー」など、基本的なデータ構造の特徴を理解し、それを適切に選択すると、寄り道をせず最短で目的を達成するコードが書ける。

　複数のプログラムやエンジニアがかかわるプロジェクトの中でコードを書く以上、基本作法も重要だろう。基本作法とは、「分かりやすい変数名や関数名を付ける」「プロシージャは制御順に記述する」「インデントのあるなしを統一する」などのことである。基本作法にのっとったコードは体裁が整い、コードレビューもしやすい。

　このような基本に徹しても、文章の推敲のように作業中にプログラム全体の構造を見直す作業が重要になる。無駄な構造はないか、プロシージャにまとめられる部分がないかと検証してみる。文章の世界では、細部に注意しながらも常に全体像を見渡し、構成や文章を調整していくことを「虫の目と鳥の目」という。コーディング作業にも同じことがいえ、虫の目と鳥の目で見直しを重ねたコードはよりきれいになるはずだ。

　Javaによるオブジェクト指向開発では、特に「虫の目と鳥の目」が重要になる。抽象的な「クラス」の階層化、継承化をベースに分析・設計・実装を繰り返すからだ。クラス同士の複雑な関係性をコードだけで理解、検証するのは難しく、プログラマもコーディング中に頭の中が混乱することはよくあるだろう。

　Javaによるオブジェクト指向開発できれいなコードを記述するには、コード指向で開発しながらも途中途中でコードをモデル図に置き換え、設計を見直す習慣と能力が求められる。モデル図を見渡すことで、次のような効果が期待できる。

• クラス同士の関係性を一目瞭然に判別できる
  
• 重複した無駄なコードを容易に洗い出せる
  
• クラス同士の依存性を最小化し、プログラムの複雑さを抑える
  
• 複雑な状態遷移（ステート）も視覚的に把握できる
  
• モデル図を介して開発者同士の情報共有が図れる

　モデリングとの連携は、コーディング作業に大きな効果をもたらす。そのため「ラウンドトリップ」「リファクタリング」などの開発技法も注目されている。2つとも結局は、モデル図を活用してコードを洗練させていく技法である。Javaできれいなコードを記述するには、モデリングが不可欠な要素となってきたのである。

　コーディングとモデリングをそれぞれ手作業で行うのは、単に工数を増大させるだけであまりにも非効率的だ。両者を効率的に連携させるには、高機能な開発ツールが不可欠である。最近では、JavaのIDE（統合開発環境）製品の多くが、モデリングの標準表記法であるUML（Unified Modeling Language）との連携機能を備え、ソースコードとモデル図の相互変換が可能となっている。

　しかし現実には、モデリング連携機能を備えた開発ツールを活用しているプログラマはどれほどいるだろうか。「モデリングは自分の作業とは関係ない」と考えているコード指向の強いプログラマも少なくない。また、個人的には重要性を理解していながらも、開発ツールが高価でプロジェクトでは使わせてもらえない、理想的な開発ツールがないなど、さまざまな理由が考えられる。

　結局のところ、モデリング連携機能を備えた開発ツールを活用するのは「設計が上流でコーディングは下流」と、工程（役割）が明確に分かれ、EJBやJ2EEを利用するような大規模システム開発の場合と考えられてきた。開発ツールの機能もそうした分業体制を前提とした製品が多い。そこではコーディングとモデリングの連携といっても工程間の連携であり、プログラマは設計側の変更をソースコードへ自動で反映させるために開発ツールを使う。受動的な利用である。

　だが実際には、Java開発者の多くは比較的小規模なWebアプリケーションやWebサービスの開発チームに携わっている。そこでは設計とコーディングの工程が並列で行われ、1人のプログラマが設計、コーディングの両方を受け持つことはよくあることだ。そうした開発チームで採用する開発ツールには、プログラマが主体的にコーディングとモデリングの相互変換を繰り返し、コード側からプログラムを洗練させていく作業を支援する機能が求められる。

　プログラマ主体でコーディングとモデリングの相互変換を利用するには、リアルタイム性が不可欠である。プログラマがコーディング中にソースコードの構造をモデル図で検証したい思ったとき、即座にモデル図を生成できなければ意味がないからだ。

　ボーランドが4月に発売した「Together Edition for JBuilder X Developer」（以下、Together）は、そうしたリアルタイム連携を実現する開発ツールだ。Togetherは、Java IDEとして定評のある「Borland JBuilder X（テン）」（以下JBuilder X）にUMLモデリングツール「Borland Together」の機能を統合するためのプラグイン製品だ。Togetherが持つ「LiveSource」技術により、ソースコードとモデル図のリアルタイムな相互変換が可能になり、コード指向とモデル指向を融合させた開発が実現する。ここが一般的なJava IDEと大きく違う点である。

　さらに、ビジュアル開発機能を持つJBuilder XにTogetherを統合することにより、

• コード
  
• ビジュアル開発
  
• モデル図

の3ウェイで“リアルタイム連携”を実現できる。

画面1　コード、ビジュアル開発、モデル図がリアルタイムシンクロ（画像をクリックすると拡大表示します）

　Togetherには、設計を改善するリファクタリング、デザインパターン、検査／測定の機能が網羅されている。広範囲に及ぶリファクタリングによって変更された設計は、ソースコードへ自動で反映できる。業界標準のGoF（Gang of Four）などのデザインパターンを活用すれば、モデル図にデザインパターンを適用した後にソースコードを生成し、コーディング作業の軽減することも可能である。

画面2　リファクタリングやデザインパターンを用いてよりよい設計に変更（画像をクリックすると拡大表示します）

　また、検査・測定機能「Audits & Metrics」は、人の眼では発見しにくい設計上の問題点を発見してくれる。さらに開発者にとって厄介なドキュメント作成も、モデル図を基にテンプレートを使って作成できる。ドローイングソフトを使ってドキュメントを作成するのに比べて、開発者の業務負担は大幅に軽くなるはずだ。

画面3　最新の図から直ちにドキュメントを生成（画像をクリックすると拡大表示します）

画面4　テンプレートを使用することで作業負担を大幅軽減（画像をクリックすると拡大表示します）

　Togetherの大きな特徴は、これまでの常識を破る価格にもある。2004年9月15日までのキャンペーン価格として、JBuilder Xユーザーに対して標準価格6万8000円で提供される（JBuilder XとTogetherのバンドル版は同9万8000円）。これまでモデリング連携機能を持つJavaのIDEは高額で、予算の大きい大規模プロジェクト以外は導入しにくかったが、Togetherならば小規模な開発チームでも導入しやすい。

　Java開発が一般化してきた現在、プロジェクトの予算は抑えられ、納期も厳しくなる傾向にある。こうした条件下でプロジェクトを成功に導くには、開発チームを少数精鋭化して開発レベルを底上げするしかない。極論すれば、前提として個々のプログラマが“精鋭”であり、きれいなコードを記述できれば、チームマネジメントは苦労しない。

　個々のプログラムが無駄な構造がないきれいなコードであれば、最終的に統合したプログラムの品質も高まる。基本に徹したきれいなコードはバグが少なく、保守性が高い。当然、コードレビュー、デバッグなど後工程の作業を軽減する。「プロシージャを制御順に記述する」など基本作法を守ったコードは、ほかのメンバーでも直しやすい。きれいなコードは、チーム開発で品質と生産性を高める基本条件なのだ。

　プログラマがきれいなコードを記述するために開発ツールのモデリング連携機能を活用することは、同時にチームマネジメントのレベルも高める。チーム開発で重要なのはコミュニケーションの質である。無駄な打ち合わせを減らしつつも、迅速、的確に情報共有、共通理解を図る必要がある。そこではコードよりもモデル図を用いる方が効果的である。「100行のコードは1つのクラスにしかず」「10回の会議は1つのユースケース図にしかず」だろう。

　きれいなコードは、“職人的なこだわり”ととらえられることも多い。確かに、品質と共に速度が求められる開発で、過度にコードの構造や体裁にこだわる必要はない。多少は無駄な構造があったり、体裁が整っていなかったとしても、最終的なシステムの振る舞いにさほど影響はない。しかし、特にJavaが活用されるケースが多いWebシステムは、一度のカットオーバーでは終わらない。避けられない機能拡張や変更をいかに無駄なく行うかを考えると、コードの“きれいさ”がチーム全体を幸せにする理由がおのずと見えてくる。

チーム開発レベルを底上げする方法 トップページへ