アジャイル開発の奥義読書会、通称ゆるふわアジャイルはちゃんと続いています。本日は5回目で7章「アジャイル設計とは」と8章「単一責任の原則」についてやりました。
この記事では前回のエクストリームプログラミング開発のケーススタディについて感想を書いてみます。*1
前回はこんなの。
ゆるふわアジャイル＃２ 「アジャイルソフトウェア開発の奥義 」 - うんこめも
まずエクストリームプログラミング開発について概要はWikipediaを見てもらうとして*2、簡単に言うとテスト駆動開発とリファクタリングなどのプラクティスを使って顧客に価値を提供するソフトウェアを柔軟につくっていこう、という話。
エクストリーム・プログラミング - Wikipedia
本書ではボウリングのスコアを計算するプログラムをJavaで書いていくことを例にテスト駆動開発とリファクタリングのケースが載っている。なんでこう書くのか、自分だったらどうするかということを話ながら写経していきました。頭では分かっていたつもりだったけれど実際に手を動かしてやってみると先入観だらけだったなと気付くことが多々あったのでメモを残してみる。
（追記）ちなみに自分はJUnitはたまに使うくらいで、書いたテストをだれかにレビューしてもらう経験がないのでテストについては先入観だらだらです。
気付いたこと
・必ずしもはじめにテストをたくさん書いていくわけではない。ひとつ書いて、それに対応するコードを書いて動かす。成功したら追加したいシナリオのテストを書いて、コードを対応させていく。テストとコードが二重螺旋を描いて相克し成長していくようなイメージ。
（シナリオというのは誤解のある言葉かもしれない。ボウリングの例だと、全部ストライクだと（入力）300点になる（結果）という組み合わせ。たぶんふつうのユニットテスト）
・テストはシナリオ単位であってカバレッジを意識して細かくテストをかくわけではない。リファクタリングの結果、メソッド単位にテストが必要なほど複雑なメソッドが存在しなくなる。品質確保を目的としたテストではないけれど、品質が確保されていく。
・テストを書いているから、コードをいろいろ修正したときにデグレードなく修正できたか確認できる。だからこそ大胆な改善ができる。たとえばいったんカプセル化を破るような改善もできて局所最適に陥りにくい。
・テストを書くことで、テストを書きやすいコードになっていく。これはモジュール化されて副作用の少ないことも意味すると思う
気になったこと
・テストコードの扱い。おそらく、受託開発やそのなかでの請負開発で委託先にテスト書いてね、って話をするとそのコード量分の料金も載ってくる。契約的にどうすればいいだろうか。そもそも受託開発というスタイルが良くないのかもしれないけれど。。
・上記の理由が解決されてテストコードを書いてもらうとして、ある程度の規模の大規模開発でできるかどうか。たぶん、たいていのエンタープライズシステムの開発では既存のコードが多くてとてもテストを書けない。追加分だけ書くにしてもテストしにくいつくりになっている場合はテスト書けないと思う。
・テストのメンテナンスをどうするのか。継続的インテグレーションなツールでテストを強制しないと引き継いだ後・納品後にテストされていかないと思う。自分も引き継いだVB .NETで書かれたツールのテストが遅すぎて放置しがちになっている・・・。
・テストを書きやすくするには？GUIやファイル操作などはテスト書きにくそう。Web系ではテストを書けるようにビューを分離できるとよいっぽいけどあまりイメージがわかない。あとシェルスクリプトとかファイル操作系は難しい。ちょっと前に社内副業でつくっていたExcelからコードをつくるキケンなツールでは、サンプルExcelからコードをつくって、これがツール変更前と同じであるかどうかでテストしてたけどこれは実はテスト駆動っぽかったかも。
以上
（テスト駆動開発でまともな開発してみたいという思いはあるけれどそれを使うように組織を変えるよりは職場を変えるほうが楽かも・・・）
