きっかけは壊れたコードだった
先日、数年前に書いたコードを久しぶりに開いたんだよね。動かない。当然だけど、依存関係も変わってるし、そもそも当時の自分が何を意図してたのか読めない部分がある。で、ふと思ったんですね。これは「修復」すべきなのか、それとも「上書き」していいのか。
この判断、エンジニアリングに限った話じゃないと思って。
デコンパイルという行為の丁寧さ
デコンパイルって、コンパイル済みのバイナリからソースコードを復元する作業ですね。完全に元通りにはならない。変数名は失われてるし、構造も崩れてる。でも「元の意図を推測しながら読み解く」という姿勢がそこにはある。
これ、庭仕事に似てるなと思ったことがあります。引っ越し先の荒れた庭を手入れするとき、前の住人が何を植えたかったのか考えながら手を入れる人と、全部抜いてゼロから作り直す人がいる。どっちが正解ということではないんだよね。ただ、前者には「読み取ろうとする丁寧さ」がある。
上書きは楽だけど、何かを殺す
リファクタリングの現場でもよく見る光景ですね。古いロジックを理解せずに新しく書き直す。動く。テストも通る。でも、元のコードが持っていた「なぜそう書いたか」という文脈は消える。
人間関係でも同じことがあると思って。相手の過去や背景を知らずに「こうすればいいのに」と言うのは、ある意味で上書きなんだよね。修復には時間がかかる。でもその時間をかけること自体が、丁寧さの正体なんじゃないかと。
境界線はどこにあるか
じゃあ全部修復すべきかというと、そうでもない。コストが見合わないこともある。元の設計思想がそもそも破綻してることもある。庭で言えば、土壌そのものがダメなら入れ替えるしかない。
境界線は「元の意図を理解した上で判断してるかどうか」だと思うんですね。理解した上での上書きは、実質的に修復と同じ。理解せずにやる修復は、ただの延命。
さらっと、まとめ
丁寧さって、手間をかけることじゃなくて「読み取ろうとする姿勢」のことなんだよね。コードでも庭でも人間関係でも。自分もつい楽な上書きに逃げがちだけど、まあ、そこは意識していきたいですね。
—
記事とは少し離れますが、低レイヤーの描画処理まで自分で触ってみたいと思ったとき、こういう本が手元にあると理解が変わることがあります。【中古】(未使用品)DirectX9実践プログラミング 書籍版 (I／O BOOKS)（参考価格：¥14,499）。古い技術だけど、だからこそ「元の意図を読み取る」練習になるんだよね。
あと、そもそもプログラミングの入り口に立ちたい人にはスタディーノではじめる うきうきロボットプログラミング（参考価格：¥2,999）もいいですね。子ども向けとあるけど、「動くものを作る」体験を最短で得られる一冊だと思って。
→ プロフィール / 他チャネルを見る
コメント