コードと保守とリファクタリングと ～現場での思い出～

導入：

15年くらい前のこと。
当時の私は、Webサイトの保守運用案件を担当していることが多かった。
最近だとUiPathの改修とかもしていたけれど、その頃は手打ちでいろいろ触っていた。

そんな案件では、「他人のコードを見る」ことが、よくある。
そして、あれ、ときめくんですよね。技術者としては。いろんな意味で。

以下、私の声：

• あら、こういう実装するんだ。
• ん？この変数、さっきのと同じ？ 組み換えてるのか。constとdimで分けた方が良くない？
• いや待って。ネストが深すぎる。ネストの先に条件分岐が5個続いて、その先に50行コード。で、もとに戻る。・・ここにもどるの? ねえ、やめようよ。。

対応：

リファクタリングの前に、まずは設計書を書きたくなる。
といっても、大げさなものではなく、まずはコメントでの整理から。

コードは直接いじらず、メモ帳などにコピーして観察用にする。
もしくは、生成AIに整理を頼んでもいい（※セキュリティとミスのチェックは必須）。

例：

// ここまでは変数定義
// 変数Aの分岐処理
// 分岐の上に5段ネスト（関数化して外出し推奨）
// この条件式、前の条件に含めれば不要かも ← ここから改修提案フェーズ

次に、コメントだけを抜き出して、並べ替える。
この段階で、だいたいの修正工数が見えてくる（テスト工数は除く）。

合意形成：

そのうえで、上司に相談。

「保守性がちょっと厳しいので、設計メモをつくって、修正案と工数を出してみます。
それで検討しませんか？」

炎上していなければ、OKが出ることも多い。
あるいは「次の改修タイミングで混ぜてね」と言われるだけのこともある。

結論：

リファクタリングは、「どこまで」「いつ」「誰が」やるかを、
関係者と合意したうえで着手すること。

勝手に走るのは、ほんとうに危ない。

おまけのあとがき：

いまはもう、実際に手を動かして保守をする役割ではないけれど、かつて自分が保守していたコードや、そこに書き添えたコメントは、今でも、指先に残っているような気がする。
・・・まあ、技術者あるあるですね。