[読書記録] Clean Agile 5. Technical Practices

books Books
Books

5章は技術的なプラクティスに関して。技術的なプラクティスはアジャイル開発の本質部分であり、最も重要だと強調されている。

Test-Driven Development(TDD)に関してはかなりページ量を割いて書かれており、TDDの重要さを説くために会計のアナロジーが採用されている。会計では大量の記号や数字を文書として扱うが、それらの正しさを担保するために複式簿記が発明された。あらゆる取引は二回記入され、バランスしなければエラーを検知できる。あまりに重要なので、複式簿記は法によって遵守が求められる。

一方、同じように大量の記号や数字を文書(ソースコード)として扱うソフトウェアでは、TDDが複式簿記に相当する。要求される振舞いは必ず二回入力されるべき。まずはテストコードとして。次にプロダクトコードとして。

TDDでは以下の3つのルールを守らなければならない。

  • 失敗するテストを書かずにプロダクトコードを書いてはならない。
  • 失敗するのに十分なだけのテストを書くこと。
  • 失敗するテストを通すのに十分なだけのプロダクトコードを書くこと。

また、テストを先に書けば、テストしにくいコードを書くことはできない。それがTDDが設計テクニックである所以だとも述べられている。

リファクタリングについては余り紙面は取られておらず、ファウラーの素晴らしい本があるよ、ってことと、リファクタリングは計画して行うような(大きな)活動ではなく、日々の作業の中で常にやるべきものだよと言っている。

シンプルなデザインでは、設計はトレードオフなので、どれだけ行うかはバランスを取って判断するべきだと述べられている(可能な限り、シンプルに)。

ペアプログラミングについては、どれくらいペアプロするかは好きにしていいよ、30%のプロジェクトもあれば80%の場合もあるだろうね、とのこと。リサーチによるとペアプロのオーバーヘッドは約15%らしく、半分をペアプロに充てた場合は全体で約7-8%のオーバーヘッドがあるだろうと。ただレビューの効果やクロストレーニングの効果もあるのでトータルで見れば十二分にペイするよねと書かれている。

3章や4章と比べて、5章は熱量が高いように感じる。その中でもTDDについてはかなり熱く語られていて、やっぱりTDDって重要なプラクティスだよねと考えさせられた。TDDの3つのルールに従ってソフトウェアを開発するのって簡単ではないけれど、個人として、チームとして少しずつできるようにしたいところ。

次は6章「Becoming Agile」。

コメント

タイトルとURLをコピーしました