CodeCoachでは、クラス、メソッド、フィールド、ローカル変数、メモリーの使用方法など、様々な領域に関するアドバイスが提供されています。各領域内で、アドバイスされた変更内容が「アドバイス・タイプ」と呼ばれるより詳しいカテゴリに編成され、必要に応じて使用可または使用不可に設定できます。また、CodeCoachでコードを評価する深さを定義し、組み込むまたは除外するクラスやパッケージを指定できます。アドバイス・タイプ、CodeCoachの深さ、パッケージまたはクラスをIDEから直接評価するか、コマンドラインから評価するかを選択できます。また、プラグマを直接ソース自体に挿入すると、CodeCoachでのコードのテスト方法をより細かく設定できます。
CodeCoachで、可能なかぎり正確なデータを取得する(それによって、最大限正確なアドバイスが提供される)には、CodeCoachでのセッションの実行中にコードを完全に実行することが重要となります。UIのすべてのメニューとボタンを使用し、コーナー・ケースが含まれるようにしてください。アプリケーションの一部の機能を実行せず、完全なコード・カバレッジが保証されていない場合は、CodeCoachによって返されるアドバイスが、アプリケーションのパフォーマンスに影響を与えることがあります。
完全なコード・カバレッジが重要な理由は、次のとおりです。VM内のCodeCoachシステムでは、実際にロードされているクラスのみが考慮されます。また、Javaはロードが遅い言語であるため、クラスは実際に使用される場合にのみロードされ、参照時にはロードされません。クラスが参照されるだけで、使用されない場合、CodeCoachではその存在は認識されません。返されるアドバイスを有効にするには、プログラムで使用予定のすべてのクラスをロードする必要があります。
次のコード例を考えてみます。
class Greeting {
String title;
String name;
public Greeting() {
}
public Greeting(String title, String name) {
this.title = title;
this.name = name;
}
public String toString() {
return "Hello " + title + " " + name;
}
}
class DearGreeting extends Greeting {
public DearGreeting(String name) {
this.title = "Dear";
this.name = name;
}
}
public class Class1 extends Object {
static Object getGreeting(String name, boolean isfemale) {
if (name.equals("Joe")) {
return new DearGreeting(name);
}
if (isfemale) {
return new Greeting("Mrs", name);
}
else {
return new Greeting("Mr", name);
}
}
public Class1() {
}
public static void main(String[] args) {
System.out.println(getGreeting("Kiks", false));
}
}
この簡単なプログラムをCodeCoachで検証すると、次のアドバイスが返されます。
(CFIN) Class Greeting should be final
(CFIN) Class Class1 should be final
(FPRI) Field java.lang.String name should be private
(FPRI) Field java.lang.String title should be private
このアドバイスに従うと、コンパイルが中断されることになります。Greeting
は、DearGreeting
によって拡張されているため、finalにはしないでください。また、java.lang.String
の名前およびタイトルは、DearGreeting
がこのフィールドにアクセスする必要があるため、privateにはできません。
では、なぜCodeCoachでこのように不適切に思われるアドバイスが返されたのでしょうか。この理由は、メソッドgetGreeting
が呼び出されるのは1回のみで、その引数にKiksが使用されており、一方、DearGreeting
のインスタンスは、名前がJoeの場合にのみ返されるためです。このため、return new DearGreeting(name);
行は、このテスト時には実行されず、Javaではクラスが使用時に実際にロードされるまで待機するため、クラスDearGreeting
は、このテスト時にはロードされていません。クラスDearGreeting
が存在しない場合(CodeCoachで存在していないことを認識している場合)、返されるアドバイスは正しいものとなります。
一方、メソッドgetGreeting
が引数にJoeを指定して任意の場所でコールされる場合、またはプログラムの他の場所でDearGreeting
クラスのインスタンスが使用される場合、CodeCoachシステムでは次のアドバイスが返されます。
(CFIN) Class DearGreeting should be final
(CFIN) Class Class1 should be final
これは非常に簡単な例であり、実際のプログラムでの関係は、より複雑になります。そのため、特にロードされるクラスに対してこの依存性に注意してください。プログラムで使用予定のすべてのクラスがCodeCoachの実行時にロードされることが理想的です。この理想に近づくと、アドバイスはより正確になります。
常に理想的な状態にはできないため、最初に評価せずにCodeCoachのアドバイスに従うと、プログラムのコンパイルが中断される場合があることに注意してください。中断された場合、修正を元に戻し、不適切なアドバイスを無視するプラグマを使用します。
コードがより完全になると、CodeCoachのアドバイスもより正確になります。一方、プログラムを完全なものにするか、完全なものに近づけるまでCodeCoachを実行しないと、CodeCoachから返されるメッセージは大量になります。
最善の方法は、CodeCoachをプログラム開発の最初から使用することです。こうすることで、操作中にアドバイスを考慮に入れて、目的に応じて、使用可および使用不可に設定するアドバイス・タイプを指定できます。ただし、CodeCoachの使用段階が初期であるほど、CodeCoachでアクセスできない全体的な設計を考える必要があります。たとえば、CodeCoachでメソッドstaticを宣言することがアドバイスされているが、最終的にそのメソッドをサブクラスでオーバーロードすることがわかっている場合、このアドバイスは無視します。必要に応じて、プラグマまたはログ・ウィンドウのポップアップ・メニューを使用して、使用不可に設定することもできます。CodeCoachでは認識されるもののみが検証されるため、必要に応じて修正する必要があります。
上手に利用すれば、CodeCoachは便利で時間の節約になります。ただし、アドバイスに従う前に、全体像を考え、予期しない結果にならないようにする必要があります。
Copyright © 1997, 2006, Oracle. All rights reserved.