あるエンジニアの備忘録

読んだ本、記事の備忘録

【書きかけ】読書メモ:アジャイルソフトウェア開発の奥義(第2部)

アジャイルソフトウェア開発の奥義の読書メモです。 厚い本なので全6部に分けるつもり。今回は第2部。

1部はこちら

第2部 アジャイル設計

第7章 アジャイル設計とは?

貧弱な設計とはどのようなものか?それを避けるためのアプローチ(=アジャイル設計)は何かを説明している。

貧弱な設計の特徴は次の通り。

  • 硬さ:設計変更が困難
  • もろさ:設計が壊れやすい
  • 移植性のなさ:設計の再利用が困難
  • 不必要な複雑さ:行き過ぎた設計
  • 不必要な繰り返し:マウスの使い過ぎ
  • 不透明さ:整然としない表現

これらを避ける助けとなるのがオブジェクト指向の原則(第8章~第12章)である。 悪臭を放つのは原則を満たしていないのが原因である。

この章では、以下の文章に感動した。 良い設計とはなにか?なぜ良い設計を行うのか?の解になると思う。

アジャイルな設計とは「プロセス(流れ)や「イベント(事象)ではない。ソフトウェアの構造や可読性を向上させるために、原則、パターン、そして、プラクティスを継続的に適用する行為である。またそれは、システムの設計を可能な限り、シンプル、クリーン、かつ、わかりやすく保つために献身的な行為である。

第8章 単一責任の原則(SRP)

単一責任の原則(SRP: The Single Responsibility Principle)について説明している。

クラスが複数の役割を背負っている場合、それらの役割は結合してしまう。その結果、ある役割が変更を受けるとそのクラスが担っているほかの役割も影響を受け、不具合が生じる可能性がある。こういった類の結合は、ある部分が変更を受けると、予想もしない形で壊れてしまうようなもろい設計を生み出してしまう。

役割というと分かりづらいが本書では役割=変更理由と定義されている。クラスを変更するのに2つ以上の理由がある場合、そのクラスは2つ以上の役割があるのことである。また、永続的なシステム(データベースなど)とビジネスルールを包含するのは典型的なSRP違反とのことだ。

書いてある内容は納得しつつも、役割が何か?と言われると想像力を働かせる必要があるので難しい。ここに強くなるには想像力とドメインの知識が不可欠だと思う。

第9章 オープン・クローズドの原則

オープンクローズドの原則(OCP: The Open-Closed Principle)について説明している。

この原則はぱっとはわかりづらい。単純に考えると「拡張に開いて修正に閉じるってどういうこと?拡張する=修正するじゃないの?」と思ってしまう。これを理解する鍵はオブジェクト指向の抽象化の概念にあった。

第10章 リスコフの置換原則(LSP)

リスコフの置換原則(LSP: The Liskov Substitution Principle)について説明している。

書きかけ

