アジャイルプラクティス読書ノート ¶

ソフトウェア開発本として Joel 本の次に買った記憶がある。

著者:: Venkat Subramaniam, Andy Hunt
訳者:: 角谷信太郎・木下史彦
出版社:: オーム社
発行年:: 2007 年
ISBN:: 978-4-274-06694-8

目次以前のローマ数字ページ ¶

扉ページの絵画はヒエロニムス・ボスあたりの作品か。
ティルヴァックヴァルとやらの警句。これは何国語の文字だろうか。

第 1 章 ¶

この短い章は、本書のイントロダクションの役割を果たす。

アジャイルは <重要度の高い事柄に注力し、重要度の低い事柄（略）には労力を割かないようにする方法論> (p. 2) である。
<ソフトウェア開発は継続的なものなんだ。フィードバックも継続的だ> (p. 3)
囲み記事「アジャイルツールキット」は必読。 Wiki を筆頭にバージョン管理、ユニットテスト、ビルド自動化を挙げている。以前読んだ Joel Test と主張の方向性は同じだと思う。

第 2 章 ¶

冒頭から <ソフトウェア開発の方法論をテーマとした従来の書籍でよくある説明の流れはこうだ。（略）本書はこうした流れに従わない> (p. 11) と、威勢がよい。
<ソフトウェア開発が本当に行われる場所は、チャートや IDE や設計ツールの中ではない。人の頭の中だ> (p. 11)

1 ¶

<チームの多数の振る舞いがプロ意識に欠けていて、チームの運営に無関心な場合は、自分自身がチームを離れてよそで成功を目指すべきだ> (p. 15)

2 ¶

<実際に髪が薄くなった開発者が何人もいた> (p. 16)
<差し迫った状況で問題の本質や起こり得る結果をきちんと理解することなく、手っ取り早く加えた修正> (p. 17)
<単独行動は危険だ。開発者が独りきりでコードを書くことがないようにしよう> (p. 17) これを予防するにはやはりバージョン管理、コードレビュー、ユニットテスト。
<ユニットテストに慣れれば、コードは自然と扱いやすい単位で構造化される> (p. 17)

3 ¶

セクション冒頭でいきなり悪魔が話しかけてくる。斬新な演出だ。

<思いついたアイデアをチームの誰もが自由に表現できる雰囲気が必要> (p. 21)
囲み記事のタイトル <全員一致でラクダが生まれた> (p. 21) がインパクト大。
- <とりわけ優れた斬新なアイデアというものは 1 人の頭脳、すなわち確固たるヴィジョンを持った個人から出てくるものだ> (p. 21)
<設計とは妥協の連続だ> (p. 22)
<主張している事態がどれだけ可能性があることなのかを併せて評価しなければならない。主張を裏付けたり、反論したりするためにプロトタイプや調査が必要であれば、そうすればいい> (p. 23) やはり裏は取りたいものだ。
メンバー全員の「その状況におけるベストとは何か」の認識を合わせておく。

4 ¶

どうしてもコードをゼロから作り直したければ、<今のコードを捨てて書き直したほうが費用対効果が高いことを明確に示そう（口頭で伝えるだけでは不十分だ）> (p. 24)
- 著者の例が囲み記事内に挙げられている：<こんなコードではすぐにメンテナンスのコストが大きくなりすぎて保守できなくなります> (p. 24)
- <「コードがすっきりするから」では、経営陣や事業家に納得してもらえる理由にならない。費用の節約、投資収益率の向上、訴訟の回避、顧客基盤の拡張といった理由のほうが適切だ> (p. 26) 意思決定者がビジネス寄りの人間ならば、こういう毛色の用語を駆使して丸め込むるのがコツか。

第 3 章 ¶

時代に乗り遅れないようにアジャイル。

<ほとんどの考え方はあっという間に時代遅れになってしまう> (p. 27)
<時代遅れの古びた手法と決別することも重要だ> (p. 27)

5 ¶

<何やらインターネットとかいう代物も話題になっていた> (p. 29) 1995 年が懐かしいような。
<イテレーティブかつインクリメンタルに学習する> (p. 30)
<定評のある技術系ブログ> (p. 30) はみんな見ているから、自分だけ見ていないと思うと恐ろしいことになる？
<非技術系の良書> (p. 30) どこから外側が非技術系なのだろうか。関係ないが、本を読む以前に、身銭を切って本を買うのを避けている。
<新技術は、採用を決める前にそのメリットをきちんと評価しなければならない> (p. 31)

6 ¶

<もし自分が一番上手いんだとしたら、それは別のバンドに移る時だ> (p. 32) という某ジャズギタリストの至言は心を打つねえ。
<『一週間でおぼえる XYZ 入門―パターンと UML で完璧マスター！』といったタイトルの書籍は十中八九、読書会向きじゃない> (p. 32) いかにもありそうなタイトルで笑える。あくまで読書会向きじゃないだけで、読むなとは言っていない、はず。

