レガシーコードと闘う 1


レガシーコードとは、テストコードがないシステムの事を言うそうです。

テストコードがないシステムを保守するのがどの位大変かは恐らくやって見ないとわからないと思います。

バグが出る度に影響範囲を調査し、テスト項目を設計書などから抽出し(本当にこれ以上影響を与えてないよねと祈りながら…)、システムを修正し、手動でテストし、本当に使うのかわからないエビデンスを一杯とり(エビデンスって簡単に偽造できるよね。私はやらないけど…)、設計書を直し、上司と顧客を説得させるために自分でもよく理解できない計算式が埋め込まれたExcelのシートに私はこれだけテストしましたとテスト件数と修正したソースの行数を書き込み、リリースできる状態になったか確認する長い会議に出席させられ、自分が作ったシステムでないのに元々の品質が悪いのだと怒られつつテスト件数と修正したソースの行数から導き出された複雑な計算式の結果に上司は何となく?納得し、最後はデグレがないように祈りながら恐る恐るリリース作業をするのです。

この一連の保守作業の何が問題か?一杯ありそうだけど挙げてみます。

  • 影響範囲というのは本当に正しい?•••影響範囲をみる時にわかりやすいのはバグが出たメソッドとそのメソッドが呼び出している下層のクラスやメソッドだと思います。わかりずらいのが、バグが出たメソッドを呼び出しているクラス、メソッド。最近のIDEは呼び出している元を抽出できる機能があるけど、その機能がない場合はソースを検索して確認するしかないのです。
  • グローバル変数みたいなの。オブジェクト思考の言語では使わないと思われがちですが、例えば、windows formのクラスに多くのビジネスロジックを書き込んでいるようなシステムは各コントローラーのクラス変数がグローバル変数みたいなものです。どこで書き換えられているのかわからないですから。そのように考えると影響範囲を正確に調査するというのは大変なことなのです。
  • エビデンスというのは本当に役に立つの?•••役に立つ場合もあると思いますが、いざバグが出たときに当時のエビデンスを見てもバグが治るわけでもなく、大体なんでこれしかテストしてないの?と怒りが沸くだけです。やろうと思えば、時間差でエビデンス取って、継ぎ接ぎできそうだし(全ての手順のエビデンスを取れなんていううるさい上司がいる場合はとり忘れたエビデンスがある場合一からエビデンス取るためだけにやり直しとかあるしね)。対効果があまりない作業だと思います。が手動でテストする場合は他に証跡をとる手段がないのも確かです。
  • テストが十分かどうかどの様に判断する?•••よく使われている手法はガバレッジでしょうか?完全に信用できるわけではないのですがわかりやすくてよいと思います。が、ガバレッジを測定するにはツールがいります。そのため、ソースの行数と試験件数を引数にどの程度試験をこなしたか、密度を計算しているところもあると思います。しかし、これは問題があります。それは例えば、正規表現を使用するメソッドがあるとすると、テストがその部分に集中してしまう可能性があります。そうすると、実際はメソッドの仕様を全てカバーしていないのにテストは十分という結果が出てしまいます。逆にガバレッジだけでも不十分です。それは例えば、if文に複数の条件がある場合、ガバレッジを計測したときに全ての条件の組み合わせを試験していなくても通過してしまう可能性があります。テストが十分かどうかを検証するには、ガバレッジや密度計算の他に、人手によるレビューも必要かもしれません。
  • その設計書は本当に正しいか?•••開発時には設計書や仕様書から試験項目を抽出するのはいいと思いますが保守の場合はよくない場合があります。それは、設計書が本当にソースと一致しているかわからない場合です。機能追加や変更、バグの修正などでソースは最初のリリースから変わるのが当然です。それに設計書がついていけているか保証できますか?できる場合はよいと思いますが少しでも怪しい場合は設計書ではなく、ソースから試験を起こしそれと設計書を付き合わせる方が確実です。これは開発時にやった手動のテストを流用する場合も同様です。また設計書の記述がわかりづらい場合は、人はその部分を詳しく調べるどころかその部分を読み飛ばしてしまうことが多いのです。ソースから試験項目を抽出する場合も、コメントから試験項目を抽出してはいけません。なぜならこんな場合があるからです。エラーチェックなどでのif文のコメントに『〜をチェックする』とか『〜の場合』とか書かれることがあると思いますが一体どっちが正常でどっちがエラーとするのかこれだとわからないですよね。しかし、コメントを読んでいると勝手に解釈して正常とエラーの条件を逆に捉えてしまうことがよくあります。特にソース上でifが真である場合にエラー処理を書いたり偽の場合にエラー処理を書いたりバラバラなソースのときに間違いを起こしやすいと思います。

じゃあどうすればいいの?とにもかくにも、テストを自動化することです。

そうすると、テスト結果のエビデンスはいらなくなります。
影響範囲など確認せずとも全部テストできます。

ガバレッジツールも使いましょう。
ただし、試験のレビューは必要です。もちろん手動でやるより、観点を定めやすいし、レビューもしやすいでしょう。

仕様書やコメントとの乖離があっても現在動作しているプログラムを正とすべしです。
後から、お客様と相談してプログラムが間違っていたら修正すればいいのです。
そのときはこの自動化したテストが役に立つはずです。

実際どうやるの?というのを、次回考えたいと思います。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です