このビデオでは Pharo の
コードの品質をチェックするアシスタントを
お見せします。
クオリティアシスタントあるいは コードクリティクスと呼ばれるものです。
コード上に良いプラクティスのルールを 走らせます。
より詳細に見ていきましょう。
クラスをブラウズするたびに
ポップアップが表示されるのを 見たと思います。
実際に起こっていることは
ブラウズしている間 自動的に
（CubHelix を選んでみましょう）
この小さな領域に
表示されています。 そしてパッケージの場合にも。
説得力のある例を見つけるのは
少し難しいのですが 例題のコードを使って
汚いコードをその中に書いくと 表示されます。
Counter に行って
例えばデバッグ用のコードを残すと
システムはここで自動的に 2 つのことを 伝えてきます。
デバッグ用のコードが
メソッドに残されていると言っています。 どうしましょうか？
このルールがどうして出てきたかはわかります。
クリックすると
ブレークポイントを使うように言ってきます。 プロダクションコードではあまり賢いやり方ではありません。
自動的に解決できると言っています。
では試してみましょう。
これを消すように言ってきます。
はい、これで良いです。
そしてその結果 もう問題はありません。
プログラミングしている時に
こうしているのを今までも見てきました。 システムが反応してくれます。
さて、もう 1 つのやり方があります。
対象のパッケージを クリティックブラウザで開きます。
今回はとても小さなパッケージです。
間違えてみて、どうなるか見てみましょう。
ここで self halt とするか
あるいは別のメソッドで
increment3 メソッドを作って
存在しないメソッドを使ってみます。
foofoo としましょう。
さて、ここで赤なわけですが
頭が熱でぼーっとしたりして 気付かなかったことにしましょう。
コードをクリティックブラウザで開くと
クリティックブラウザは
一連のルールを表示します。
実際、沢山のルールが
説明付きで示されています。 もしこのコードがあったら
こうしたほうが良い
もし内部でアロケーションがあれば。
ルールには数種類あります。
最適化に関係したルールや
潜在的なバグを特定するためのルールや
バグを特定するルールがあります。
ここへ行くと、コードを見ることができます。
元の定義を見ることや
変換することができます。
そして警告が消えます。
ここで大切なことは
全てのルールは経験則だということです。
つまり、意図的にあまり良くないことを することもあります。
システム中でわかった上で
そうせざるを得ないこともあります。
これは偽陽性（実際には問題ではない指摘） だと指定することもできます。
ここに foofoo メッセージがありますが
わかった上でそのままにしたいとします。
すると、このルールはこのメソッドには 正しくないと指定することができます。
そう指定します。
ここでグレーになりました。
これは後になって
このルールの言う通りかもしれないということで
後でまた見たほうがいい
ということです。
指摘を保存しておくことができます。
つまりルールの結果や
偽陽性といったものを保存します。
もし偽陽性になるようなものを書いた時
ルールを走らせるたびに何度も何度も
ずっとシステムが繰り返し 指摘してほしくはありません。
指摘を保存すると、クリティックブラウザは それらの指摘をマニフェストに入れます。
見てみましょう。ここにマニフェストがあります。
システムに関連つけられ バージョンが付けられています。
内部的にどうなっているかを 見る必要はありません。
マニフェストは色々なことをコード化しますが それはどうでもよいです。
マニフェストに触らないでください。 コードクリティクスが次回実行される時に
使われるものです。
そしてマニフェストはパッケージごとにあります。
コードにバージョンをつけると
マニフェストにもバージョンをつけます。
そしてコードクリティクスを再び走らせると
自動的に偽陽性やメタコメントが
取り入れられます。
これらの品質ルールについて 本当に大切なことは
Pharo はそれらのルールを 開発プロセスに統合しているという点です。
プロジェクトを
コミットするたびに
Jenkins サーバーがそれをロードして
それらの品質コードを自動的にチェックして
プログラムが本当に品質ルールに 従っているかを確認します。