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

技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（後編） ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しました。 この記事ではそのダイジェストを紹介します。記事は前編と後編の2つに分かれています。今お読みの記事は後編です。 森崎氏による補足説明 前編では、グループA（命名的問題）より、グループB（構造的問題）の方が正答率が大きいということ。一方でグループA（命名的問題）よりグループB（構造的問題）の方が読みにくさを感じた、という点に統計的に有意な差があったことが発表されました。 発表の後、オンラインイベントの参加者からの質問について森崎氏と和田氏

[gfx]

"Diffでコードレビューするようになったことで、Diffの小ささがよしとさよしとされてしまう。これをやや俯瞰で見ると、構造的複雑さとか命名的な悪さというのが、じわじわと累積されていく形になる"

[t-wada]

協力しておりました名古屋大学の森崎先生の研究、コードの保守性に関する問題のうち命名的問題と構造的問題のどちらにより問題があるかを解析する実験の結果をpublickeyの新野さんに記事にしていただきました

[koo-sokzeshky]

抽象モデルの不備が命名と構造のどちらに現れているかの違いでしかないとも言えるけど、だとしても命名のほうが致命的というのは分からなくもない。「よかれ」の話は実際それでよくて、リファクタPRの不在が問題かな

[beejaga]

そもそもパシッと名前付けができるとコードはまとまるし複雑性を局所化できたりもするしね／コード保守でdiffを最小化しようとしてレガシーコードの問題を先送りしてしまうのはわかりみが深い

[mohri]

“調査に参加される方々を最初JJUG（日本Javaユーザーグループ）で募ったので、だいぶ強者が集まってきた”

[afukuhara]

"抽象化することで、コードの詳細まで読みにいかなくとも、名前を見て、中身を信じるという、コードの書き手とコードの読み手のあいだの一種の信頼関係によって認知コストを下げる。という関係が成立する"

[tacamula]

“グループB、つまり命名に問題はないが構造的に問題を抱えているコードを読解した方々の方が、読みにくさを感じたにもかかわらず、正答率が高かった”

[izoc]

"機能追加の際などにレビュワーの負担を下げようとしてコードのDiffを小さくしようとするんです" これ昔からあるよね。余計な修正をして責任問題にしたくないから構造的問題には目を瞑り最小限の修正に留める

[katsyoshi]

“さらに言えば、英語にもイギリス綴りとアメリカ綴りがあったり、なんかいろいろあって英語的に正しい命名をしてもあまり通用しなかったり" 昔よくいわれたのが「こんな難しい単語現地では使わなかったよ」です。

[nemoba]

ささっとA Philosophy of Software Designを和訳する作業に戻るんだ(違う)

[mikage014]

"Diffでコードレビューするようになったことで、Diffの小ささがよしとされてしまう。これをやや俯瞰で見ると、構造的複雑さとか命名的な悪さというのが、じわじわと累積されていく形になる"

[NetPenguin]

テストコードの関数名を日本語で、は本当にそうだと思う。(メンバーが日本語メインの人達である前提） なのだけど、コード中コメントを他人が読んだときに分かるように書いたり出来ない人も多い事を考えると……

[nakex1]

白紙状態で命名を疑う所から入れるかというとな。「命名が誤っていることに気づかずに（中略）命名をそのまま信頼してコードを読み進めていくことによって、結果的に読みやすいと感じたけれども、正答率は低い」

[otihateten3510]

勘違いさせるコードは非常に危ういよね。なぜ勘違いさせるのか？は構造的になってるのでめんどくさい。

[mumei-0]

“関数名は日本語で書いてもいい”

[taguch1]

まず修正したいところを状態にあった正しくダサい名前に変えてマージしてしまう。。 そのダサい名前を治すためにリファクタして正しい名前に戻すモチベを無理やり叩き起こす。