7 時が来たら習慣を捨てる ¶

<変化への対応> (p. 35)
<現代では開発者の時間こそが貴重な（しかも高くつく）リソースなのだ> (p. 36)
<古い習慣に気づくのはそれに輪をかけて難しい> (p. 36)
<例えば、新しいプログラミング言語を学ぶとしよう。この場合は、その言語用の新しい IDE を使うようにする> (p. 37) まったく耳が痛い。
<これまで経験した言語で使い慣れた独特の特徴にはとりわけ注意を払い、新しい言語や新バージョンでは、互いの類似点や同意点を学ぼう> (p. 37)

8 わかるまで質問する ¶

<質問をする前に、そう問う根拠を考えておくこと。事前に考えておくことには、質問と問題との関連を確実にする効果もある> (p. 40)

9 ¶

<アジャイルプロジェクトにはリズムと周期がある。このおかげで物事を進めやすくなっている> (p. 41)
<一日の終わりにチェックインされているコードはすべてテストされているように計画を立てよう> (p. 43) チェックインというのはコミットのことだと思うが、これは難しい。

第 4 章 ¶

<避けて通れない敵とは、変化だ> (p. 45)

10 顧客に決断してもらう ¶

<自分たちが決定すべきでないことは何かを決定する> (p. 48)

11 ¶

<こうした作業を経てはじめて、コーディングに着手できるレベルの構造にたどり着けるのだ。事前に考える手間を省いてしまったら、いざコーディングに取りかかるや否や、想定外の問題に圧倒されてしまうかもしれない> (p. 50)
<川岸にたどり着かないうちから、川の浅瀬を渡る方法の詳細を考えるなんて時間の無駄だ。実際に川岸にたどり着いてからのほうが適切に判断できるだろう> (p. 52) 一瞬わけがわからなかったが、川岸というのは手前側の川岸か。
<「設計する」という行為そのものに、何者にも代えがたい価値がある> (p. 53)

12 技術の採用根拠を明らかにする ¶

<職務経歴書駆動設計> (p. 54) とはいい言い方だ。
<あまりにもごった煮すぎた> (p. 55)
<ダウンロードできるものを開発するな> (p. 55)

13 いつでもリリースできるようにしておく ¶

<チェックイン済みのコードは常に動作可能な状態にする> (p. 57) システム開発の本ならば必ずこの一文が書いてあるとみた。
<継続的インテグレーションといっても、小難しく考えることはない。要するに、コードのチェックアウト、ビルド、テストをバックグラウンドで定期的に実行するだけのアプリケーションだ。スクリプトを書いて自作するのも簡単だが、既存のフリーでオープンソースなツールを使ったほうが、動作も安定しているし機能も充実している> (p. 58)

14 ¶

<統合はソフトウェア開発で特にリスクが大きい領域のひとつだ> (p. 61)

15 早いうちにデプロイを自動化する ¶

<少し時間をとってプロセスの自動化を検討してみよう。これはエンドユーザ向けの本格的なインストールシステムを作るときのベースにもなる> (p. 64)
囲み記事で本項目の主張を補強する。
- <初日どころかプロジェクトの開始前に、全面的に自動化されたインストール手順を用意してしまうプロジェクトすら実在する> (p. 65)
<ユーザがいつでもインストール内容を安全かつ完全に削除できるようにしておくこと> (p. 66)

16 ¶

囲み記事 (p. 70) のプロジェクト用語集の有意性についての議論は説得力がある。チームのメンバー同士でも専門用語の解釈が違っていることがある。
<仕事の都合で月に 1 回しか打ち合わせできないなら、その頻度でやるしかない> (p. 71)

17 ¶

<大規模なプロジェクトのほうが失敗しやすい> (p. 72)
<だったら単一の大規模アプリケーション開発をやめればいい！アプリケーションを使える単位で小さく分けて作る――つまり、インクリメンタルに開発するんだ> (p. 73)
<プロジェクトの完了まであと 1 年あると言われたら、なんだか余裕があるような気がするだろう？> (p. 74)
<メンテナンスを済ませてから、次のイテレーションを開始するのだ> (p. 75)

18 定額契約は守れない約束 ¶

このタイトルは傑作。

見積もりは実作業を基準に見積もるしかない。

第 5 章 ¶

19 ¶

