Repro Tech: Long Life RailsApps の雑なまとめ

結論

• 読みやすくすること
• テストしやすくすること
• 最も大事なことは「それを行うことでユーザによりよい価値やサービスを届けられるようになること」

Repro Tech: Long Life RailsApps

これです。

当日の発表資料

全員の方の発表資料が公開されています。

当日のメモ

概要は資料に全て書かれているため、当日メモした内容を並べます。資料と重複する箇所があります。

jokerさんの発表

• 臭うコード
  • 密結合
  • 一つの機能に長いコード
• 何をするか
  • 誰でも読めるようにする
  • 疎結合にする
• いつやるか
  • 読んでてイラついたら
  • プロジェクトに見積もりに含めた上でやる
• 個人的によくやること
  • メソッドを段落ごとに分割
  • 粒度を揃える（リーダブルコードなどを参考に）
  • 分割や粒度の話は Markdown で文書を書く場合と通じる
• 完全コンストラクタ

    - コンストラクタに詰め込んでイミュータブルにしてオブジェクトの振る舞いを限定的に
  

• 責任範囲を適正化
  • デメテルの法則
  • 尋ねるな、命じろ
  • 呼び出し先にロジックを入れてメソッドチェーンをへらす
• クラス分割（サブクラスに分割する）
• gem化（OSS化のチャンス）
• 機能削除は最強であるが、社内政治問題が大変
• リファクタ時に大事なこと
  • なぜだめかを論理的に説明できること
  • 既存のコードは誰が書いたものでも（自分が書いたものでも）信用するな
  • 仕様は絶対ではない
  • チームに怒りの沸点が低い人（コードに対して）がいるとはかどる
• 一番大事なこと
  • どうすればユーザにとって価値があることになるか

hokacchaさんの発表

• レガシーシステムを撤去
  • 自社で「煮込まれた」システムやライブラリ
  • エコシステムの恩恵を受けるためにgemã‚„Webサービスを使う
• デプロイはhakoでECSにしている
• Fluentdã‚„cronの見直し
• 秘匿値はスプレッドシートからParameter Store (AWS) へ

koicさんの発表

• 全員が知見を共有できるようにする
  • コードレビューを皆でまわす
  • ペアプロやモブプロを行う
• bundle update はこまめに（週一ぐらい？）行う
  • 担当者は半固定ぐらいがいいかも
  • CIã‚„Webサービスも使う
  • gemdiff という gem
  • 細かくやると情報が追いやすい
• Rails自体のアップデート
  • Rails 6 はもうベータが出ているのでどんどん触っていく
  • bundle install をまずは通す（まあ通らないので）
  • Rails 6 対応のための PR を出すのも良い
  • モンキーパッチは極力排除（モンキーパッチは負債）
    • モンキーパッチでなくなるように PR を出す