いうコードはMRIではSyntaxErrorになり、RubyVM::ASTでもSyntaxErrorと判断されますが...他のパーザは(まだ)MRIのRubyVMと100%の互換性がないPrismでパースするとワーニングは出るもののSyntaxErrorと判定されません。Protocol)に適していると言った特性・特徴があり、適材適所と言えます。前出のCoverbandにもコード解析機能(メソッドスキャナ)がありますが、食べログにちょくちょくある性質のコードが解析できない問題がありました。食べログにちょくちょくある性質のコードも解析できるようになったASTにはモジュール、クラスなどの情報も含まれているのでメソッドスキャナを自作して解決できました。まとめ食べログの取り組みでは、専任1名の体制で1ヶ月間に約300のデッドメソッドを削減することができました。この結果、コードベースのシンプル化が進み、リファクタリングに関連した不整備の検知など、様々な付加価値をもたらしました。長いメソッドの途中にあるコードを削除するのが難しい、後置if/unlessのようなメソッド記法をすると判定できないといった課題も明らかになりました。このような我々の実例を通じて、デッドコード削減におけるベストプラクティスを学び、効率的なコード管理の実現に一役買えればうれしいです。最後に、食べログではエンジニアを絶賛募集中ですので、ご興味のある方はぜひご応募ください。栗山さん、ありがとうございました!続いては質問コーナーです。Q&Aコーナー(Q)開発言語にRubyを選んだ理由や逆に課題となっている部分をお聞きしたいです中野:選んだ理由は途中からJOINしたので把握してません。スタートアップでスピード感もって作っていけるからかなと推測しています。課題は、パフォーマンス問題。最新のRubyが使えていない。依存しているライブラリもあるので、なかなか対応できていないです。(Q)ErrorBoundaryが形骸化しないような周知でどのような工夫とかされる予定ですか?中野:定例会で周知したいと思っています。プルリクベースで周知できるタイミングもあるので、色んなタイミングで布教活動を進めていきたいと思います。以外は何が候補にあがっていましたか?中野:ポストモーテム行った際にいくつかアイデアが出ましたが、主にnilチェックが候補に挙がっていたと思います。(Q)型、この辺りで大失敗のご経験とかありましたらお聞きしたいです廣江:大きく失敗するという経験は今のところないです。障害が起きることはない。RBSに書きなれていない人がgem_rns_collectionに対してプルリクを出すのに業務時間いっぱいいっぱいになっちゃうってことはありました。(Q)現在はまだRBSはRBIと比較すると型チェッカーのパフォーマンスが課題だと思います。Timeeは大きなシステムだと思いますがエディタのレスポンスは快適な方でしょうか?廣江:現在開発中のものが規模が小さいため、パフォーマンスに関して特に問題を感じることはありません。(Q)RBSの手書きスタイルはタイミーさんの中でも検証段階?ということでしょうか?廣江:検証段階です。RBSの開発者がTimeeに加わったため、今後もがっつりと書いていくことになると思います。メインのシステムでも、rbs-inlineがリリースされたら、それを活用して本格的に進めていくという話が出ています。(Q)タイミー様では、ActiveRecordのクラスについてもRBSを手書きしていますか?廣江:そこはさすがに手書きは辛いので、そこだけはrbs-railsで自動生成です。Rails(以後RoR)、Webフロント、iOS、Android、インフラ、データ分析といった単位でChapterという組織があります。自分はRoRチャプターに属していますが、その中でもtoC寄りなMatchingTribeとtoB寄りなSpotworkSystemTribeという区分があり、その中でもさらにSquadと呼ばれる単位で細分化されています。自分はその中でもお金周りに関するドメインを担当しているSquadに所属しています。(Q)素のrailsでもできることがある、良いですね。思ったのですが一瞬しか見れなかったのでもう少し詳しくお聞きしたいです。適切にActiveModelやActiveSupportといったライブラリやRailsにある機能を活用することが大切かなと思います。(Q)導入して良かった!の裏で、ここがまだまだつらいのお話ももう少しお聞きしたいです。この辺り今後の展望もあればお聞かせください。西尾:モデルのコールバックを具体的にどう扱うかなどが課題です。RailsやRubyについてキャッチアップしながら、最適な答えを模索していきたいです。間にメソッド呼び出しが20行くらいあります......西尾:コールバックが動いちゃってご迷惑おかけしたりはどの会社様も結構あるのかなと思います。辛いですよね...!(Q)Namespaceの話があったと思いますが、zeitwerkとの兼ね合いで冗長なクラス名になってしまう気がします。その辺りは受け入れてやっていく感じですか?西尾:これは受け入れています。仕方ないと思っています。(Q)カカクコムさんの歴史がすごい。Rubyを選んだ背景、決め手をお聞きしたいです。栗山:当時の選択したときにいなかったので、把握してないです。不十分なところがあったので、参考にして自作しています。(Q)すごい歴史のあるRailsアプリケーションだと思いますが、調べてみた結果、デットコードは結構あったなーって感じでしょうか?差し支えなければ教えていただけると参考になりますー!栗山:(今度テックブログにも書く予定です)少ないところと多いところでかなり幅があります。スマホアプリだと10%くらい。それ以外のところは多いところもあったりします。(Q)最新キャッチアップはどういう場所でやってますか?中野:Ruby、Rails最近書いてないんです。kaigiに参加して、単体テストのセッションなどでヒントを見つけました。Twitterでの情報を見たりもしています。廣江:Railsは毎日その日のコミットが社内のSlackに流れてくるので、気になるものは社内で共有します。メンバーが学びを共有しあう文化もあるので、そこで学んだりもしています。Railsの作者のDHHのアカウントをフォローして、彼の課題に感じていることをウォッチしています。https://x.com/dhh栗山:有識者のテックブログで、最新情報を追うことが多い。RubyKaigiで追ってなかったところのキャッチアップもしています。(Q)「Rubyあるある」もしくは「これだからRuby大好き」があればお聞きたいです。中野:Rails以外を使うと、「こんなコード書かなきゃいけないの?」と思うことがあるので、そんなときにRailsの良さを実感します。廣江:Rubyでこういう処理したいなと思ったときに、大体メソッドが用意されています。Rubyだと何か1つのことを行いたいときに、良くも悪くも書き方に複数の選択肢があるので、面白く楽しくコードを書けるところが好きです。Railsの哲学が好き。作者の思う生産性が一貫性をもって体現されていると感じるところが魅力です。栗山:かゆいところに手が届く機能があり、簡単に書けるのが良いです。したコードも書けて、幅広く対応できるところがうれしいです。いかがでしたでしょうか、レポートの内容は以上です。StreetではIT・テクノロジーに関する様々なイベントや勉強会を開催しています!参加ご希望の方はフォームよりご登録をお願いいたします。引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。