Hatena::ブログ(Diary)

k_0kamotoの日記

2012-12-23

TDDはじめましたが。 #TddAdventJp

このエントリは、 TDD Advent Calendar jp: 2012 の 日目の参加エントリです。前日のエントリは @YasuOzaさんのTDDを取り入れたい誰かのためにでした。

私のいる職場では1000行を超えるメソッドやisなんたらっていうメソッド名で戻り値がStringで"falus"だったりするのが散見されるんですが、今回はそんなウンコードがあるよ、酷いよね!っていう話ではなく、そういう職場にTDDを導入しようとしたらどうだったかっていう話を書こうと思います。

私は数年前、デスマにやられました。
リリース前からリリース後まで爆発炎上し、チームメンバーは疲弊し、お客様にもご迷惑をたくさんかけてしまいました。
この反省から、チームの改善を模索するようになりました。
もっと良いシステムを作り、お客様に喜んでいただきたい。
チームにもっと楽しんで仕事をしてもらいたい。
そう思うようになりました。

いろいろな縁もあり、改善の手段として、TDDに注目するようになりました。
私自身はケント・ベックの「テスト駆動開発入門」の写経はしたし、TDDBCにも参加したので、これでテストを書ける!チームに導入したる!と意気込んだのですが、いざチームに導入しようとするといくつかの壁にぶち当たりました。

テストが書けない。
Assert文でテストする値の取得方法が分からない、というものでした。
言っている意味が分からないかもしれませんが、戻り値で返すということや、(良いか悪いかは別として)プロパティを作るということが思いつかないということです。
強引にテストしたい変数をすべてpublicにして、そのままにする人もいました。

リファクタリングができない
リファクタリングしてどうするべきかが分からないというものでした。
クラスやメソッドは小さい方が良いとか、結合度とか、名前付けの良し悪しとか、そういうところがそもそも共感できていなかったという問題です。

一つのメソッドに全部書いてあった方が分かりやすいという意見を聞いたことがあります。
あちこちに飛ぶのは分かりにくいというものです。

TDD関連の書籍に書いてあることが理解できない
テスト駆動開発入門」の写経をしてもらっても、意味が分からなすぎるという状況でした。
コンストラクタって何?クラスの継承って何?なんでわざわざプライベート化するの?っていう状態でした。


しばらくやってみて分かったのは、テストを書くということ以前に、クラスの継承がどうとか、変数のスコープがどうとか、そういうことが理解できていないとテストは書けないし、ましてやリファクタリングなんてできるわけがない、ということです。
考えてみれば当たり前ですが。

私はこれらの過程があり、チームにTDDを導入するのは一旦諦めました。
現在は、TDDはおろか、ユニットテストだって、結局自分ひとりしか書かなくなっています。
しかし、だからといってTDD導入の試みが完全に失敗だったわけではありません。

TDDを広めようとした過程で、プログラミングの話を頻繁にしたことで、チームはメソッド変数の名前をよく考えるになり、メソッドをできるだけ小さくする傾向が出てきました。
結果、以前よりは遥かに保守性が上がり、変更にも強くなりました。
お客様に、質が良くなったとお褒めの言葉をいただいたときには飛び上がるほど嬉しかったものです。

何よりチームメンバーは自分のやっていることへの理解が深まり、プログラミングを楽しんでくれるようになりました。
チームメンバーが楽しそうに仕事をするのを見るのは実に良いものです。
目の前のプログラムは相変わらずツッコミどころは多かれど、自分の充実度は素晴らしく高くなりました。
未だにレベルが低いけれども、改善を感じるからです。

TDD AdventCalendarにはそぐわない結果ですが、チームが仮にTDDをするまでのレベルに達していなくても絶望することはない。
別の形で改善することはできるということです。

明日は @biac さんです。私は.NETで開発しているので、氏の書かれた記事にはいつもお世話になっています!

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/k_0kamoto/20121223/1356257816