Chat (Lingr.com)
Informaiton
Daily
Column
- MySQL日本語の旅(5/1)
- アクセス向上秘伝(5/9)
- 一風変ったHaskellλ門(6/13)
- SICP Answer Book (5/31) 問題3.26追加
Zope Solution
Extra
アーカイブ
OSS案内所
Site Info
関連リンク
９月は休みが多くて、世間並みは良いのですが、 派遣の人にとっては、時間数が減って、残業代を稼げられなくて、つらいところです。。。 ソフトウェア業界でも、休められない人が多くて、大変じゃないだろうか。。。
私は、ＸＰの実践後、ユニットテストは開発に絶対不可欠なものと感じていますが、 ユニットテストから離れてコーディングしたことがないわけではありません。 ２度ほど、ユニットテストから離れて、コーディングした経験があります。 そして、今でもユニットテストで開発できるように模索しています。
１．機能テスト、毎回毎回同じことを
- ユニットテストの代わりに必ず、作成する関数に対して機能テストを 実施するようにしました。 総合テストと同様に、 アプリケーションを実行した際、その関数を通るように環境設定して、 その機能を実施してテストすることです。 これでも、代用は利くと自分は考えていました。 毎回毎回実施すれば、同等なテストが可能だと思っていました。
- しかし、実際行なってみると、とにかく、面倒でした。 毎回、毎回、テストする前に、環境設定しなければならないのです。 前準備に時間がかかります。 その上、蓄積された自動テストではないので、 ちょっとした修正でも、全パターンを一つ一つ手動で実施することが必要です。 同じ関数を開発している間はいいが、 他の関数の開発へ切り替わるとき、とにかく時間がかかります。 いきなり変更、修正を言われたとき、じたばたしてしまうのです。
- 時間がかかるです。これが人の神経を磨り減らすのです。 そして、テストしたがなくなるのです。 いろいろのテストケースが漏れていくのです。
２．ケアレスミスは、慎重に
- ちょっとしたケアレスミスにも、慎重でなければならないです。 地雷を気をつけるあまりに、開発スピードが落ちるのです。
- あるとき、AAAという定数と比較して、エラーとする箇所で、 私はxxx_AAAと書いてしまいました。本当にどうかしてたと思います。 あまりにも、その処理が多すぎたせいかもしれません。 タイミングが悪いことに、xxx_AAAの方は、既存で存在していたので、 エラーにはならず、問題として発覚されなかったのです。 それがお客さんに渡って、障害として挙がってきたのです。 それが解析で分かったときは、あまりにものイージーミスで、 唖然としてしまいました。 本当にアプリケーションというのは、動かしてみないとわからないんだねと思いました。 同じパスが多すぎるので、問題ないだろうとたかをくくり、 手動のテストの面倒さに負けて、テストを怠りました。 そんなつまらないミスで、お客さんの信用を失うなんて、 本当に情けなくなりました。 テストもしていないコードは、動かなくてもおかしくということを身をもって知らされました。
３．ユニットテストの経験を生かして
- ユニットテストをした経験で、 どんなコードが分かり易いか、シンプルなコードの意味など、 いくつかのことが分かるようになりましたので、 局面に絞ってコーディングするようになり、考えすぎなくなりました。 コードは小さくなり、技巧的に走らなくなりました。
- C言語でdefineを切る場合も、二つのバージョンの共通箇所で切るのではなく、 塊を持って切るようになりました。 その方が、コーディングの意図が読み易く、メンテナンスがし易いのです。 ところところで、虫食い算のように切られるdefineは読みにくく、 バグが発生し易いのです。
ユニットテスト抜きの開発は、騎兵が歩兵に変わって戦うような感じです。 とにかく動きが遅くなってしまうのです。 細心の注意を払って、前へ進むので、スピードがダウンしてしまうのです。 注意力が磨り減らされて、開発の楽しさがかき消されてしまうのです。
There is no comment.