技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先? - Publickey

2024-07-01

https://www.publickey1.jp/blog/24/post_301.html (前編)
https://www.publickey1.jp/blog/24/post_302.html (後編)

命名的問題の方が悪影響を与えるというのは、私の経験的にも当てはまるので納得感があった。

グループB、つまり命名に問題はないが構造的に問題を抱えているコードを読解した方々の方が、読みにくさを感じたにもかかわらず、正答率が高かった。ここが今回の研究の最も面白いところです。

これは、私も面白いと思った。
命名が間違っていることに気づかなければスムーズに読みやすく、また構造的複雑さはどうしたって読みにくいので、言われてみればそういう結果になりそう。

けれど、名前とコードの中味や、やっていることが違う、という場面を発見したときには、脳内に黄色信号が灯るというか、これはコードの書き手との信頼関係が成立しないな、というモードになるんですよね。

「書き手との信頼関係」という表現は、私には新鮮に感じられた。
過去の自分を含め、確かに名前と処理が異なっている書き手は信頼できないので、より入念に見る必要があり疲れてしまうという経験は割とよくある。

だから、基本的には良かれと思って既存コードとコーディングスタイルを合わせようとする。あるいは、これは善し悪しがある、まあ悪い方が多いんですけれど、機能追加の際などにレビュワーの負担を下げようとしてコードのDiffを小さくしようとするんです。

これも分かる・・・。
Diff が小さいことはレビューアーにとって確実に良いことなんだけど、だからといって誰も問題の本質に手を付けなくなるのは課題だな。
誰もが善意で Diff を小さくしようとしていることなので、なかなか解消が難しいポイントでもある。