執筆の背景
LMの顧客信頼性エンジニアリング（Customer Reliability Engineer）として、モチベーションクラウドを利用する顧客、コンサルタント、カスタマーサクセスからの仕様確認や障害調査依頼の対応を行っています。
仕様に関する情報はコードの中にあるため、コードを正確かつ迅速に読む力が求められます。しかし、これまで私はChatGPTや先輩の力を借りながら、その場しのぎでコードを読んできたため、根拠を持った調査ができる状態には至りませんでした。
そこで、この3ヶ月間でコードリーディング力を向上させるための取り組みを行い、変化を感じることができたので、その内容をご紹介します。
（使用しているエディタはVSCです。）
変化
Before
- 値が変数なのかメソッドなのか、判別がつかない
- 変数やメソッドの定義元がわからない
- 引数で何が渡され、結果として何が返ってくるのか把握できない
- 処理の全体像を把握できない
After
- 値が変数なのかメソッドなのか、判別できるようになった
- 変数やメソッドの定義元が特定できるようになった
- 引数の加工過程と実行結果が追えるようになった
- 処理の全体像を把握できるようになった
何をしたのか？
1. 値が変数なのかメソッドなのか、判別できるようになった
コードを読む際、値が変数なのかメソッドなのかを判断できない状態からのスタートでした。
Ruby Silverの取得：数値・文字列・型の理解
1ヶ月間、毎日RExを解き、間違えた部分を最短突破 Ruby技術者認定試験（Silver/Gold対応） 公式テキストで学び直しました。
特に、メソッドの知識を習得したことで、コードをレシーバとメソッドという構造で理解できるようになりました。
コードを最小単位で分節する
常に「レシーバ + メソッド」という最小単位にコードを分解して読むことを意識しました。これにより、複雑なコードでも混乱せずに読み進められるようになりました。
よく使用されるファイルの役割を理解する
ファイル数が多いプロダクトでは、定義元を検索しても大量の結果が表示されるため、重要なディレクトリとファイルの役割を理解しました。
VSCの検索機能を有効活用して、必要なファイルだけを迅速に検索できるようにしました。
2. 変数やメソッドの定義元がわかるようになった
次に、判別できるようになった変数やメソッドの定義元を調べようとしました。
しかし、変数名やdefメソッド名、def selfメソッド名で検索すると、検索結果が複数出てきたり、0件であったりして簡単に定義元に辿り着けないことが多々ありました。
レシーバが何クラス・何モジュールか確認する
レシーバのクラスやモジュールを確認し、メソッドの定義場所を特定するようにしました。
スコープ解決演算子::を理解する
::を理解したことで、クラスやモジュールの定義場所を正確に特定できるようになりました。
- 参考資料：::（スコープ解決演算子）
def以外のメソッド定義方法を理解する
defで定義されないメソッドも理解しました。
- attr_accessor、attr_reader、attr_writerでの定義
- enumと更新・照合メソッドの定義
- 参考資料：enumについて
ライブラリ由来のメソッドを理解する
プロダクトコード内で定義元を確認できない場合、インターネットで検索してライブラリ由来のメソッドであることを確認しました。
- 参考資料：ライブラリについて
3. 引数がメソッドの処理の中でどのように加工されるかを追えるようになった
ここまでで、変数やメソッドの定義を調べることができるようになりました。
次に直面したのが、引数に渡されている値の中身が何か、その値がメソッドで処理された結果どうなったかがわからないという問題です。
binding.pryで処理途中の変数を確認
binding.pryを利用して、ローカル環境で処理を中断し、変数に格納された値やメソッドの結果を確認しました。
- 参考資料：Pryの使い方
4. 処理の全体像を把握できるようになった
ここまでで、1メソッド単位ではコードを読むことができるようになりました。しかし、複数のメソッドが使用されていたり、複数のファイルを跨いで処理が実行されていたりすると、定義元を辿っているうちに「今どこを読んでいるんだっけ？」や「さっきのファイルにどうやって戻るんだっけ？」と全体像を見失い、わからなくなってしまいます。
フロー図を書いてデータの流れを理解する
以下のように、APIリクエスト発生から処理完了までのフロー図を書いてデータの流れを理解しました。
特に、コントローラーとモデル間のデータ処理を視覚的に整理することで、処理全体を把握できるようになりました。
次の課題：「スピード」
コードを読む力は向上しましたが、業務で求められるスピードにはまだ到達していません。
次の課題は、「目的に応じて読むべき箇所と読まなくて良い箇所を判断する力」です。
細部を読み込まずとも、処理の全体像を素早く掴む方法を見つけることが必要だと感じています。
VSCで試行錯誤しているため、おすすめのプラグイン等、良い方法があれば、ぜひご教示ください！
本記事を執筆しての学び
今回の取り組みで気づいたのは、わからないことが多いと手が止まりがちな性格であることです。
わからないことが多い場合、共通の原因が隠れていることが多く、焦らず腰を据えてそれを解決することが成長の近道です。
また、わからないことがあれば、必ず記録を残し、共通の原因は何か？を先輩や周囲に相談することが大切だと痛感しました。
どんなに量が多くても、わからないことについて記録を残すことだけは続けていこうと思います。