結論
- 読みやすくすること
- テストしやすくすること
- 最も大事なことは「それを行うことでユーザによりよい価値やサービスを届けられるようになること」
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 を出す