こんなコードは読みたくない！久しぶりに頭を抱えるコードに出会った

エンジニアの仕事をしていると、設計書も無く、実装担当者もいないコードを改修しなくてはいけないときが一度はくると思います。

自分も何度もそういった経験をしてきました。 今では勘も働くようになり、初めてのコードでも理解するまでにそこまで時間がかかることもなくなりました。

ですが、今日久しぶりに頭を悩ませるコードに出会いました。 なんでそんなコードを読むことになったかというと、簡単な定数を変えるぐらいの改修を行うはずが、いざテストしてみると、バグっぽい動きがあったのです。

そのプログラムを改修したことがあるエンジニアは全員退職済み。 残された資料とプログラムをもとに、改修したこともない、仕様もあんまり分かっていないコードを調査することになったのでした。

仕様が複雑

まず詰まったのが仕様の複雑さ。 設計書があったのですが、その資料に書ききれないほどの処理を行っていました。 資料と照らし合わせてコードを追っていたのですが、急によく分からない定義がでてくる。 その定義の説明は、資料にはどこにもない。 うーん、困った。

コメントが少ない

ひとつひとつのメソッドには、きちんとコメントが書かれているんです。 メソッドの中にも、ちょこちょことコメントが書いてある。 書いてあるが、足りない。不十分。 急によく分からない計算式が、なんの説明もなく出てくる。 何してるのここのコードはああああ。

正しい結果が分からない

この結果と、この結果は、同じ結果になるはず。でも違う結果が返ってくる。 そもそもどっちが正しい結果なのか。 それともどっちも間違った結果なのか。

外部データの設計が分からない

今回見ていたプログラムでは、わたしたちのチームの管轄外のデータを多く利用していました。 そのため、取得もとのデータの仕様がそもそも分からないという事態に。 例えば60日以内に更新された件数をDBから取得する、といった処理を行っているのですが、 どのカラムがその60日以内の更新件数にあたるのかが分からないという。

いかがでしたか。 初めて見るコードの不具合を探すときって、なんとなく当たりをつけて探していくと思うんです。 そして大体が、結果からコードを追っていくことになると思っています。 上からコードを追っていくというよりは、下からコードを追っていく形ですね。 今回は追うもととなる、正しい結果すら分からない状態だったので、だいぶ苦労しました。

結局、3時間かけても原因がつかめず、 デバッグコードを仕込んで今日は帰宅をしました。

なんというか、不毛だ。不毛な3時間を過ごした。 こういった経験をする度に、きちんとコメントを書く、テストコードを書く、という当たり前のことがどれほど大切なのかを実感します。 つらい。