すでにある程度完成しているプロダクトの開発にたずさわるとき、たいていは「コードを書く」ではなく「コードを読む」から仕事を始めることになります。
このとき「コードが読めない」「コードがいい感じに理解できない」と悩むのは、それほど珍しくないでしょう。
この記事では、コードが読めないときにどう対応すればよいかを考えてみました。
コードの美しさは気にしない
まず重要なのは、コードがどれだけキレイに書かれていようが読めないものは読めない、と割り切ることです。とくにエンジニアになりたての人や自分を責めやすい人にとっては、この考えが大切だと感じます。
コードがどれだけ美しくても、自分で書いていないコードは必然的に理解しづらいものです。1
というのは、あるコード（文章）をただ読むだけで理解するのは難しいからです。社会の教科書を一度読むだけですべてを記憶できた人はいないはずです。（この理論が正しいことを前提としたいので、記憶できていた人はそっとブラウザを閉じてください。）
この点をおさえると、対処法も見えてきます。
自分のことばで表してみる
なにかを理解しようと思った場合、「読む」ことよりも「書く」ことが重要になる。という考えがあります。
何かを長いあいだ学びつづけたければ、内容を書き留める必要があります。そして、何かを本当の意味で理解したいなら、自分の言葉に直さなければなりません。メモのポイントは、自分の言葉で書くことです。2
たとえばあるコードのまとまりに自分のことばでコメントをつける。これはシンプルかつ効果的な作戦でしょう。
publicなメソッドにJavaDocがなければ、まずこれを埋めてみるのも良さそうです。他の人にも伝わる内容を書けたときはPRにすると、それだけでも一定の貢献になります。
無責任な「試行リファクタリング」をためす
自分のことばで「コメントを書く」以外には、自分のことばで「コードを書く」方法もあります。
『良いコード／悪いコードで学ぶ設計入門』 では、これを 試行リファクタリング と呼んでいます。
これ〔試行リファクタリング〕は正式にリファクタリングするのではなく、ロジックの意味や構造を分析するためにお試しでリファクタリングするものです。3
コミットしないことを前提にコードを書き換える。これはコードが汚い場合にとくに効果を発揮します。
多少の間違いがあっても気にせず、テストコードも書きません。ネストを小さくしてみたり、一部の処理を関数化してみたり、適当なクラスをつくってみたり。
とにかく既存のコードを自分のコードに染める感覚で、無責任にリファクタリングを進めます。
ある程度コードを書いた頃には、処理の内容が以前より把握できているでしょう。その後実際にリファクタリングを行うつもりなら、その設計も進んでいるはずです。
まとめ
「コードを読む」という業務はよく発生します。
エンジニアによっては、業務のほとんどがコードを読む時間にあてられるかもしれません。
もし困ることがあれば、自分を責めずに 「自分のことば・コードで書く」 という方法を試してみることをオススメします。
参照
備考
この記事では「ファイル単位のコードを読む」ことを主なテーマにしています。
もっと全体的なコードの把握（機能の理解）をする場合は、下記を参照するとよいと思います。