頭の中は異空間

生活を日々ハックしてよりよくするブログ

既存コードを過信しないこと!

どうも。

 

大量の既存コードを読むのが日常のコーダーにとって、既存コードが諸刃の剣になりうるっていうことを改めて痛感しました。

 

その既存コード、本当に大丈夫?

そのコードは、実は未使用だったりしないか?実はバグってるけど優先度が低いから放置されていなかったか?コーディング規約から逸脱してないか?同じ様な記述が他にもあって、思い切りDRY破ってないか?など。

完璧なコードはないにせよ、あきらかにこれはひどい、と言えるコードはいくつか見てきたので、それをコピペして(もしくはお手本にして)作ると、またクソが1つ増えるというわけ。だから、それが本当に信頼のおけるものか、第三者視点から判断して、ダメならそれごと修正してやろうという気概が一番良いかもです。

 

例えばCで言えば、includeしたヘッダファイルがバグっていたせいで特定の関数の呼び出し箇所に悪影響あったり、ポインタの指し示しているアドレスが最近の修正によってずれていたり、mallocしてfreeしてないとか、関数に値渡しをしていたり(これは初歩的すぎるか..)とか。

そしてそのバグが実は問題になってて、誰か同時並行で修正中かもしれないですし。だから、自分が力をつけてそれを見抜けるのが一番いいですし、自信がないならちょっと質問してみるのもいいかもしれません。。

 

Railsには便利なメソッドがあった!

qiita.com

わざわざ独自でエラーを吐くログ出力ロジックを組まなくても、既にRailsには便利なシステムが備わっていました。

 

例えばmodelとかlibに

# mymethodは呼びだされているかチェックしたいメソッド名、MyDepreatorで独自メッセージ定義(override)
deprecate(mymethod: 'mymethod', deprecator: MyDeprecator.new)

とか張って、もし呼び出し先があればMyDeprecatorで定義されたメッセージがログ出力されるという仕組み。

使われているか怪しいメソッドがあればこれで一網打尽にしてやればおk。

ただし一部の黒魔術に対しては対策が難しいので、それはそれで別で使ってる箇所を洗い出す必要があるかも。。そもそも、そんな分かりづらいのを使うなよって話なんですが。

もしリファクタリングする機会があるのなら、こういうちょっとした工夫をするだけで効率よくゴミ掃除が出来そう。

 

今回はこの辺で。