この記事はRubyOnRailsのアドベントカレンダー11日目の記事です。
さっそくですが、僕はこの12月にリンクアンドモチベーションに転職しました。リンクアンドモチベーションは約3年運用されてきたRailsアプリ「モチベーションクラウド」を運営してる会社です。
この記事では、僕がリンモチに転職した際、全体像を把握するために行ったことをまとめています。RailsじゃなくてもWebフレームワークならだいたい同じだと思います。中途入社や社内移動で新規のプロジェクトに関わるとき、何から始めればいいかわからず途方にくれたら、一読していただければ幸いです。
1. Modelの数をチェック
# 単純にファイル数
ls app/models | wc -l
# rakeならメソッド数とかもわかる
./bin/rake stats | grep Models
数を見れば、なんとなーくアプリケーションの大きさや複雑度がわかります。
Railsアプリとして有名なCookpadでは2014年時点で、1525個あったみたいです。
参考:クックパッド開発者ブログ
自分の感覚としては
30個くらい... 2-3人規模
100個くらい... 8-10人規模
かなぁと思ってます。
（Model数に現れない複雑さや、開発体制などにもよるので一概には言えないですがなんとなくです）
2. 行数の多いModelファイルTop3をチェック
find app/models -type f | xargs wc -l | sort -r | grep -v total | head -n3
多くのロジックが書かれているところは、それだけいろいろなテーブルと関連を持っているアプリの核となるModelであることが多いです。
よって、ファイルの行数top3を確認しました。
（ruby, railsの基本的なコード規約が完全に守られていて、適切にmoduleに分離されている超理想的なコードではその限りではないかもしれないです）
3. Gemを確認
Gemfileを見るとインフラの構成がある程度わかります。また、コードを読む上でも、「このメソッドはgemで定義されてるのか？自分で書いてるのか？」を判別するのに役立ちます。自分が開発に携わるときも、車輪の再開発をしないで済むようにgemを抑えておくのはいいことです。
モチベーションクラウドの場合、toBアプリであるという特性上、スプレッドシートやcsvの処理に関わるGemが多く見受けられました。
4. レコード数確認
select table_name, table_rows from information_schema.TABLES where table_rows is not null order by table_rows desc;
レコード数を確認することで、取扱いに注意しなければならないテーブルがわかります。
自分は100万件以上あるテーブルを取扱い注意リストに入れてます。
最後に
転職や新規プロダクトへのジョイン時は、キャッチアップだけでかなりの労力がかかりますが、個人が成長するすごくいい機会です。どんどんチャレンジしていきましょー