第8回

コーディング標準でコーディングスタイルを統一


縣俊貴
橋本正徳
Project Mobster/メディアファイブ株式会社

2003/8/7

 いよいよ本連載も最終回です。今回はチーム開発の最も基本的な部分、「コーディング標準」に触れていきます。また、いままでで書ききれなかった細かい点も、本稿の最後の方で補足します。

ペアプログラミングもコードの共同所有もここから始まる

 コーディングスタイルには人それぞれ癖や好みがあります。しかし私たちXPer(XP的な人)にとってはコーディングスタイルの癖や好みは邪魔なものになります。各自の好みのコーディングスタイルでコーディングをしているペアプログラミングを想像してください。または、各自の好みのコーディングスタイルでコードを共同所有しているチームを想像してください。コードはフォーマットがバラバラ、個人のコーディングスタイルに足を引っ張られて、コーディングが遅々として進まないことが容易に想像できます。そこでコーディング標準を取り入れて、クラス名やメソッド名の命名規則や、中カッコや改行位置などを決めることが大切になってきます。そして、そのコーディング標準を全員で確認し、守って作業することで、ペアプログラミングなどで余計な混乱を避けることができます。

コーディング標準の再利用

 すでに良いコーディング標準がたくさん出回っていますので、それをカスタマイズして利用しましょう。オブジェクト倶楽部からコーディング標準のテンプレート「Javaコーディング標準 」がダウンロードできます。Wordのファイルになっていますので、カスタマイズして利用することができます。 また「頑健なJavaプログラムの書き方(Writing Robust Java Code)」にも理解・保守・拡張のしやすいコードを書くことを目的にした、コーディング標準の指針があります。

Eclipseのコード・フォーマット機能を使ってけんか知らず

 EclipseをIDEとして使用するチームでは、「コーディング標準」の一部にコード・フォーマット機能を使い、フォーマットをすべてEclipseに任せてしまうという手もあります。

Eclipseのコードのフォーマットルールを設定する(クリックすると拡大)
  1. [ウィンドウ] - [設定]
    設定画面が表示されます。

  2. [Java]を展開 - [コード・フォーマッタ]
    Javaコード・フォーマッタの設定ができます。

 ショートカット[Ctrl+Shift+F]で簡単にJavaコード・フォーマッタのルールに合わせてコードをフォーマットできます。Javaコード・フォーマッタのルールを決めるのに時間がかかるのも手間なので、できるだけデフォルトの状態で使うことをお勧めします。

{

  if (size < currentSize) {
    try {
      size = (long) inStream.available();
    } catch (IOException e) {
    }
  } else if (size == currentSize) {
    ++size;
  } else {
    --size;
  }

}
EclipseのデフォルトJavaコード・フォーマット

XPをドライブするためにはまだまだ必要なものがある!

 XPを快適にドライブするためにまだまだ必要なものがあります。いままでに書ききれなかったことを補足的に紹介します。

プリンタ内蔵のホワイトボード

 XP開発ではホワイトボードを多用して、ミーティングや設計会議をします。ホワイトボードはプリンタが内蔵されているタイプのものは、書かれた内容をそのまま残すことできます。もし、ホワイトボードにプリンタが内蔵されていなかったら、デジタルカメラでホワイトボードを撮影するのもお勧めです。プリンタ内蔵と同様に書かれた内容をそのまま残すことができますし、電子媒体として残るのでとても便利です。

使えないフェルトペンはポイしなさい!
 ホワイトボードのそばにはゴミ箱を置いておくことをお勧めします。使えないフェルトペンを即捨てるために必要になります。使えないフェルトペンはミーティングの集中力や、テンションを下げます。最初に手に取ったフェルトペンが使えないときに、テンションは50%ほど下がります。最初のフェルトペンに愛想を尽かして、次に手に取ったフェルトペンがまた使えなかったときのテンションは残りわずか20%ほどです。すごい名案も半分忘れてしまいます。これではいいミーティングができそうにありませんね。ホワイトボードには使えるフェルトペンしか置かないようにしましょう。そして、使えないフェルトペンはきちんと捨てましょう。

B6サイズのカード

 プロジェクトの管理ツールとして、XPではカードが大活躍します。物理的なメディアであるカードは、どのような便利なソフトよりも、扱いやすくアジャイルなツールなのです。ストーリー、タスクの管理、設計のツールやメモとしてカードをうまく活用しましょう。カードのメリットとしては次のような点があります。

    だれでも簡単に扱える

    物理的に移動可能

    常に最新の状態で表示してくれる

    目に付く場所に貼り付けることができる

    破り捨てることができる

    すぐに書き始めることができる

 カードは厚めのB6サイズぐらいのものがお勧めです。薄すぎると、よれよれになってハードに使えないことも多いです。ぜひ「気合いが入った」厚いカードを選択しましょう。私たちがよく使っているのは次のカードです。

    コクヨ 情報カードシステム シカ-10W(無地) 100枚入り

 壁の「未完了」部分に貼られたタスクカードをはがして、ペアでコーディングに臨む、完了したタスクカードを「完了」の壁に貼り付ける、このような「カードの物理的な移動を伴う達成感」は、プロジェクト管理ツールやエクセルシートでは味わえない、楽しさと手軽さがありますので、モチベーションの向上にもつながります。

