激しく造語。ここ一年アレなコードに色々出会ってきたので、自分なりの汚いコードの読み方をまとめてみたい。
前提知識を捨てる
xxという機能だからこんな感じの実装だろう、Javaだからアレはあんな感じに書いてるだろう・・・とか、そういう前提を捨てる。
捨てる、というのは少々言いすぎだが疑ってかかる必要はおおいにある。ある程度書ける人間からすれば常軌を逸したコードであっても、そのコードを書いた人間には常識だから。
例えば、Collection使えばいいのに配列にしていたり、Iterator使えばいいのにforにしていたり、継承する必要がないのに継承していたり、メソッド名にinsert3てあったり、どう考えても冗長なコードだったり・・・そのテの「何がしたいんだ」コードが現れてもそのまま受け入れる必要がある。
こうしないと、正しい知識・技術があるがゆえに間違って読んでしまう。皮肉なことに「こうしたほうがいいのに」と考え始めると頭が沸騰してしまって先に進めなくなりがちなため。
コードのバックグラウンド情報を集める
仕様書などのコード以外のコードに関する情報を集める。
文書(があればいいけど)を読むのは基本だけど、あくまで参考にとどめておく。ドキュメントが古いままなことは良くあることなので。
それ以外にも重要な背景情報がある。それは、コードが書かれた状況・時期、コードを書いた人、書いた人の出身言語・前いたプロジェクト・思想・性格など、人から聞かなければ絶対にわからない情報。俗に言う「Cっぽい」「Xさんっぽい」書き方などのこと。
このコードのこの部分はだれそれさんが何時頃書いた・・・というのが分かると読み進めの足しになる場合がある。
こういう情報は正攻法では聞けない・聞きにくい場合があるので、飲み会などでそういう話題に及んだときは聞き漏らさないようにしておきたい。
リファクタリングの応用
自動テスト環境はおそらく無いか、あったとしてもnullチェックだけとか粗末と思われるので純粋なリファクタリングではない。
リファクタリングのうち、コードを理解したと思ったら変数名・メソッド名置換、メソッド抽出・インライン展開を行うテクニックがある。これをそのまま行うだけだが、あくまでもコード理解のためだけに使う。
紙と鉛筆
昔ながらだが、コードを紙に印刷して読み進める方法。
その際、鉛筆やペン、マーカーも併用する。重複コードがあればマーカーで囲ったり、300行ぐらいあとに同じ変数を使用していれば線で結んで関連があることを示したり・・・コードの要点や改善点に印をつけていく。原始的だがコードをプリントアウトして並べて眺めることで色々分かることも多い。
-
- -
ハッキリ言ってスーパーバッドノウハウなのでこんなの必要にならないに越したことはない。ただ、仕事でやる分には良いプログラムに必ずしも会えるとは限らないのでまとめてみた。
書いててちょっと虚しくなったのは秘密。