こんにちは、ふーが（@fugakkbn）です。
暑さも厳しさを増して参りましたが、入社して5ヶ月弱となりました。
人にも環境にも恵まれて、毎日楽しくプラグラミングできていることに幸せを感じずにはいられない今日この頃です。
さて、この5ヶ月を振り返ってみると、とにかくプログラミングが楽しい！WEB エンジニア最高！！という気持ちが98%くらいなのですが、2%くらい「苦労したな…」と思うことがあります。
それがタイトルにもある「コードを読み解く」ことです。
何に苦労したのか
プロジェクトに入った当初は本当にコードが読めないし、何をどこから読んだらいいのかもわからない状態でアタフタしていました。
モデルは300近くあるし、テストは1万ケース以上あるし…規模の大きいプロジェクトが初めてだったこともあり、断崖絶壁を見せられて「登れ」と言われているような気持ちになりました。。。
しかし数ヶ月経った今、多少はコードを読めるようになり、修正や機能追加をしようとしたときに「あの辺を見れば良さそう」というアタリもつくようになってきました。
断崖絶壁だったのが、少し勾配の大きい坂道くらいに感じられるようになりました。
この状態になるまでに自分なりに工夫したことや、チームメンバーに助けてもらいながら取り組んだことをまとめてみようと思います。
1人でもできること
サービスを触りまくる
環境構築をした後、ローカルで立ち上げたサービスをたくさん触りました（本番も触るには触るのですが、ローカルと違って気を遣うので主にローカルで触っていました）。
どんなサービスなのか、何ができるのか、誰が使うのか、どういうビジネスなのか…などを意識しながら触っていました。
ひとしきり触った後は、「その画面がどのモデルから構成されているか」に着目して改めて触ってみるなどもしていました。
実際の画面とコードを見ながら、自分の頭の中でマッピングしていくよう意識していました。
処理の流れを書き出す
コードを読むにあたっては、なるべくユーザーストーリーと対応付けながら処理の流れを追って、手元でまとめるようにしました。
いろいろなコードを追っていると少し前に追ったコードを忘れてしまったりするので、対策としてメモを残していました。
まとめることで思考も整理されますし、実際にコードを書く時にも見返せてとても役に立ちました。
ユーザーストーリーを意識するのもその機能・画面がなんのためにあるのかを理解するのに有用でした。
bin/rails console でモデルをいじくりまくる
モデルがどんな関連を持っているのか、この情報は取れるのか、このメソッドを実行するとどうなるのか、といった部分は、bin/rails console で実際にモデルを触って確かめていました。
他にも特定のカラムの値を変えたらどうなるか試してみたり、登録・更新・削除などしたときに周辺のモデルがどういう挙動をするか、なども試してみました。
モデル同士がどのように関連し合っているのかを知ることで、どのタイミングでどのモデルに影響が出るのか、というのが少しずつ掴めてきました。
db/schema.rbとにらめっこする
モデルがどんな情報を持っていて、どのモデルと関連しているのかという情報は db/schema.rb からも読み取ることができます。
具体的には「このモデルからこの情報って取れるんだっけ？」という時に主に見るようにしていました。
見た上で bin/rails console でも確認すると、理解が深まりました。
コミットログと Pull Request を見る
「ここはなんでこういう設計・書き方をしているんだろう？」と感じた部分はコミットログや Pull Request を見て、経緯を確認するようにしていました。
一見「あれ？」と思うコードでも、プロジェクトのバックグラウンドやサービスの特性などからそうしていることもある、ということに気が付けました。
同時に、自分が書いたコミットログや Pull Request を同様の目的で見られる場合も想定して、丁寧にわかりやすく書く必要があるということにも気が付けました。
人に頼ること
15分コードを読んでわからなければ質問する
15分はあくまで目安ですが、調べずに質問しても意味がないし、調べるのに時間を掛けすぎるのもよくない、という意味で15分と書きました。
調べても理解の糸口が見つけられそうになければ、Slack やビデオ通話でチームメンバーに聞くようにしていました。
チームメンバーに声を掛けるとすぐに反応をもらえるので質問しやすくてありがたいです🙏
毎日ペアプロする
1ヶ月ほど、とある機能開発で毎日のようにペアプロをしていた時期がありました。
先輩メンバーと一緒にナビゲーター・ドライバーを交代しながらペアプロしている中で、プロジェクト内の横断検索で目的のコードをサッと見つけているのを見たり、コミットメッセージから素早く Pull Request に行き着くのを見たりして「なるほど！」と思いました。
どうやって処理を追っているのかを間近で見ることができ、調べ方の引き出しが増えました。
コードレビューする
コードレビューは先輩が書いたコードを見られるだけでなく、わからない部分を教えてもらい放題で大変お得です。
また、自分の考えを表明して「確かにそうだね」と受け入れてもらえたら素直に嬉しいですし、反対に「こういう意図だからこうなんだよ」と教えてもらえると「そういう考えもあるのか！」という気付きになります。
そもそもコードレビュー自体が「コードを読む」行為に他ならないので、読み解く力を培うのに打ってつけだと感じました。
定期的なオリエンテーション
プロジェクト内のわからないことを聞いたり、先輩メンバーから「これを知っておくといいよ」といったお話をしてもらう場として、隔週でオリエンテーションを実施してもらっています。
お客様との打ち合わせの中でわからないお話があったり、ちょっと調べてわからないけどすぐに聞くほどでもないな、というようなことをストックしておいてこの場で質問させてもらうことが多いです。
実装などを通じて知ることとは別軸で新たなインプットができる機会になっています。
おわりに
コードを読み解くためにやったことを思いつくままに書いてみました。
今後は紹介した方法＋αを駆使して、より速く・正確にコードを読めるようになるともう1歩前進できそうだと感じています。
とはいえまだ把握できていない機能があったり、プロジェクトに関する知識が不足している点も多々あります。 今はまだ急勾配に感じられる坂道ですが、少しずつ緩やかに感じられるよう、引き続き精進していきたいと思います。
永和システムマネジメントでは、コードを読む・書く技術を磨き合いながら坂道をともに緩やかにしていける仲間を募集中です！ agile.esm.co.jp
