TDDBC2.0に参加してきた
TDDBC2.0(札幌)に参加してきた。僕にとっては初めてのTDDBCだったので正直ついて行けるかかなり心配な中での参加だった。
演習ではRubyを選択し、@ayuminさん、@sandinistさんと組ませていただいた。お二人ともRubyはもちろん vim の使い方や Github にも慣れていて一緒にペアプロしているだけで非常に勉強になった。TDDの形式は一定時間たったらドライバとプログラマが交代するという乱取り形式というやり方。最初はタイマーで５分を計りながらやっていたけれどちょっと時間が少な過ぎるということで大体10分、もしくは区切りのいいところまでという感じですすめた。
気づいたこと、感想など
- バージョン管理の徹底。演習始まってすぐに@ayuminさんがすかさず GitHubにリポジトリを立てて共有してくれた。コードと向き合う前にバージョン管理環境を整えるという見本のような行動だった。早速それぞれのマシンに clone し、演習中は push と pull を繰り返しながら自分がプログラマでない時もコードを見ながらアイデアを出し合ったりした。細かい区切りで「ではコミットしましょうか」と促してくれたので、GitHubのコミットログを見るだけでどのような歴史で演習に取り組んでいたのかが一目瞭然だった。さらにいつの間にかコミットした瞬間にコミットログが Twitterにつぶやかれるようにしてくれていたのにも驚いた。
- 仕様化テスト。rspec を使ってレガシーコードの仕様化テストを書き始めて、テストを書きながら仕様を理解していくというのを実感できた。仕様を理解できればリファクタリングのアイデアも浮かんで来る。テストがあるから既にレガシーコードではなくリファクタリングも恐くなくなった。バージョン管理も徹底されているから壊れたらいつでも戻れるという安心感がよりリファクタリングを後押しする。
- レガシーコードとの戦い方。まずはファイル分割し、多少手を加えてでもテストしやすいように慎重にI/Fを見直す。テストコードが書き難い所にはそもそも構造的な問題がありそうで、その辺りをリファクタリング対象としてチェックしていく。ある程度テストでセーフティーネットができたというところでリファクタリング。様子を見ながら不安なところにテストを追加していく。カバレッジもリアルタイムで監視しながらやれると仕様化テストの網羅率も明確にできてもっと良かったかなと思った。
- 同時に戦わない。作業を進めて行くと、バグフィックス、テストコードのリファクタリング、テストの追加、コードのリファクタリングなど今すぐやりたいことが同時に複数現れ始めるけれど、そこは一旦落ち着いて今やるべきことをメンバで整理／認識合わせして進めることが大事だと思った。「ここは一旦テストを綺麗にしてから、次のテストを書きましょう」とか「リファクタリングして構造を綺麗にしてからバグフィックスするためのI/Fを考えましょう」など。一度に複数の敵を相手にしてはいけない。あと、ついついコードを触りすぎてしまいそうになる時も「ここはまだテストコードが無いから触っちゃだめだね」と正しい手順を意識しながら取り組むことで不可解なバグやデグレに遭遇することも少なかった気がする。
- 良いテストコード。今回は外部ファイルに書き出すプログラムだったので、テストコードで吐き出すファイルと本物コードが吐き出すファイルとが混ざって多少混乱した。テストは何度でも実行可能でなければならなく依存関係を無くす、という原則に乗っ取って、テストコード用の出力ファイルを分けることや後始末をするタイミングが重要だと感じた。
- テストの自働化。これは@ayuminさんが演習の終盤で環境を作っていて、guard-rspecを使ってファイルを保存した瞬間にテストが自動的に流れて結果が growl に表示されるという究極的にすばやいフィードバックを得られるようにしていた。自分もそれを見習って帰ってから早速環境構築してみた。コードやテストを編集しながら自分の想定通りに結果が自動的に通知してくれるのを横目で確認しつつ、次々とタスクに取りかかれるのはものすごく快適。想定外の結果の時だけちゃんとテスト結果を確認すれば良いので思考が中断されにくいのがいい。時にはコンソールを切り替えてテストを実行し、結果に対してみんなで一喜一憂するのも大事なアクティビティだと思うけれど、一人で黙々と作る時は作業効率アップへの強い武器になると感じた。
- 道具にこだわる。お二人とも vim をかなり使いこなしていてものすごいスピードでコードを書いたりファイル間を移動したりしていた。超基本動作しか使っていない自分とは大違いだった。特にタイマーで時間を計りながら作業していたから５分で自分が書けるコードの量の少なさを実感できたし、みなさんに申し訳なく思った。自分が使う道具の使い方にこだわって、より効率の良い使い方を追求することの重要性を知った。
- ３脚椅子。演習は言ってしまえばものすごく小さいソフトウェア開発なんだけれど、その中でさえもソフトウェア開発の三本柱(三脚椅子)の、バージョン管理、テスティング、自働化を徹底することの重要性を実感できた。僕の知る「何百キロステップ作ってます！」というような大規模開発を行っているプロジェクトでもこれらを徹底しているところはほとんど無いんじゃないだろうか。それってプロの仕事じゃない。すぐに腐ってしまうレガシーコードを大量生産しているだけだ。
まとめ
いろいろ書いたけれど、ソフトに対して真摯に向き合っている人達と一緒に開発できた今回の経験は自分に取ってとても大きな宝になった。今後のテストやコードへの向き合い方の大きなヒントをたくさんいただいた。最近は開発現場から離れてしまって直接活かせる機会は減ってしまったけれど、少しずつでも現場の人達に伝えていけるといいな。
このような貴重な機会を作っていただいた @shuji_w6e さんやスタッフのみなさま、素晴らしい講演や演習フォローをしていただいた@t_wadaさん、本当にありがとうございました。
- 演習で作ったソース