第11章 依存関係逆転の原則(DIP

DIP: The Dependency Inversion Principle

書きかけ

第12章インタフェース分離の原則(ISP

ISP: The Interface Segregation Principle

書きかけ

ここまでの感想

書きかけ

読書メモ:アジャイルソフトウェア開発の奥義(第1部)

アジャイルソフトウェア開発の奥義の読書メモです。 厚い本なので全6部に分けるつもり。

第1部 アジャイル開発

第1章 アジャイルラクティス

アジャイル開発がもたらす4つの価値と12の原則について説明している。

全体を通して面白いのは「顧客」というキーワードが頻出すること。 開発者の提言だからソフトウェアに関わることに閉じた話だと思いがちだけど、 プロジェクトのコストや納期、システムの仕様を予め定めるのは無理だという前提に立てば、 契約ではなく協調(協調関係を築くための契約は必要)が重要になる。

原則1

最優先事項は顧客を満足させることであり、価値あるソフトウェアを早い段階から継続的に届けることでこれを実現する。

原則2

要求変更を歓迎し、たとえ開発過程の公判であってもそれ受け入れる。アジャイルプロセスは変化に対応することで顧客の競争上の優位性を確保する。

技術や設計に対する配慮は顧客のニーズを迅速に満たすために適用する、という考え方も勉強になる。 場面場面では局所的な課題に囚われがちだけど、本質的に今のプロセスが適切なのか評価するためには、こういった大方針はとても大事だと思う。 だからこそいきなり抽象化に向かうのではなく、とりあえず仕様を満たすソフトウェアを開発するという考え方も納得。(YAGNI原則)

原則9

高度な技術と優れた設計への配慮は、アジャイル性を高める

第2章 エクストリームプログラミングの概要

具体的にアジャイル開発を行うための実践法がかなり具体的に書かれている。 実践論的な話は聞いたことがあったので既知の話が多かったけど、勉強になったのはメタファーに関する話。

実現したいシステムのふるまいを現実の仕事(ゴミ収集車やトースターなど)に見立てて動きを説明することで、各クラスの役割を理解できる。 これはアジャイル開発だけではなく、クラス設計全般に適用できる考え方だと思った。(抽象化が難しいけど、、、)

第3章 プランニング

ビジネス側が出した各機能の重要度に応じて、開発者側はその機能を組み込むためのコストを見積もることをプランニングと呼んでいるが、この章では、このプランニングの具体的な実践法を説明している。

イテレーションを繰り返すことで各開発チームの速度(イテレーションあたりのストーリーとタスクの消化数)を計測できるという点が面白かった。 現場では、過去のプロジェクトからソースコードの生産性を導出しそれにリスクを掛けることで見積もりを行うけど、プロジェクトの難易度なんて蓋を開けてみないと分からないし、どこがボトルネックになるのかも分からない。その点、この方法では、イテレーションが短期間(2週間)であり、同じメンバーかつ各プロジェクトに閉じた範囲で速度(≒生産性)を計算できるので、尺度としても妥当性があると思う。

第4章 テスティング

プログラムを設計する前にテストを設計する利点を説明している。 テストを先に書くことでユニットテストであればモジュールの独立(関心の分離)につながり、受入テストであればユーザインターフェースへの関に繋がるという点が面白かった。

テストは動作検証に過ぎない(設計で記した仕様が漏れなくソースコードに反映されているか、の確認)という認識だったが、テストケースを検討し、実際にテストコードを書くことでアーキテクチャと設計の改善に繋がるとは新しい発見。

第5章 リファクタリング

リファクタリングの流れをでも形式で説明している。

個人的には以下の比喩が好き。(キッチンは汚くなりがちだけど)

リファクタリングは食後のキッチンを片付けるようなものだ。最後は後片付けをしなければ、それだけ食事時間は短くて済む。しかし、片づけておかないと、翌日の食事の準備をするときにもっと時間がかかってしまう。そこで、また片づけをしたくなくなる。実際片づけをしなければその日の食事は早く済ませることができる。しかしキッチンはどんどん汚くなっていく。ついには、必要な調理用具を探すだけでとんでもない時間を費やすことになってしまうだろう。

第6章 プログラミングエピソード

ボウリングのスコアを集計するアプリを題材にXPプログラミングのプラクティスをデモンストレートしている。 実際に手元でコードを起こしながら文章を追ってみたけど、想定するテストケースを手元で検証しながら開発を進めていけるのは新鮮だった。 テストが瞬時に行えるおかげでリファクタリングへのハードルが低減されるので、保守性の高いコードを書くモチベーションに繋がると思う。 ただ、このやり方だと、どうしても対象のコードが逐次追加になるので、柔軟性を保つために設計原則を頭に入れて開発を進めていくのはマストだと思う。

また、こうやってリファクタリングしていく過程を書いてくれる書籍は初めてだったので、抽象化の考え方やトップダウンアプローチでのリファクタリングなどとても勉強になった。

あと、関係ないけどテストコードのJunitのバージョンは4のよう。バージョン5で試そうとしたけど上手くいかなかった。

ここまでの感想

アジャイルがもたらす価値と具体的な進め方を学ぶことができた。 また、実際のエピソード(ボウリングスコアアプリ)をベースにアジャイル開発の簡単流れをつかむことができた。 ただ、イテレーションで逐次機能追加していく中でカオスを防ぎ、どうやって全体の整合性を高めるのか、という疑問は残るので読み進めながら解消していきたい。