<変数が期待値どおりであることをテストするコードは共通化できる。テストをどれだけ実行したか管理するコードも共通化できる。こうしたテストの作成や構成といった低レベルの雑多な処理には、標準的なフレームワークを使えばいい> (p. 81)
<ビルド用マシンでは、常に最新バージョンのソースコードを取得してコンパイルし、ユニットテストを実行させる。実行結果が想定外のものだった場合には、直ちに通知させるようにする。この作業をバックグラウンドで実行できるようにしておく> (p. 82)
<自動化されたユニットテストを習慣にしなさい> (p. 84) ああ、エンジェルの言うとおりだ。
<アクセサや、結果が自明なメソッドのテストには、そんなに時間をかけなくてもいいだろう> (p. 84)

20 作る前から使う ¶

冒頭のドッグフードの話に既視感を覚えた。何だったかな。

TDD は Test Driven Development - テスト駆動開発の略。<TDD では、コードを書くことが許されるのは、失敗するユニットテストを書いた後だけだ。そして、必ずテストを先に書かなければならない（テストファースト）> (p. 86)
<真のポイントは、「目的の機能をきちんと果たす実装に必要な最小限の作業」を見つけだすことだ> (p. 89)
<TDD では（略）どれぐらい便利なのかや、使い勝手についても考えることになるので、結果としてより実用的な設計にたどり着けるというわけだ> (p. 89)

21 ¶

<どうにかして突き止めた犯人は、プラットフォームによる .NET API の挙動の違いだった。 Windows XP と Windows Server 2003 とでは挙動が異なるのだ> (p. 91) Win32 API ではあるが、まさにここに書いてあるような経験をした。これを読む前だったら、こういうことが起こるものだと知らずに、パニックになっていたかもしれない。
<複数のプラットフォームでテストしたければ、プラットフォームごとに継続的インテグレーションツールをセットアップすればいい> (p. 92)
<いまどきビルド用マシンのハードウェアの価格なんて、開発者の時給に換算すればたったの数時間分だ。VMWare や Virtual PC のような製品を使って複数バージョンのオペレーティングシステム、VM、CLR を単一のマシンで走らせて、さらにハードウェアコストを節約してもいい> (p. 92) とあるが、マシンを置く場所がない。
<ハードウェアよりも開発者の時間のほうが貴重だ> (p. 93)

22 ¶

開発中に、顧客の「実データ」が喉から手が出るほど欲しいことはよくある。しかし、まずそのようなものは貸してくれない。その理由は単純だった。<もう既に正しいデータを入手できるのだとしたら、新しいシステムなんで別に必要ないのだから> (p. 95)

23 ¶

<「今日の進捗率は 80 パーセントです」みたいな報告を耳にしたことはないだろうか？何日たっても何週間たっても、ずっと進捗率は 80 パーセントのまま> (p. 97) 確かにこういう構成員がいる。報告書が前回のコピペだったりする。
<バックログは複数あっていい> (p. 98) 本物は一つでいい。

24 ¶

なぜ開発者は <ユーザーの声にきちんと耳を傾ける> (p. 101) のを忘れがちなのか。その辺の見解が欲しい。

第 6 章 ¶

コーディングに関連するトピックをあつめた章だ。

25 意図を明確に表現するコードを書く ¶

<じゃあ、2 は何だろう？ 2 杯？ 2 ショット？それともカップのサイズ？> (p. 106)
<小賢しいコード> (p. 108) というフレーズが気に入った。

26 ¶

<ソースコードのわかりやすさとはコメントによるものではない。コード自身のエレガントさと明瞭さによるものであるべきだ> (p. 110)

27 トレードオフを積極的に考慮する ¶

<とはいえ、そこそこ性能の出ているアプリケーションの速度をさらに追求する必要はあるだろうか？たぶんない> (p. 115)
<予断は禁物だ。実際に確認すること> (p. 117)

28 インクリメンタルにコードを書く ¶

「インクリメンタルにホニャララする」という見出しがいい。

エンジェルが <コードを書くときは編集・ビルド・テストのサイクルを短くしなさい> (p. 118) と言っているが、そんなことは承知している。短くできないから困るンだ。

29 ¶

<何か引っかかるものを感じたら、それは「どこか間違っているからだ」と考えるんだ> (p. 121)

30 凝集度の高いコードを書く ¶

右ページの家具のお化けみたいなイラストがインパクト大。

<例えば、洋服がすべて同じ引き出しに放り込まれているとしよう。靴下を探すにも、ズボンやら下着やら T シャツやら、ほかの衣類を引っかき回さなければならない。これは非常にいらいらする> (p. 122)
<このアプリケーションでは、画面のそれぞれは HTML だが、データベースにアクセスするための埋め込み SQL 文といっしょに、相当な量の VBScript が組み込まれていた> (p. 123)
「単一責任の原則」と「再利用の単位とリリースの単位の等価性」を調べること。

32 ¶

