![](nagilerm_s.gif) |
複数の開発者で作業を行う以上、最低限のルールは必要だ。それをまとめたのがこの標準化だな。
|
|
|
![](tmtaki_s.gif) |
標準化というとガチガチなイメージがしますね。
|
|
|
![](nagilerm_s.gif) |
そうだな。だが、Development Baselineではあくまで必要最低限なものを決めるという考え方があるのでガチガチではない。ここでは、コードの標準化と品質の標準化について説明しよう。
|
|
|
![](tmtaki_s.gif) |
はい。
|
|
|
![](nagilerm_s.gif) |
コードの標準化は、だいたい想像がつくと思うが、コーディング規約に従ってプログラミングを行うことが第一だ。偉大な先人によってまとめられたVisual BasicとC#のコーディング規約(のドキュメント)を次のURLから参照することができる。
これらは、.NET Framework 1.0の時代に作成されたものだが、現在最新の.NET Framework 2.0による開発でも十分に使える内容のものだ。
|
|
|
![](tmtaki_s.gif) |
こうやって情報を公開してくれる偉大な先人がいるとありがたいですね。
|
|
|
![](nagilerm_s.gif) |
そうだな。感謝の気持ちは常に忘れないように。
それと、コードがコーディング規約に従っているかどうか検証を行う“FxCop”という無償のツールもある。これは、Visual Studio Team Systemの各エディションに標準で搭載されている機能でもある。下記URLよりダウンロードすれば、通常のVisual Studioから単体で使うことも可能だ。
また、FxCopは常時結合のツールである“CruiseControl.NET”とも連携することが可能だ。CruiseControl.NETのFxCopレポートの画面は次のようになる。
![](nagile06_04_s.gif) |
CruiseControl.NETのFxCopレポート |
FxCopによりコーディング規約に従っているか検証された結果が、CruiseControl.NETのWebユーザー・インターフェイスから確認することができる。 |
|
|
|
![](tmtaki_s.gif) |
なるほど、いっぱい警告メッセージが出力されてますね。
|
|
|
![](nagilerm_s.gif) |
ただし、FxCopの使用は必須ではない。
|
|
|
![](tmtaki_s.gif) |
えっ?! なぜFxCopは必須ではないのですか?
|
|
|
![](nagilerm_s.gif) |
FxCopが標準で使用するコーディング規約は.NET Frameworkのクラス・ライブラリの標準に従ったものであり、かなり厳密だ。先ほどの画面を見て分かるように、普通にコードを書いただけでもかなりの警告メッセージが表示される。なので、プロジェクトに応じてこのルールは使う/使わないという設定を行う必要がある。
しかしながら、FxCopのコーディング規約をカスタマイズするには、専用のアセンブリを開発する必要があり、かなりの工数を要する。もし、社内で使用する共通の開発標準のコーディング規約の検証ツールとしてFxCopを利用し、カスタマイズのための予算を積んでいるのならともかく、1つの開発プロジェクトでFxCopのコーディング規約のカスタマイズを行うことは現実的ではない。だから必須ではないのだ。
|
|
|
![](tmtaki_s.gif) |
なるほど、コーディング規約を検証するために、工数を取られすぎても本末転倒ですものね。
|
|
|
![](nagilerm_s.gif) |
そういうことだ。また、コーディング規約を守るだけで、標準化の本来の目的であるソフトウェアの品質を一定のレベルに保つことを達成できるわけではない。品質の標準化も同時に取り組むことが重要だ。
|
|
|
![](tmtaki_s.gif) |
品質の標準化ですか?
|
|
|
![](nagilerm_s.gif) |
そうだ。コーディング規約に従っただけのプログラムは、あくまで書き方のお作法が正しいだけで、それが美しいコードになるわけでも、十分なパフォーマンスが得られるわけでもない。当然ながら、不適切なアーキテクチャの基で作成したコードは満足なパフォーマンスが得られないだろうし、システムの中の1つのモジュールの品質が悪いだけでシステム全体として満足なパフォーマンスが得られないということだってある。つまり、品質の標準化は1人の努力や規約だけでは駄目で、チーム全員の協力と努力が必要ということだな。
|
|
|
![](tmtaki_s.gif) |
なるほど。では、どうすれば品質の標準化を行うことができるのですか?
|
|
|
![](nagilerm_s.gif) |
1つの答えとしては、コード・レビューとリファクタリングだな。作成したコードを1日1回でもよいので、ほかの人にレビューしてもらうこと、そして汚いコードはリファクタリングし、奇麗なコードに書き換えること。
また、可能であればペア・プログラミング(=2人組でコーディングを行うアジャイルの手法。以下ペア・プロ)を行うことで、常に第3者の目を意識しながらプログラミングを行うことができ、独りよがりのコードの記述ができなくなる。知識の共有という意味でもペア・プロは有効だ。
|
|
|
![](tmtaki_s.gif) |
でも、ペア・プロというと、なかなか上司の理解が得られないものですよね。
|
|
|
![](nagilerm_s.gif) |
気にすることではない。広い意味でいうと、実際の現場では普通にやっていることだ。
|
|
|
![](tmtaki_s.gif) |
え? ペア・プロをですか?
|
|
|
![](nagilerm_s.gif) |
そうだ。滝も分からないことがあれば、そのことについて詳しい人に教えを請うだろう? また、自分のプログラミングに問題があればほかの人に見てもらいながら開発するだろう?
|
|
|
![](tmtaki_s.gif) |
確かに、それならよくやってます。
|
|
|
![](nagilerm_s.gif) |
ペア・プロというと「1日中、2人でがっつりプログラミング!!」と思いがちだが、そうでなくてもよいのだ。分からないことがあれば周りに質問し、問題を抱えて悩んでいる人がいればちょっとの時間でも一緒に考えてあげる。大切なのはチーム内のコミュニケーション、決して時間の長さではない。チーム内のコミュニケーションを活発にすることで、品質を一定のレベルに保つことができる。さらに定期的に勉強会などを開催することで技術の底上げを行うことができる。それら複数の要素が組み合わさって初めて、品質を向上させることができるのだ。ペア・プロと聞いて肩ひじを張る必要はないので、まずは自分にできることからやってみるとよい。
|
|
|
![](tmtaki_s.gif) |
それなら私にもできそうです。ちょっと勇気がわいてきました。
|
|
|
![](nagilerm_s.gif) |
それと、メトリクス・ツール(=品質を測定するツール)についても紹介しておこう。“NDepend”というツールで、無償ではないが、トライアル版も提供されているので試してみるとよいだろう。商用利用のプロジェクトでも2週間は無料で試せるので、試してみて損はないツールだ。
また、NDependもCruiseControl.NETと連動させることができる。分析結果のレポートは次のようになる。
![](nagile06_05_s.gif)
|
NDependのレポート |
分析結果をアセンブリの依存関係などさまざまな観点からレポートとして出力する。 |
|
|
|
![](tmtaki_s.gif) |
おおお!! なんかいろんなレポートが見れますね。面白〜い。
|
|
|
![](nagilerm_s.gif) |
NDependは確かに面白い。が、メトリクス・ツールを導入するだけで品質を確保できるわけではないということを忘れるでないぞ。
|
|
|
![](tmtaki_s.gif) |
というと?
|
|
|
![](nagilerm_s.gif) |
メトリクスはあくまで品質を計測するための指標にすぎん。つまりは中学や高校での期末試験のようなものだ。
|
|
|
![](tmtaki_s.gif) |
期末試験?
|
|
|
![](nagilerm_s.gif) |
そうだ。品質を向上させる取り組みを常に行っていなくては、メトリクス・ツールを導入する意味がないということだ。ここでいう品質を向上させる取り組みとは、コード・レビューやパフォーマンス測定などを行い、コードの問題点をリファクタリングし、コードの品質を改善するということだ。それらの取り組みを行ったうえでメトリクス・ツールを使えば、継続的に品質を向上させることができるのだ。品質を向上させる取り組みを行っていなければ、日ごろ勉強をしていないのに期末試験だけ何度も受けているようなものだ。試験を受けるだけで学力が向上するわけがなかろう。大切なのは日々の積み重ねだ。
|
|
|
![](tmtaki_s.gif) |
そういわれると確かにそうですね。
|
|
|