「Ruby on Railsを扱わせたら世界トップレベル」と自負するチームと最近仕事で会う機会があり、かなりの影響を受けた何某です。こんばんわ。
英語が出来たら、もっとつっこんだ会話が出来たのにと後悔しております。
というか自分の技術力のなさにかなり落ち込んだわけですが、逆に中級者にあがるステップと前向きに考えてみた次第。
彼らは、
「TDDを開発手法として採用しない理由はないし、最も効率のいい開発手法だと考えている。そして、それを一番効率よくこなせるのがrailsだから僕達はrailsを使うんだ。」
と語っておりました。
『うん。わかるよー。』
と、見栄をはってみた。
仕事絡みじゃなければ素直に教えてくださいと言えるのに。。。
とにもかくにも、今後を考えるとある程度知らなければならないので、rspecを最近必死にやっております。
そこで、rspecを利用したなんちゃってTDDをやってみた。
15〜30分程度の開発サイクルを繰り返すため、リズミカルで気持ちいいというが、いきなりは無理。
まずテストの書き方がわからないため、1工程をこなすのに2〜3時間以上余裕でかかる。
↓
テストを書くのが面倒になり、いつも通りいきなりコーディングしたほうが早いことに気づく。
↓
こう書けばこう動くとわかっているところは多少複雑でもテストを書かなくなる。
↓
ある程度の機能が完成。動かしてみると問題なく動く。
↓
別な機能を実装中、以前実装している関連機能に手をいれることになる。
↓
改修した関連機能でデグレーションが発生。
改めて長々としたテストケースを書いてバグを再現させてみる。
↓
テストケースを書きやすいコードを書けばいいことに気づき、１から作り直すことにする。
↓
自然とシンプルなメソッドが増え、可読性と保守性があがった気がする。
また、仕様をテストケースで確認するようになってきた。
でも、他人が書いたテストケースを理解するのにはまだ時間がかかる。
↓
デグレはテストケースをきちんと書いておけば、比較的容易に発見出来ることに気づく。←今ここ
なんで今までちゃんとやらなかったのかと後悔してます。非常に便利。
これはブラウザで動かす前にかなりのバグ減らせるよねって話。
実際に意識してやってみるまでは、どんなに有効かってのはわからないものです。
恥ずかしながら、PHPでプログラミングを覚えた技術者が多いうちの会社では、ユニットテストなどの存在すら知らない人がほとんどだ。
実際、彼らが読んだ本を見ても、テスト手法などほとんど書いていない。
あっても「登録ボタンを押したらDBにデータが入っているか確認しましょう。」くらいのもの。
私もPHPから入ったので、いろんなPHP関係の書籍を読んだが、確かにPHPはその手のことはほとんど書いていない書籍が多い。
でも、こんなに便利な開発手法があるのにやらないのはもったいない。
というわけで、うちの会社でTDDをやってみようと言ってみた。
ほとんどPHPの開発なので、せめてPHPUnitだけでも採用しようと。
javaや.Netをやってきた人は実際やったことがあるらしく、必要とうなずいた。
ところがそういう手法があるということを知らなかった、PHPerの反応がすこぶる悪い。
「テストなんてWebアプリなんだからブラウザでやるものでしょ。」
「プログラムのテストをやるためにプログラム書くなんてダルい。」
「書く前から動くとわかっているコードをわざわざテストする気にならない。」
まぁ大体こんな感じ。
以前、PHPのフレームワークを導入しようと提案した時は、
「フレームワークを使わないのがPHPだ。」
「俺のOOPはフレームワークには負けない。」
とわけのわからない理由で一蹴され激論したが、今回の理由は自分で実際思ったことがあるだけにわからんでもない。
間違っても、PHPをdisっているわけではないが、先に書いた通り、PHPには「こういったテスト方法があります、実際やってみましょう」という書籍が入門書に書いてあることがほとんどないので、この手の話題は理解し難い人がうちの会社では多い。
javaをかじったことがある人は「Eclipseを使ったテスト方法」などの解説が入門書の時点からあったりして、事前に知識があるので特にこういう話題の違和感はないようだ。
確かに単純な開発速度で言えば、ひたすら書いたほうが早い。
テストケースを書かない分早いのは当たり前だ。
問題は保守の時にかなりの差が出るはず。
これは実際に自分でやってみた感想。
先にも書いたが、設計=テストケースとすると、書き方の良い悪いはともかく、自然とコードがシンプルになる。
複雑なコードではテストケースを書く事自体面倒になるから。
もちろん、スキルに左右はされると思うし、私の書いたコードを自信満々に人に見せれる気にはならないけれども、それでも、「テストを楽にする」という意識を持つだけで無駄なコードはかなり減らせる。
今までは、とりあえず動くものを最速で出してきたが、改修が入った時に複雑なコードを追わなければいけない、デグレが発生してないかを手作業で全部見なければいけないなど、とにかく改修作業が大変だった。
逆に、シンプルなコードは見やすい、改修しやすいでいいところしかない。
でも、TDDが導入出来ない。
「とりあえず今まで通り、人に見せられないようなプログラムを一気に書いて、とりあえず動くものを出して、客に怒られながら終電まで残業し、必死でバグを直し続け、直ったと思ったらデグレって死にそう。」
と、
「今までExcelで管理してた人手のテストケースを捨て、テストケースを逐一走らせながらプログラムの動作を確認し、都度バグを直し、品質をかなりあげた状態でリリースして、客が怒らないくらいのバグ改修で済む可能性が今までよりも高い開発。」
では、越えられない壁がある。
それは、「納品までの工数」。
工数を減らすのはさすがに最初は難しい。
慣れるまではリリースまでの作業が格段に増えてしまう、というのがボトルネックになるようだ。
また、バグが出ても納品後なら、もうすでに納品しちゃったんだから気楽という考えもあるようだ。
私は、納品前ならいくらバグが出ても怒られないが、納品後じゃ客に怒られるじゃんと考えるので、いまいち理解は出来ないが、そういう考えで開発している人達にとっては、TDDというのは必要ないと考えるのだろう。
もちろん、バグが出たとなったら、対応しないわけではないし、きっちり改修は行うが、そこにあるのは地獄です。
もうそんな日々は嫌ざんす。
まぁ問題なく開発出来てれば今まで通りやるんだけどね。
出来ないんだから何か対応策考えないとね。
開発手法より説得手法を覚えるべきと思った今日この頃。
マーチン ファウラー Martin Fowler 児玉 公信 平澤 章 友野 晶夫 梅沢 真史
ピアソンエデュケーション
売り上げランキング: 8673
おすすめ度の平均:
リファクタリングの勉強するなら
オブジェクト指向がなんでいいの。その回答がここにある。
体質改善の処方箋
可読性向上の特効薬
コーディングが変わった
