Category Archives: Reading

DIxAOP の Java Framework, Spring


Spring3 入門 (技術評論社)
Spring3入門 を Amazonで買う

DIxAOP ってなんだ? と思っていたら、 ある人が紹介してくれました。 DIxAOPについてはわかりやすく書かれているそうです。 パラパラっと見てみましたが、 EAADDD などのアーキテクチャを一通り知っている人が書いた本に見えます。 今回は第1章をじっくり読んでみました。 Spring フレームワーク の前書きみたいな内容で、 Spring を使ったことのない私にはちょうどいいです。

Spring の特徴

Spring の特徴として 際立っているのが DIxAOP だ。 第1章では紹介程度になっているのだが DIxAOP なくして Spring は成り立たないといっても過言ではなさそうだ。

Spring の DIxAOP 設計 は Webアプリケーション が抱える 3つの問題点 を解決する。 以下、簡単にまとめた。

オブジェクトのライフサイクルの問題
オブジェクトの生存期間をコントロールする作りこみが困難
部品化の問題
部品化をするためには実装非依存にする必要があるが、それなりにコストがかかる。 (注: 単にインターフェースを使えばいいという問題ではない。)
技術隠蔽や不適切な技術隠蔽
高レベルの技術を初級レベルの開発者に利用させて不具合を引き起こしてしまったり、不適切な技術隠蔽をしてその技術の利用が困難になってしまったりすることが開発現場でよく起こる。

Spring では、 上2つの問題を DIコンテナ が、 最後の問題を AOP が解決する。

Webフレームワーク というと Rails や FuelPHP, CakePHP などがあり、 「(アクティブレコードパターンの) 簡単にデータベースが使えるもの」という印象を受けてしまいがちですが、 Spring3 入門 では アーキテクチャ の考え方からしっかりと書かれていて EAAに見られるパターンの説明も(第1章では)随所で行われています。 第1章では特にレイヤの分離の説明が重点的に行われています(フレームワークを使う人には是非ともわかるようになっていてほしい内容です!)。 コードの例もあり、全体的にしっかりした印象を受けます。

以下、第1章の中で私が(個人的に)重要だと思った内容を簡単に書き留めました。

アプリケーションアーキテクチャ

プログラムを作る際には 最低でも 2つの方面からの要件・目標がある。

  • ユーザの要件: ユースケースなどで表される機能要求やレスポンスタイムなどの非機能要求
  • 開発者・運用者の目標: 開発期間の厳守、変更・機能追加のしやすさ、テストのやりやすさ

この本では 2つ目の 開発者・運用者の目標 からアーキテクチャの重要性が説かれている。

アーキテクチャに求められるもの

  • 開発効率
    • 意図を把握しやすく、理解しやすい構造
    • テストが容易に行える構造
  • 柔軟性
    • 変更しやすく、機能追加しやすい構造
    • 将来の環境の変動に耐えられる頑健な構造

ティアとレイヤ

Web アプリケーション の アーキテクチャ は ティア と レイヤ に分かれている。 ティア は 物理層 を表し、 レイヤ は 論理層 を表す。

ティア

クライアント層、中間層、 EIS(Enterprise Information System)層 の 3つに分かれるのが基本となっている。

各ティアの例
クライアント層 パソコン、スマートフォン
中間層 アプリケーションサーバ
EIS層 DB、レガシシステム

レイヤ

EAA の冒頭あたりにある分類と同じ分け方でレイヤが書かれている(プレゼンテーション層、ビジネスロジック層、データアクセス層 の3層)。 (もちろん異なる分け方もある。) 互いに隣接するレイヤ間では一方向のアクセスのみ許す。

トランザクション処理がどのレイヤに属するのかは迷うところだが、本書ではプレゼンテーション層とビジネスロジック層の境界と説明されている。

Spring3 入門 (技術評論社)
Spring3入門 を Amazonで買う

テスト駆動開発の基本とメリット


Test-Driven Development By Example (Kent Beck)
Kent Beck の Test-Driven Development By Example を Amazon で買う

同僚の勧めで Test-Driven Development By Example を読むことにしました。 書いたのはあの Kent Beck です。 日本語のものもあるのですが、そちらは絶版になっているので買うなら中古です。

この本では具体例が示されていて、どのようにテストができていき どのようにコードができていくのかがよくわかります。 まだ最初のほうしか読んでいませんが、他人(Kent Beck)のテストの書き方がわかるので、自分のやり方を見直すよい機会になります。

Test Driven の基本

Preface のところに Test Driven の基本ルールが書いてあります。

  • 自動テストに失敗するまで新しいコードを書かない。
  • 重複は排除する。

テストで失敗するまでコードを書いてはいけません。 これに関連して よくはまる落とし穴に、「テストコードのテストコードを書く必要はないのか」というのがあります。 これについて 同僚は次のような説明をしてくれました。

自動テストがないときはどうやってテストしていましたか? (PHPの場合) var_dump などでテストをしていたと思います。 テストコードのテストコードというのは、 その var_dump と 目視 のテストを書くってことと同じことなんですよ。 テストコードそのものの正しさは開発者が担保するようにして進めるんです。

わかったようなわからないような説明かもしれませんが、要するにそんなこと言っていたらきりがないからテストコードは開発者のチェックとコードの間に入れる保険なんだと思います。 またテストコードのバグについてはじゃんじゃん直していいそうです。

そして Kent Beck はコードの書き方について重要な方針を書いています。

自分の書いたコードのテストは自分で書こう

これ重要ですね。 この本をバイブルってことにしておけば、自分で書いたコードのテストは自分で書いてくれって言えますからね。 Red / Green / Refactor の順でやろうと思ったら自分で書くしかないんですけどね。

テスト駆動・自動テストのメリット

開発現場では往々にして「自動テストなんてやって意味あるのか」「時間がかかるだけじゃないのか」という議論が勃発します。 地位の高い人がそういうことを言い出すとどうしようもなくなったりします。 モチベーションにも繋がるところなので 自動テストのメリットを再確認しましょう。 本書では social implications として4つのことが書かれているのですが、それを仕事上のメリットとして書くと次のようになります。

汚いコードの密度が減り、品質保証は受け身の仕事じゃなくて能動的な仕事になる。
自分でコードを書くことが品質保証に繋がるので、問い合わせを受けてから手を動かすようなものではなくなります。
ドッキリするようなコードに遭遇することが減り、マネージャの見積もり精度が上がる。
開発者のみならずマネージャにとっても嬉しいことが起こります。
技術的な会話の議題が明確になり、同僚との協力作業の効率が高まる。
開発者の能力にもよると思いますが、書籍上ではそういうことが書かれています。
汚いコードの密度が減り、新機能の追加されたリリース可能なコードが毎日増えて顧客との関係が向上する。
毎日というのは言い過ぎかもしれませんが、バグを見落とすことが少なくなるので新規機能の追加に集中できるようになります。

特に2番目は重要ポイントですね、 テストドリブンとは関係なさそうな人にもメリットがもたらされるので。 どれも理想論に見えますが、テストドリブンの目指すところは上記のメリットです。

この本を読んで今以上にテストドリブンに力を入れていこうと思いました。 中にはテストを書かない人もいるのですが、具体的な進め方も書いてある本なので 他人への説明も楽にできると思っています。

Test-Driven Development By Example (Kent Beck)
Kent Beck の Test-Driven Development By Example を Amazon で買う