「バグ」と「リファクタリング」と「技術的負債」について


自分の書いたコードにバグがあった。

コードは何ヶ月か前にかかれたものだが、今見返してみるととてつもなく・・・汚い。

バグが出て当たり前のようなコードだ。
バグはSQLの記述ミスだった。

完全にケアレスミスだが、注意深く書いていれば防げたと後悔している。

ただ時間が経ってから考え直してみると、ただ注意深くと言っていても根本的な解決にはならないのではと思った。

根本的な解決法は何かと考えた結果、やはりUnitテストだろうと思った。

ソースを書いていた当時はどうしてもテストを書く時間を確保できず、ほとんどUnitテストを書かなかった。
こういう行為を技術的負債というそうだ。

以前保守屋だったときはあれほど、人の書いたコードにテストがないことを憤っていたのに、同じことをしてしまったのだ。

技術的負債は納期との兼ね合いなどでどうしても発生するものだ(そして溜まっていく。だから「負債」)。しかし、それは早く返済しないといけない。
それがよくわかった。

それからテストを書く時間がなかったと言ったが正確にはテストが書けなかったというほうが正しいかもしれない。

ソースを書いていた当時はわからなかったが、リファクタリングを学んだ今だから言えることがある。

Unitテストはまずメソッドに一つ以上の役割りを持たせてしまうと書きづらい。
よく考えると当然だが、あるメソッドを検査するのに二つも三つも結果のパターンがあればテストもそれだけ複雑になるし、メソッド名も曖昧だからテストを書くのにソースを読む必要があるのだ。

だから、テストを書く前提として、テストが書ける程度のソースの書き方を知る必要があったのだ。

もちろん完璧にリファクタリングをしていては時間がなくなってしまう。が、技術的負債が負担にならない程度にリファクタリングしなければならない。

ちなみにリファクタリングは設計の際にも必要になる。深いモデルはリファクタリング後に明らかになることが多いとDDD本に記載がある。

ということで、時間の合間を縫ってこのコードのリファクタリングを始めている。さすがにこれは臭いすぎるという箇所と、しょっちゅう修正している箇所からだ。

もともとforやwhileなどはなかったものの同じメソッド内に大量ifがあったり(長すぎるメソッド)、重複したコードが大量にあった。引数も多すぎるものがあったりした。

リファクタリング実行後一番効果的だったのがenumの適用だ。(リファクタリング本にはないパターンだが、effective javaに詳細あり)。これで劇的に変わった。

enumにする前はあちこちのクラスに似たコードやenumの項目分のifがあったりしたがenumを適用したクラスに責務がきちんと集まってきた。

また、リファクタリング開始当初はメソッドの抽出が多かったが小さいメソッドが多くなると別の臭いが発生する。
属性操作の横恋慕が目立ってきたり、一つのクラスにまとめられそうなデータの群れが出てきたり。。。

ただ、あまり時間もかけられないので兼ね合いはとらないといけない。

とは言え、やっとテストが書きやすいぐらいにはなってきた。

この本で初めて「技術的負債」という言葉を知った。他にもいろいろ考えなくてはいけない内容が納められている。
「プロのプログラマとは?」は必ず読むべし。



コメントを残す

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