Fat Modelに対処する
6つのリファクタリングパターン2019/09/15 大阪Ruby会議02 登壇資料 https://regional.rubykaigi.org/osaka02/ Fat Modelに対処する 6つのリファクタリングパターン
ペイモのリファクタリングとの戦い
割り勘アプリ「ペイモ」がリリースされて早１年。僕がペイモiOSの開発に関わり初めたのはリリース直後だった。驚くべきことに、当時、弊社AnyPayにはアプリエンジニアが誰もいなかった。 誰がペイモを作ったのか。そう、完全に外部のチームがペイモiOS/Androidを作りあげたのだ。それもおよそ3ヶ月という短い期間で。さらに、プレスリリースの日付も決まっていたので、決して遅れることは許されなかった。今、当時の仕様書を振り返ってみても、よくこれをそんな短時間で作り上げたな…となってしまう。 では、そんな短時間でこんなハードな開発を行うとどうなるのか…。ブクブクに太ってしまったViewController。APIから受け取った配列データをDictionaryにマッピングした結果期待通りの順番が保証されていないデータ群。急に登場するTableViewController。どこで値が更新されているのか
Railsの太ったモデルをダイエットさせる方法について - メドピア開発者ブログ
こんにちは。メドピアのRuby(Rails)化をお手伝いしている@willnetです。最近はよくリファクタリングをしています。 今回は、最近僕がリファクタリングしている内容についてまとめようと思います。 メドピアではFat Model/Controllerを避けるために、rubocopの設定を利用しクラスの行数が300行以下になるよう制限しています*1。最近300行を超えるモデルが出てきたので、一部の処理を別のクラスに切り出し始めました。 このとき、Railsが提供している機能であるconcernsを利用すると楽に行数を減らすことができますが、それだとrubocopの指摘を回避できるという意味しかないので、なるべく委譲(composition)を利用して処理を別クラスに移していっています*2。 複数モデルにまたがる処理を切り出す Railsアプリケーションを書いていると、複数のモデルを一度
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
