1
00:00:01,260 --> 00:00:03,390
このビデオでは Pharo の

2
00:00:03,557 --> 00:00:06,040
コードの品質をチェックするアシスタントを

3
00:00:06,207 --> 00:00:08,640
お見せします。

4
00:00:08,807 --> 00:00:11,450
クオリティアシスタントあるいは
コードクリティクスと呼ばれるものです。

5
00:00:11,617 --> 00:00:14,770
コード上に良いプラクティスのルールを
走らせます。

6
00:00:15,710 --> 00:00:17,040
より詳細に見ていきましょう。

7
00:00:17,300 --> 00:00:19,220
クラスをブラウズするたびに

8
00:00:19,387 --> 00:00:22,770
ポップアップが表示されるのを
見たと思います。

9
00:00:22,937 --> 00:00:25,300
実際に起こっていることは

10
00:00:25,467 --> 00:00:27,770
ブラウズしている間
自動的に

11
00:00:27,937 --> 00:00:32,010
（CubHelix を選んでみましょう）

12
00:00:32,177 --> 00:00:35,740
この小さな領域に

13
00:00:37,020 --> 00:00:40,390
表示されています。
そしてパッケージの場合にも。

14
00:00:43,110 --> 00:00:46,350
説得力のある例を見つけるのは

15
00:00:46,517 --> 00:00:49,240
少し難しいのですが
例題のコードを使って

16
00:00:49,407 --> 00:00:52,090
汚いコードをその中に書いくと
表示されます。

17
00:00:52,280 --> 00:00:57,080
Counter に行って

18
00:00:57,247 --> 00:01:00,480
例えばデバッグ用のコードを残すと

19
00:01:02,350 --> 00:01:04,730
システムはここで自動的に 2 つのことを
伝えてきます。

20
00:01:05,180 --> 00:01:09,310
デバッグ用のコードが

21
00:01:09,477 --> 00:01:12,200
メソッドに残されていると言っています。
どうしましょうか？

22
00:01:12,940 --> 00:01:14,540
このルールがどうして出てきたかはわかります。

23
00:01:14,707 --> 00:01:16,680
クリックすると

24
00:01:16,847 --> 00:01:19,800
ブレークポイントを使うように言ってきます。
プロダクションコードではあまり賢いやり方ではありません。

25
00:01:21,280 --> 00:01:25,260
自動的に解決できると言っています。

26
00:01:25,427 --> 00:01:26,340
では試してみましょう。

27
00:01:27,300 --> 00:01:28,530
これを消すように言ってきます。

28
00:01:28,720 --> 00:01:30,240
はい、これで良いです。

29
00:01:30,950 --> 00:01:32,710
そしてその結果
もう問題はありません。

30
00:01:34,540 --> 00:01:36,700
プログラミングしている時に

31
00:01:36,867 --> 00:01:40,100
こうしているのを今までも見てきました。
システムが反応してくれます。

32
00:01:40,460 --> 00:01:43,350
さて、もう 1 つのやり方があります。

33
00:01:43,517 --> 00:01:48,250
対象のパッケージを
クリティックブラウザで開きます。

34
00:01:48,417 --> 00:01:49,460
今回はとても小さなパッケージです。

35
00:01:50,960 --> 00:01:55,460
間違えてみて、どうなるか見てみましょう。

36
00:01:55,627 --> 00:01:56,440
ここで self halt とするか

37
00:02:01,020 --> 00:02:02,790
あるいは別のメソッドで

38
00:02:03,460 --> 00:02:06,910
increment3 メソッドを作って

39
00:02:07,077 --> 00:02:08,790
存在しないメソッドを使ってみます。

40
00:02:08,957 --> 00:02:11,740
foofoo としましょう。

41
00:02:13,110 --> 00:02:16,010
さて、ここで赤なわけですが

42
00:02:16,177 --> 00:02:18,900
頭が熱でぼーっとしたりして
気付かなかったことにしましょう。

43
00:02:20,590 --> 00:02:24,360
コードをクリティックブラウザで開くと

44
00:02:27,380 --> 00:02:31,250
クリティックブラウザは

45
00:02:31,417 --> 00:02:32,770
一連のルールを表示します。

46
00:02:33,720 --> 00:02:38,620
実際、沢山のルールが

47
00:02:38,787 --> 00:02:42,790
説明付きで示されています。
もしこのコードがあったら

48
00:02:42,957 --> 00:02:46,200
こうしたほうが良い

49
00:02:46,367 --> 00:02:47,450
もし内部でアロケーションがあれば。

