TDD BootCamp Hokuriku Extra Day - Development Antinews
これは個人的なイベントというか、起きたこととそれの観察記。
そして、BootCamp と日常を重ねて思ったことなど。
大変だ！ レガシーコードの修正だ！
TDDBC の翌日は普通に仕事していたのですが、この現場には Camp とは比較にならない劣悪なレガシーコードがゴロゴロしています。
そこに修正の依頼が入りました。自分にじゃないですが。電話口のやりとりを小耳に挟んだので、要求を再確認。
- 対象はいわゆるMVCフレームワークを利用したWebアプリ
- 最速でやってくれ（ここがもう「なんだかな」ではあるんだが）
- 変更を加える必要のあるメソッドはもう見つかっているが、これが一つで140行あってベッタベタ
- できるだけここはいじりたくない
いやぁ、レガシーだねぇ。
- どうやら基本的にはブラックリストの考え方で迂回する方法で実現できそうだ
- なんか censor のない Camp ネタのように見えるな
- この部分だけ切り出せば圧倒的にテストしやすくなるぜ。ボリューム的にも TDD の導入にモッテコイダ
というわけで、判定処理の class を別個に作るように指示。
実録！ これがレガシーな現場だ！
1時間後。
- 判定処理は class に分かれていた
- できた class は実際の処理の中に思いっきり組み込まれ、
- ブラウザで一回一回実行して人間が特定のボタンを一生懸命押して
- printfデバッグ！
orz orz orz
いや、まぁ。まぁね。TDD でやれとは言わなかったけどね。やったことはあるけど身に付いていない方法を「最速」と言われている仕事で使えとはよー言いません。
- なぜ判定にミスるのか、一生懸命に目視しているが分からない！
- けっきょく脇で見ていた自分が原因を発見
何のことはない、単に改行コードが混ざってただけで、実はこれ、自分が Camp でハマったのと同じ(笑) すぐ使える Camp
なんとか動く状態になったので、一応対応完了となった。
レガシーコードにレガシーに対応する方法のここがダメ！
上の流れの中で自分が「こりゃダメだな」と思った点を挙げておく。
実システムは遅い！
まずいちばん気になるのは、フレームワークに載っけて目視チェックする方法は不必要なコードがたくさん動いているので遅い。おまけにブラウザも不必要な機能がたくさん動いているので遅い。つまり、
Feedback までの道のりが遠い。
これが自分が PHPer なのにコマンドラインでテストを回している最大の理由。最小のコードだけを動かして最短で Feedback を得るため、そして自分の手を Terminal から離さず、より良いリズムを作るための手法として自分はコマンドラインでテストを回している。
※ まぁ、自分の環境が劣悪なのもあるとは思いますが。
ブラウザは特に「値」の目視チェックに向かない
目視チェック自体の是非はともかく、sensitive な目視チェックの工程にブラウザは向いていないと思う。なぜなら Web ブラウザは HTML のレンダリング向けのツールであり、ホワイトスペースはいい具合に省略して表示してしまう。
もちろん PHP なら var_dump() などを使うことでクォート文字列が出力されるので、「クォート文字の間に何があるか」を人間が一生懸命読めばチェックは可能。しかし。しかし、次に続く。
目視チェックの精度は決して上がらない
ここまでで、すでに
- ブラウザで正しいページを出して
- 正しい操作をトレースして
- その結果を人間が正しく読み取る
という、極めて高度な操作を行っている。
上のどれをミスっても現象の把握、問題の発見を始めることはできない。
野球に例えるとこれは高度な連係プレーなのだ。野球に興味のある人なら連係プレーが本番で完璧に機能する確率が決して高くないことをよく知っていると思う。上のテストのための操作はそれと同じである。つまり、こうした手動テストは
わざわざテスト工程にミスを自分たちで入れているのと同じ
である。また、成功したとしても、ここまでですでに脳力を浪費している。問題を発見し、デバッグを行うために使える MP が、デバッグ開始時にすでに減っているのだ。しかもこれを何回もくり返していればどんどん MP は減っていく。
疲労である。
上の方法では自動化されたテストよりも人間の疲労が大きい。結果、修正作業の速度は遅くなる。
断言する。遅くなる。
コメントアウト地獄
これは BootCamp のときにも感じたことなんだけど、日頃から TDD に親しんでいる人に比べてそうでない人の方が
コメントアウトを乱発する
傾向にあるように思う。このコメントアウトがまたコードの視認性を悪くする。
テストコードがない目視チェックの場合、当然、プロダクトコードの中でチェック用のコードがコメントアウトされたりインされたりをくり返すので、TDD していない人は
コメントアウトが入っていて当たり前
と思っているように見える。
この傾向はよくないと思う。プロダクトコードの中には、必要なコードと必要なコメントと必要な余白以外ない方がよい。コメントアウトそのものを全面否定する気はないんだけど、やはり気にすべき情報は少なければ少ない方がよいと思う。人間の脳は優秀だから無意識のフィルタリングは十分有効に機能する。しかし、本当の目的以外に力を使っているという事実は変わらない。
JOJOネタの向こうを張って HxH のヒソカの台詞で言えば
「君の敗因は容量（メモリ）の無駄使い」
オレ repos のススメ
上の話とも絡むんだけど、TDD 体質の人の多くはバージョン管理システムやエディタの機能に依存してしまうことの楽さをすでに知っていて、
「不要だよな」と思った瞬間コードをばっさり削っている
と感じた。これは
あとで必要になったら戻せばいいし、戻せる
ことを「身体が」覚えているからなんだろうなと思う。
ここで言うバージョン管理システムは、より柔軟な運用ができる分散バージョン管理システムのことを指すと考えてしまった方がよいように思う。自分も去年から official な repository である svn とは別に、自分用に必ず git か hg を併用するようにしている。この方法は多少の混乱は生むけど、
svn の commit をきれいに保ちつつオレ repos で好きなようにコードを蹂躙できる
ので
「自分の作業に対する不安」が減る
ことに繋がり、とてもよいと思う。
CVS や svn 一本だと、例え branch でもあまり変な commit を作るわけにいかないというプレッシャーが残ってしまう。このプレッシャーをオレ repos で解消すると、よりコード変更に自信を持って取り組むことができる。目先の面倒が多少あっても、最終的に
自信を持って取り組めるかどうか
が、いちばん大事なんじゃないかと最近よく思う。
当たり前の話だけど不安やプレッシャーは能力の発揮を妨げる。これはアスリートたちだけの問題じゃない。我々の日常の小さな作業においても同様に、不安やプレッシャーを取り除くことが大事なんだ。
以下完全に余談。
「git は速いから」という理由を挙げている記事を目にするけど、必ずしもすべての操作において git の方が svn より速いわけではないことには注意しておいた方がいいと思う。特にリポジトリがでかいとかディスクが遅い（ネットワーク越しとか）ケースでは、branch の操作は git の方が速いけど日常的な diff 出しは svn の方が速い、ということも起きる。日常的な操作が遅いとリズムが悪くなってしまう。