テスタブルJavaScript読んだ

テスタブルJavaScript

後半はペラペラと読んだ程度だが。前半はテストしやすいコードをどう書くか、なぜそう書かないといけないのか、書くとどういういいことがあるのか、という話だったが、後半は複雑度を出すツールはこういうのあるよとか、自動化する時はこういうツールがあるよ、デバッグするのはこのブラウザだとこうだよっていうツール中心の話だった。「広く浅く」という感じで、別に読まなくてもよかったかもしれない。

以下、メモ

コードは人のため

コードは「機械」のためではなく「人」のためのものであり、保守・理解しやすくすべきである、と、2章に書いてある。「保守のしやすさ」という面で、テストというのは自分が加えた変更の影響度を明らかにしてくれる役割がある。また、テストしやすくするために出来る限りシンプルにしたりすることで自分以外の人間がコードを読んでも「理解しやすい」コードを書くことができる。

複雑さ

JSLint, JSHint

複雑さを直接測定するわけではないが、「悪いパーツ」を排除しコードを健全に保てる

循環的複雑度

• Wikipedia
• コード全体をチェックするために必要なユニットテストの個数の最小値
• これが25以上に達しない限り、循環的複雑度とバグの可能性との間に関連性が無いという研究があるらしい
  • http://www.enerjy.com/blog/?p198
• 循環的複雑度が高いほど、保守時に誤った変更が発生しやすい
  • 1〜10の場合、5%だが、20〜30で20%、100付近だと60%になる
  • http://www.aivosto.com/project/help/pm-complexity.html
• jsmeterが紹介されていた
• これが高いメソッドは複数の小さなメソッドに分割するのが望ましい

再利用

• 「コードのうち85%はアプリケーション特有のものではなく、プログラムの独自性が発揮されるコードは15%にすぎない」とのこと
  • 20%近くがドメイン非依存で汎用的、65%は特定のアプリケーションドメイン固有で再利用可能、残りは再利用不可能なソフトウェア
  • JavaScriptだとドメイン非依存の部分にjQueryやYUI、Node.jsなどがあげられる

ファンアウト・ファインイン

• ファンアウト「ある関数が間接的に依存しているモジュールやオブジェクトの数を表す指標」
• ファンイン「共通の昨日の再利用度を表す指標」

結合度

• よくあるやつ。英語でcouplingっていうらしい

まとめ

• コードは人のため。保守しやすい・理解しやすいが大事。
• 指標は何個かあって、自動化して常に見ろや。

カバレッジとかテストランナーとか、karmaやkarma-coverageの方が使い慣れてるし、後半の話はあんまり響かなかったなー。

本の内容と関係ないが、前回「JavaScriptで学ぶ関数型プログラミング」を読むのにダラダラ2ヶ月もかかってしまい、読み終わる頃に前半の内容を完全に忘れてしまっていて、今回は2週間で読み終えるぞ！と決めて頑張ったのが集中力を高めることができ、非常によかった気がする。これからも2週間ペースで読もうと思う。