50
00:02:47,617 --> 00:02:49,620
ルールには数種類あります。

51
00:02:50,040 --> 00:02:52,160
最適化に関係したルールや

52
00:02:52,327 --> 00:02:54,300
潜在的なバグを特定するためのルールや

53
00:02:54,650 --> 00:02:56,600
バグを特定するルールがあります。

54
00:02:56,860 --> 00:02:59,200
ここへ行くと、コードを見ることができます。

55
00:02:59,367 --> 00:03:03,050
元の定義を見ることや

56
00:03:03,217 --> 00:03:05,810
変換することができます。

57
00:03:08,180 --> 00:03:12,160
そして警告が消えます。

58
00:03:13,610 --> 00:03:15,400
ここで大切なことは

59
00:03:15,567 --> 00:03:17,920
全てのルールは経験則だということです。

60
00:03:18,087 --> 00:03:19,700
つまり、意図的にあまり良くないことを
することもあります。

61
00:03:19,867 --> 00:03:22,840
システム中でわかった上で

62
00:03:23,007 --> 00:03:24,200
そうせざるを得ないこともあります。

63
00:03:24,367 --> 00:03:28,840
これは偽陽性（実際には問題ではない指摘）
だと指定することもできます。

64
00:03:29,007 --> 00:03:33,660
ここに foofoo メッセージがありますが

65
00:03:33,827 --> 00:03:36,660
わかった上でそのままにしたいとします。

66
00:03:36,827 --> 00:03:40,240
すると、このルールはこのメソッドには
正しくないと指定することができます。

67
00:03:41,850 --> 00:03:44,850
そう指定します。

68
00:03:45,017 --> 00:03:46,510
ここでグレーになりました。

69
00:03:46,677 --> 00:03:49,690
これは後になって

70
00:03:49,857 --> 00:03:51,310
このルールの言う通りかもしれないということで

71
00:03:51,477 --> 00:03:53,490
後でまた見たほうがいい

72
00:03:57,250 --> 00:03:57,883
ということです。

73
00:03:58,410 --> 00:04:00,640
指摘を保存しておくことができます。

74
00:04:00,807 --> 00:04:04,910
つまりルールの結果や

75
00:04:05,077 --> 00:04:06,670
偽陽性といったものを保存します。

76
00:04:07,290 --> 00:04:08,850
もし偽陽性になるようなものを書いた時

77
00:04:09,017 --> 00:04:11,000
ルールを走らせるたびに何度も何度も

78
00:04:11,167 --> 00:04:12,680
ずっとシステムが繰り返し
指摘してほしくはありません。

79
00:04:13,400 --> 00:04:18,230
指摘を保存すると、クリティックブラウザは
それらの指摘をマニフェストに入れます。

80
00:04:18,470 --> 00:04:21,690
見てみましょう。ここにマニフェストがあります。

81
00:04:21,857 --> 00:04:23,920
システムに関連つけられ
バージョンが付けられています。

82
00:04:24,087 --> 00:04:26,410
内部的にどうなっているかを
見る必要はありません。

83
00:04:26,577 --> 00:04:29,400
マニフェストは色々なことをコード化しますが
それはどうでもよいです。

84
00:04:29,700 --> 00:04:32,590
マニフェストに触らないでください。
コードクリティクスが次回実行される時に

85
00:04:32,757 --> 00:04:34,120
使われるものです。

86
00:04:34,287 --> 00:04:36,260
そしてマニフェストはパッケージごとにあります。

87
00:04:36,700 --> 00:04:38,100
コードにバージョンをつけると

88
00:04:38,267 --> 00:04:39,920
マニフェストにもバージョンをつけます。

89
00:04:40,087 --> 00:04:42,880
そしてコードクリティクスを再び走らせると

90
00:04:43,047 --> 00:04:44,890
自動的に偽陽性やメタコメントが

91
00:04:45,057 --> 00:04:47,040
取り入れられます。

92
00:04:47,207 --> 00:04:49,510
これらの品質ルールについて
本当に大切なことは

93
00:04:49,677 --> 00:04:53,390
Pharo はそれらのルールを
開発プロセスに統合しているという点です。

94
00:04:53,557 --> 00:04:56,010
プロジェクトを

95
00:04:56,177 --> 00:04:58,570
コミットするたびに

96
00:04:58,737 --> 00:05:01,170
Jenkins サーバーがそれをロードして

97
00:05:01,337 --> 00:05:04,000
それらの品質コードを自動的にチェックして

98
00:05:04,167 --> 00:05:05,920
プログラムが本当に品質ルールに
従っているかを確認します。