コードの読み方 Ruby on Rails編

今回は、僕がRailsのコードを読む時に工夫していることを書きます。
どのようなエンジニアであれ、かなりの時間をコードを読むことに費やしていると思います。機能を追加するときは、過去のコードを読むことになりますし、ライブラリを使ったりアップデートするときは、ライブラリのコードを読みます。レビュー文化がある場合は、他の人のコードをレビューすることになります。

コードを読む時にやっていることは、人によって様々ですが、なかなか他人の工夫を知ることは少ないと思ったので、noteで共有します✍️

きっかけ

1/9(木)の表参道.rb #54 で、たくさんのRailsエンジニアが、RubyやRailsのコードを読む時に工夫していることを聞きました。抽象化の話だったり、コードをエディタの便利機能だったり、自作のデバッグツールだったり、色々な角度から工夫点を聞きました。（詳しくは、Connpassの資料か、ハッシュタグをみてください）

勉強会の懇親会で話があがったのですが、コードを読む工夫は人によって異なるので、自分の工夫してる点を軽くまとめていこうと思います。

工夫点1: コードを読む前に仕様を読む

1つ目の工夫点は、仕様理解を先に行うということです。
どのような動きをするのか把握していると、分からないコードでも大体の予測がつきます。逆に仕様を理解せずにコードを読み進めると、分からないことだらけで色々なクラスをめぐりにめぐって、詰まってしまうケースもあります😞

仕様を理解する方法は、以下の3つがあります。
1) READMEやリファレンスを読む。
2) テストコードを読む。
3) 実際に動かしてみる。

上から順にやっていって、どうしても分からない時に実際に動かすという流れになります。全体の仕様だけでなく、クラス単位でもテストコードで期待値を理解することで、実際のコードの理解が格段に上がります👍

工夫点2: すぐにコードを読める・動かせる環境を作る

2つ目の工夫点は、GitHub上にあるOSSやプライベートプロジェクトを利用する時短テクです。

普通であれば、何かgemを調べるときは、gem名でググって、GitHubのページに行くと思います。僕は、ghqを使って手元にダウンロードしておいて、必要になった時にコマンドラインからGitHubページに遷移できるようにしています。

詳しくは、クラウドワークスさんのAdvent Calendarに載っているものを使うと、aliasまで含めて説明されているので、やってみると良さそうです💪
https://qiita.com/itkrt2y/items/0671d1f48e66f21241e2
（ただし、ghqはどこかのバージョンから ~/.ghq 配下ではなく、~/ghq 配下にダウンロードされるようになったため、aliasのコマンドは修正する必要があるかもしれません🙏 ）

工夫点3: printデバッグするときは絵文字を使う

3つ目の工夫点は、printデバッグする時の工夫です。
pryやbyebugを使っている場合は、なかなか p (puts) を使うことは少ないと思います。printデバッグはすぐに欲しい情報を手に入れられますが、ログの中に埋もれてしまうのが難点です。僕は、絵文字（スタンプ）を出力内容に入れることで、ログの中からすぐに見つけられるようにしています。これは、 @willnet さんに教えてもらったテクです😍

まとめ

他人のコードを読む時の工夫は、なかなか知ることができない内容です。僕がやっている工夫点も、大半は社内でペアプロ・モブプロをする時に、教えてもらいました。
勉強会では、様々な内容をデモ付きで教えてくれた方が多く、実践してみたい内容がたくさんありました。
（エディタも、そろそろAtomから乗り換え時期なんだろうなあ・・・）

最後に、このような機会を提供してくれた表参道.rbとSansanさんに感謝😍
他の言語でも、コードの読み方とかデバッグのやり方とかあると嬉しいですね。