SmartHR の `rails stats`―― 良いところ・伸びしろ全部語り尽くしちゃいます

rails stats 2024 ~ Kaigi on Rails 2024 アフターイベント https://andpad.connpass.com/event/337371/ の発表資料です。

Transcript

1. SmartHR の `rails stats` 良いところ・伸びしろ全部語り尽くしちゃいます 2024.12.10 Tue. rails stats 2024 〜 Kaigi on Rails 2024 アフターイベント@株式会社アンドパッド yuriko SmartHR プロダクトエンジニア mkmn SmartHR プロダクトエンジニア
2. yuriko （由利優子） 所属: SmartHRサブスクリプション管理ユニット 趣味: プロ野球観戦、読書、ゲーム SmartHRに入社して約1年 GitHub、Bluesky: yuriko1211 X: yuriko12111 自己紹介
3. mkmn （三上 拓也） 所属: SmartHR 労務プロダクト開発本部 趣味: たくさん Ruby/Rails歴10年め。前職ではソーシャルゲームを作っていました。 SmartHRに入社して5年目 GitHub: mkmn X: mkmn252 自己紹介
4. SmartHRの紹介
8. 今回はここ
9. SmartHR 基本機能の `rails stats`
10. • SmartHRローンチ日の2015年11月18日から 1年ずつ取得 • 特徴のある箇所を中心にご紹介 SmartHR 基本機能の`rails stats`
11. コード量の変遷
12. サービスローンチ（2015年） ->2024年 サービスローンチ（ 2015） 2024年 行数が約 30倍 Code LOCが16倍 Code to Test Ratioが増加
13. コード量の変化
14. ディレクトリの深堀り
15. サービスローンチ時 2024年11月
16. サービスローンチ時 初期の構成 • View ◦ Haml ◦ CoffeeScript ◦ bootstrap ◦ simple_form ◦ cell • SmartHR API ◦ Grape • その他 ◦ Pundit ◦ CarrierWave ◦ Sidekiq ◦ etc…
17. 2024年11月 最近の構成 • フロントエンドは別で管理 ◦ ほぼReact/TypeScript • New! ◦ GraphQL ◦ Packwerk ◦ など • 変わらない部分も多い ◦ Grape ◦ Pundit ◦ CarrierWave ◦ Sidekiq ◦ etc…
18. サービスローンチ時 2024年11月 • Controller数が約9倍 • Model数が約15倍
19. 2016年11月 2017年11月 フロントエンドのコードの整理 参考: Rails Sprocketsとのお別れの仕方 - 最初の一歩 - https://tech.smarthr.jp/entry/2017/02/21/193000
21. 2019年11月 • GraphQLの導入 • Protocol Buffersの導入
22. コード量の変化（再掲） テストコード増加が顕著 履歴機能の実装
23. • BiTemporal Data Modelを採用 ◦ activerecord-bitemporal gem • 参考: ◦ 操作履歴/時点指定アクセスの実現 - BiTemporal Data Model の実践 ◦ https://speakerdeck.com/f440/implementi ng-command-history-and-temporal-access SmartHRの履歴機能
24. 2021年11月 2022年11月 機能追加により、コードは純増 一方で、不要コードの削除も進む
25. 2023年11月 packagesディレクトリが誕生 モジュラモノリス化への第一歩
26. • モデルが多い ◦ SmartHRで作る書類は年度ごとに様式が変わ るのでそのたびにモデルを作っている • ディレクトリが多い • Specが多い ◦ 2019年頃からテストコードが増加している ◦ 機能の複雑さが増したことも一因？ 特徴
27. SmartHR 基本機能の エンジニアに `stats`取ってみた
28. • SmartHR基本機能の開発に関わるエンジニアにア ンケートを取ってみた • 良いところ・伸びしろについて調査 • 今回はそこからピックアップ SmartHR基本機能のエンジニアに `stats`取ってみた
29. • 半数が開発にジョインして1年未満 • 歴による大きな回答の違いはない SmartHR基本機能のエンジニアに `stats`取ってみた
30. • フレームワーク、言語、ライブラリのアップデートが行われている • テストが充実している • RuboCopのメンテナンス • リリース体制 • ライブラリ更新やflakyテストの改善が自律駆動でできている • PRを見ると過去の意思決定の背景が追える • Reactの状態管理に標準のhooksを使うようにした 良い点/上手く成長させられた点
31. • フレームワーク、言語、ライブラリのアップデートが行われている ◦ dependabotがPRを作ってランダムアサインをしている ◦ 有志で集まったアップデート会がRuby、Railsのアップデートをし ている • テストが充実している ◦ 基本的に実装した機能に対してはテストを書く方針になっている ◦ テストカバレッジが約88% 良い点/上手く成長させられた点
32. • system specが多い、テストの実行時間が長い • 混沌としたディレクトリ構成 • コードコメントが少ない • ドキュメントが少ない • flakyテスト • マジックナンバーが含まれたクラス名・ファイル名 • ActiveRecord::Bitemporal の罠 • jQueryを使用した古い画面が生き残っている 伸びしろ/こうすればよかった…と思う点
33. • system specが多い、テストの実行時間が長い ◦ CIの実行時間が約30分 ◦ flakyなテストもあり、30分待ってから再実行することも… • 混沌としたディレクトリ構成 ◦ ディレクトリのどこに新規ファイルを置くべきなのか迷う ◦ この処理どこに定義されているんだろう？ ▪ modelにあったりｓerviceにあったり 伸びしろ/こうすればよかった…と思う点
34. • デッドコードの削除、古い年末調整のコード削除 • モジュラモノリスの試験的導入 • コメントを書く • むやみにsystem specを増やさない • 細かなリファクタリング • ドキュメント修正 • jQueryを使用した画面のReact化 改善への取り組み
35. • デッドコードの削除、古い機能の削除 ◦ なんでもSmartHR基本機能に乗せるのではなく、適切にアプリ ケーションを分ける ▪ 2017年頃まではSmartHR基本機能になんでも乗せていた ▪ 年末調整や届出書類といった複数のアプリケーションで独立し て動くようになった • モジュラモノリスの試験的導入 ◦ 影響範囲がわかりやすくなるように ◦ まだまだ試験段階 改善への取り組み
36. まとめ
37. • SmartHR基本機能は歴史あるサービスでコード量も膨大 • 課題もたくさんある まとめ • 良くしていきたいと思っているエンジニアがたくさんいる • 一緒に挑戦したい仲間を募集しています
38. Appendix
39. サービスローンチ時 2016年
40. 2017年 2018年
41. 2019年 2020年
42. 2021年 2022年
43. 2023年 2024年