最初から自分が関わっていないプロダクトコードを探索する記事を書いたのですが、そこからRails特有のTipsを書き留めておきます。
考古学するときに見るといいポイント
routesを常に見れる状態にする
Webサービスをやっているので、大概の要望は「◯◯というページの内容を変えたい」など、どこかのページをどうにかしたいという話から始まります。そのため、そのWebページがどのように処理されているかをというところが肝要という話になります。毎度 bin/rails routes して探すのもアリですし、私の場合は bin/rails routes した結果を手元に残しておいて検索をかけて使います。（ annotate のgemを入れいてるのであれば、 annotate --routes でroutesにもコメントを吐き出してくれるのでそちらを閲覧するのもアリです。）
メソッドが増えるタイプのgemがあればそれを頭に入れる
「このメソッドどこに定義があるんだ…？」と思ったらgemが生やしている、というケースはたまにあります。そういうgemがどれだけあるかを頭に入れておくだけで考古学がはかどることがあります。自分がよく知るものだと以下です。
- heartcombo/devise: Flexible authentication solution for Rails with Warden.
- 定番ではあるが、メソッド名単位だと知らないものがあったりするので認証認可っぽい名前がでてきたらドキュメントをあたると良い
- なお他のgemである可能性もあるので、その場合はGemfileから整理する。
- activerecord-hackery/ransack: Object-based searching.
- kpumuk/meta-tags: Search Engine Optimization (SEO) for Ruby on Rails applications.
display_meta_tagsというメソッドをview側で使っていればこれです。
- CanCanCommunity/cancancan: The authorization Gem for Ruby on Rails.
Viewの作り方の質感を整理する
ModelやControllerは少し見ると方向性がつかみやすいのですが、Viewは作り方の方向性が色々あるので、どういうコンセプトなのか見ていくと良いと思っています。確認ポイントは以下。
- JavaScript関連はどのような使い方をしているか
- webpackerなのかwebpackなのか、VueやReactを使っているのか、古いものであればturbolinkをつかっているのかいないのか、など。
- テンプレートエンジンは何を使っているか
- erbじゃなくてslimやhamlを使っているケースもあれば、混ざっていたりとか
- インスタンス変数の取り扱い方
挙動がよくわからなかったらテストコードを書く
ロジック面で難解な処理があれば、テストコードを書いちゃうのが一番効率がいいので書くのが早いです。View側も可能であればControllerまで処理を移植してControllerSpecを書くと挙動理解が早いです。もしページに来るべきパラメータがわからない、などであれば一旦Railsのデバッグログからパラメータを拾い上げるなどやるとショートカットできます。
考古学するときのポイント
一番はどうやってコードが伸びてきたのか、というところに思いを馳せると良いと思っています。「このコードを書いている人は既存のコードベースを参考にして書いているのかな？」とか「この人はどちらかというと責務の比重をフロントエンドに置こうとしているのかな？」とPullRequestやAuthorの名前を見ながら考えると、どのような成長の仕方をしたか、当時どういう思いで書いていたかというのがなんとなく見えてきます。
余談ですが、自分の価値観に沿わないコードを見ると憤りの気持ちが募ることもありますが、コードを考古学する本質は「なんでこうなったか」を把握して、現状のあるべき論と照らし合わせたときに誤った方向にいかないようにすることなので、憤ったときはその憤りの根源を整理して後の改善案と結び付けられるように整理できるとよいと思います。