Wiki

 プロジェクト内での情報共有にはWikiを使用することがあります。Wikiとはプロジェクトメンバーが自由にページの内容を編集することができ、メンバー同士の情報の共有を手伝うWebベースのツールです。調査結果や仕様のメモなどを書き込み、プロジェクトのみんなで参照します。Wikiのメリットとして次のような点があります。

    仕様書などの印刷物が机の上に散乱しない

    バージョン違いの仕様書が存在しない(Wiki上が常に最新情報)

    検索できる(検索機能の付いたWikiの場合のみ)

 フリーのWikiを紹介します。(カッコ内は実装言語)

それでもドキュメントを殺したいか?
 XP開発はドキュメントを作らないイメージがあると思います。それは大きな間違いで、実はXPではドキュメントをすごく大事にしています。

 例えば、テストコードなどをクラス設計書として扱う姿勢や、ホワイトボードの記録を取る姿勢、タスクカードなどです。つまり「死んだドキュメントはいらない」という姿勢が大切なのです。スプレッドシートなどで作成した、素早く修正できない、大量で誰も読まない、生かすことのできないドキュメントは、苦労した割には更新を怠るとすぐに死んだドキュメントになります。これではドキュメントが浮かばれません。ドキュメントの性質を見極め、残すためのドキュメントと、一時的に必要なドキュメントを区別しましょう。

 ドキュメントを大事にしよう! ドキュメントは使い込もう! 死んだドキュメントは作らないようにしよう!

今日は仕事を切り上げて飲み会へ行こう!

 本連載の最後までお付き合いしてくださいました読者の皆さま、大変ありがとうございました。本連載はXP開発をツールの視点から見た内容でした。XPを初めて聞いたという読者には、ちょっとだけXPに対する好奇心に火を付けることができたのではないか? と思っています。また、実際にご紹介してきたツールを使って、雰囲気を少しつかんだ方からの連絡もよく届きます。

 私たちはXP開発の思想は「物を作る」という行為で、ごく当たり前のことだと考えています。別に「XP、XP」と騒ぐほどのものではなく、昔から普通に行われてきた手法の集大成です。しかし、その「当たり前」が「当たり前」として実践されていない状況が、さまざまな現場で見受けられます。だから「XP」という旗を高々と掲げて、あえて大きな声で「XP、XP、デスマーチ防止にXPはいかがっすかー」と叫んでいるのです。「下手をすれば顧客の多額のお金や、人命を奪う仕事をしているのだ」という緊張感があれば、XP開発の本質が分かるかもしれません。

 さて、この記事を読んだ今日、チームのみんなを誘って飲みに行きませんか? そこで次の話題をさかなにして盛り上がってみましょう!

    何か困ったことはないか?

    仕事は楽しいか?

    テストは面白いか?

    ドキュメントは役に立っているか?

    ペアプログラミングについてどう思うか?

    幸せになりたいか?

XPエクストリーム・プログラミングシリーズの紹介

 本連載を読んでXP開発に興味を持った方はXP開発の入り口に立ったところだと思います。さらにXPをドライブするためにピアソン・エデュケーションから出版されている「XPエクストリーム・プログラミングシリーズ」を会社の書籍棚にそろえてみてはいかがでしょうか? きっと、未来に会社を背負って立つ社員が手を伸ばすことでしょう。


プロフィール
縣俊貴(あがた としたか)
 メディアファイブ株式会社所属。XML,フレームワークを中心に開発業務に携わる。Javaのコミュニティー団体であるMobsterを主催。現在MonsterにてJavaベースのWikiシステム「MobWiki」を開発している。

橋本正徳(はしもと まさのり)
 メディアファイブ株式会社所属。XML、フレームワーク等の開発業務に携わる。Javaのコミュニティー団体である「Mobster」を縣と共に発起、運営。現在mobsterにてバグトラッキングシステム「mobbug」等を開発している。「日本XPユーザーグループ関西支部 九州分科会」にも参加。ちなみにこの記事自身もCVSでバージョン管理し、縣と橋本とで共同所有されて書かれている。

Project Mobster(ぷろじぇくと もぶすたー)
福岡県福岡市を中心にJava言語を研究追求し、その成果物をWeb上に公開していく団体です。年齢・スキル・会社などを超えてボーダーレスに活動しております。

IT Architect 連載記事一覧

この記事に対するご意見をお寄せください managemail@atmarkit.co.jp

「ITmedia マーケティング」新着記事

CMOはつらいよ マッキンゼー調査で浮かび上がるAI時代の厳しめな業務実態
生成AI、研究開発、価格戦略……。慢性的なリソース不足の中でマーケターの業務範囲はま...

「リンクレピュテーション」とは? SEO対策や注意点もわかりやすく解説
「リンクレピュテーションって何のこと?」「なぜ重要?」「リンクレピュテーションを意...

MAツール「MoEngage」 DearOneが日本語版UI提供へ
NTTドコモの子会社であるDearOneは、AI搭載のMAツール「MoEngage」の日本語版を2025年1月...