かしブログ

技術ブログ的なものです

MedBeer -Rails開発での技術的負債との付き合い方- に参加してきました

MedPeerさん主催のイベント、「 MedBeer」に参加し「技術的負債」をテーマにRails開発のリードエンジニアの方々のお話を聞いてきました。
自分的にすごく刺さるテーマで、参加できてよかったです。

各発表のまとめ・感想

前島 真一(メドピア株式会社技術顧問) さんの「Rails Good Parts, Bad Parts」

前島さんの発表は、新たな負債を作らないためにはどうすれば良いかという内容でした。
負債を作らないためにはRailsのレールに乗る取り扱い注意な機能・ライブラリについての向き合い方が大事ということでした。

Railsのレールに乗るとは
  • Railsには便利な機能がたくさんある
  • レールに乗るとはRailsが提供している機能を活用することである
  • 便利機能の存在を知らず、スクラッチ開発をして微妙な感じになってしまうのはもったいない
  • 便利機能の存在を知るには
    • 公式ドキュメントやRailsガイドを読む
    • 強い人にレビューやペアプロをしてもらう
取り扱い注意な機能・ライブラリについての向き合い方
  • 安易に採用すべきでない機能やライブラリ例: defalut_scope,devise,webpacker,etc...
  • この手ものの扱い方
    • チーム内でよく吟味する
    • 吟味する時間がないなら禁止する
    • 周りがdisってるからといって、吟味せずに使わないっていうのは良くない
  • チームメンバー全員が負債になりそうな要素に対して対応法を知ってることが大事
    • 社内教育を頑張りましょう
clean-rails.orgについて
  • 可読性の高いRailsコードの議論をするコミュニティ
  • どのように実装するか迷った時に相談できる

MedPeerさんでは社内教育の一環で、ペア(モブ)プロやプルリク振り返り会をやっているそうです。
この2つ、今の現場でも最近積極的に行っておりドメイン知識の共有にもかなり役立っています。
発表を聞いて、チーム開発ではメンバーの知識の標準化が大切なんだなと思いました。

佐々木 達也(Classi株式会社) さんの「Classiでの負債返却への取り組み」

佐々木さんの発表では、いかにして負債の返却を行ってるかの発表でした。
自分の最近の業務内容と照らし合わせ共感できる部分が多く、「あーわかるわー」とつぶやきつつ聞いてました。

ペアプロ/モブプロの導入
  • 一人だと辛いコードもみんなで読むと読める
  • チーム内で知見とやれた感が共有できる
  • みんなでやった感がある
聖地部
  • 負債返却のための活動
  • モブプロで行う
  • 2h/週で開催
  • ボーイスカウトルールの精神
  • 今までやれなかったことができる
  • 小さな成功体験が積み重なる
一人の方が早くね?
  • 大切なのはPRマージ(=リリース)までの時間
  • レビューはベテランがやりがち(=結局時間かかる)
  • モブプロならベテランがコード書ける

発表を聞いて、やはりモブプロのメリットは多いなと思いました。 また聖地部という活動で、定期的に負債返却を行える環境がとてもいいなと思いました!

村上 大和(メドピア株式会社) さんの「メドピアにおけるライブラリアップデート」

タイトル通り、どのようにライブラリをアップデートしているかという内容でした。
自分はこのような作業はやったことはないのですが、なるほどなーと思いつつ聞いてました。
1年数ヶ月ぶりのbundle updateの苦労話から改善の流れが聞けて面白かったです!

bundle update flow
  1. CIにて毎月1日にbundle updateのPR作成
  2. 担当者3人で差分チェック
  3. 必要であれば修正
  4. テスト環境にて1週間漬ける
  5. リリース

発表を聞いて、やはり小まめなupdateは大事なんだなと思いました。 また仕組み化することで運用しやすくなるとのことでした。 npmのupdateも同様に、yarn update flowとして行っているそうです。

小室 直(クックパッド株式会社) さんの「クックパッドの巨大 Rails アプリケーションの改善」

「お台場プロジェクト」というプロジェクトを立ち上げ、cookpad_allという巨大なRailsアプリをどのように改善していったかというお話でした。

お台場プロジェクトでやったこと
  • 開発メトリクスの定点観測
    • コード量、起動時間などを可視化、計測
    • 改善結果を見える化
  • シムテム削除
    • 不要なAPIやworkerを削除
  • システムの分割
    • システムを正しく分割
    • 機能のマイクロサービス化
  • コード削除
    • 頑張って不要コード削除
    • 頑張って不要Gem削除
    • Code Cleaning Contest
      • コード削除コンテスト
      • 豪華景品も

発表を聞いて、ただただすげーと思ってました笑
お台場プロジェクトがうまくいっている要因にプロジェクト名をつけたことを挙げられてましたが、自分も数ヶ月前の業務で似たような経験がありとても共感できました。
プロジェクト名をつけることでチーム全体が同じ問題にフォーカスでき、良い結果につながったと認識してます。

最後に

今回は現場で実践している様々な負債返却方法が聞け、とても参考になりました。
得られた知見を今後の業務でも活かしていけたら良いなと思いました!