リスコフの置換原則とは <要するに、基底クラスのメソッドを使っているコードは、コードの修正なしに派生クラスのオブジェクトを扱えなければいけない> (p. 129)
<「委譲だとメソッド呼び出しを転送する小さなメソッドを大量に書かないといけなくなる」という意見もあるだろう。（略）しかし、だからといってそんな理由で継承を使うのは間違いだ> (p. 131)

第 7 章 ¶

<デバッグは時間を読めない> (p. 133)

33 ¶

<古来、エンジニアはそうやってきたのだ。彼らはそれを 開発メモ と呼んでいる> (p. 134)

34 ¶

<どんな警告も無視されないように、一番厳しい設定にしよう。 GCC には -Werror オプションがある。Visual Studio なら、プロジェクト設定を変更すれば警告をエラーとして扱える> (p. 137) 趣旨には大賛成だが、実際はよそのライブラリーをインクルードするところで警告が出るのでやらない。
当節の助言・忠告にすべて従うと、<警告が（略）警告のように感じられる> (p. 138) ようになる。
<インタープリタ言語にも通常は実行時の警告を有効にするオプションがある> (p. 138)

35 問題を切り分けて攻める ¶

<コードが他のモジュールに依存しているなら、モックオブジェクトを使って余計なモジュールから分離する> (p. 140) と、ユニットテストしやすいコードとなる。ピンとこない説明だ。

36 あらゆる例外を報告する ¶

<もし回復できなかったとしても、何が悪かったのかをコードの呼び出し元へと適切に知らせることができたら、それもやっぱりすばらしい。しかし、いつもそうであるとは限らない> (p. 143)
<この例外を空の catch ブロックで握りつぶし、代わりに null を返していた。これではヴェンカットの呼び出し元コードからは、何が起きているのか知りようがない> (p. 143)
<対処できない例外は伝播させること> (p. 144)

どの言語でも例外のハンドリング方針は同じようだ。

37 ¶

<ログだけでは十分ではない> (p. 145) ユーザーにもメッセージを送る。
囲み記事のエラー種類の分類は、「解決できるのが誰なのか」による分類になっている。

第 8 章 ¶

再びチームワークの話題。

38 ¶

つっ立ったままでミーティングを進めると、短時間で済ませられる。
ミーティングの各参加者の発言内容は、きのうの作業内容、今日の作業予定、問題点の三つに絞る。さらに、発言時間を定数時間に制限する。これで会議が長引かない。
<出勤時間の 30 分から 1 時間後に始めるのが適切だろう> (p. 154)
<スタンドアップミーティングが待ち遠しい> (p. 155) そんなヤツはいないだろう。

39 ¶

<PowerPoint でコードは書けない> (p. 157) には笑った。
<こういう設計者は現場では役に立たないことが多いしね> (p. 157) 「現場で」役に立たないなら、どこで役に立つのだ。

40 ¶

<大規模プロジェクトでは、全員がてんでバラバラに変更していては大混乱を招くことになる> (p. 161)
<コードの共同所有を避けたほうがいい特殊な状況もある。（略）コードを書くのに専門的で特別な知識が要求される場合がそうだ> (p. 161) 専門的で特別な知識が要求されない場合とは？

41 ¶

<質問に答えられなければ、そこが自分の不得意な分野だとわかる。その分野こそ、自分がもっとよく学ばねばならない分野だ> (p. 162)

43 ¶

<開発者が分散していたりオフショアだったりするので、バージョン管理システムへのアクセスが遅い、というのはよくある言い訳だ> (p. 166)
ちょっと長いが、正確にノートしておこう。<通常、チェックインするファイルは特定のタスクや修正済みのバグに関係している。チェックインは意味のあるまとまりで行う。チェックイン時には意味のあるログメッセージを書くこと。ログメッセージは将来の誰かに向けたものだ。どのファイルを変更したか、そしてなぜ変更したのか（これが重要）を伝えるためだ。コミットをアトミックに、すなわち論理的にはこれ以上分割できない最小単位でコミットしていれば、変更をロールバックする必要に迫られたとしても困らない。コードをチェックインする前には、すべてのユニットテストが通ることを確認しておこう。継続的インテグレーションを実践していれば、バージョン管理システムに登録されているコードが正常かどうかを簡単に確認できる> (p. 167)

44 ¶

<コードレビューをやりっぱなしにしないこと> (p. 171)

第 9 章 ¶

9.3 ¶

<取り入れるプラクティスは、スタンドアップミーティングから始めよう> (p. 178)
開発インフラの整備として「達人プログラマースターターキット」三点セットを採用する (p. 178):
- バージョン管理
- ユニットテスト
- ビルドの自動化

付録以降のページ ¶

[GHJV95] の著者陣リストで、Ralph Johnson と Erich Gamma の間にカンマが要る。
天使の助言集だが、もう少し活字が大きいと読みやすい。