約束の地

キャロ組

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 を出す
Powered by はてなブログ