Amazon | Refactoring: Improving the Design of Existing Code (2nd Edition) (Addison-Wesley Signature Series (Fowler)) | Martin Fowler | Software Development
マーチン・ファウラー氏の新著「リファクタリング 2nd Edition」が完成、ほぼ全面的な刷新。日本でも11月22日発売 マーチン・ファウラー氏が約2年を費やして執筆してきた新著「リファクタリング 2nd Edition」が完成し、日本のAmazon.comなどで予約が始まりました。発売日は11月22日と表示されています（下記の表紙画像からもAmazon.comへリンクしています。記事執筆時点でのAmazon.comでの販売価格は7279円）。 「リファクタリング」とは、ソフトウェアの機能追加や変更、性能向上などに備えるため、開発されたコードの外部に対する振る舞いは変えずに、より整理された、あるいは洗練されたコードに書き換えること、あるいはその手法のことを指します。 いまでは開発者の間で広く知られているこのリファクタリングの意義や方法論をはじめて系統的に解説し、普及に大きな貢献を果たした
2018/9/1、GDG DevFest Tokyo 2018にて発表した資料です。
近年、RailsアプリにService Objectを追加するメリットを説く記事が次から次へと量産されています。私は本記事において、それがなぜ正しくないかを述べたいと思う次第であります。もっとよい方法はあるのです。 私はこれまで、Service Objectに関するネット上の議論にときおり参加しては、問題に対するまっとうな解決方法としてService Objectが正しくない理由について繰り返し見解を述べてきました。実際、私は多くの場合においてService Objectよりもっとよい解決方法があると考えるのみならず、Service Objectはオブジェクト指向設計原則への配慮が損なわれている兆候を示すアンチパターンとして取り扱っています。 このような深遠なポイントを細切れのツイートやコメント欄を追って理解するのは大変です。そこで私は、私の見解を正確に表すいくつかの現実的なコードを詳しく
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Refactor your Ruby on Rails app with null object pattern 原文公開日: 2018/01/22 著者: Paweł Dąbrowsk Null Objectパターンによるリファクタリングは、指定されたオブジェクトが存在するかどうかをチェックして、存在しなかった場合に指定の属性やメソッドのデフォルト値を返す操作に適用できます。このような操作ではif条件が必要になることが多く、そのままではコードが少々読みづらいうえにテストも少しばかりやりにくくなります。Null Objectパターンを使うことでコードが非常にシンプルになり、テストも簡単になります。 Null Objectパターンを使うメリットをわかりやすく示すため、次のような事例を考えてみましょう。UserとPostという2つのク
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Rails Anti-Pattern: Fat Decorator 原文公開日: 2015/12/19 著者: Jeroen Weeink サイト: Crafting Ruby パターン名は英語表記としています。 2018/03/06: 初版公開 2023/05/25: 更新 RailsでDecoratorを用いるとさまざまなメリットが得られます。モデルはスリムになり、ビューもすっきりし、手続き臭い従来のビューヘルパーが過去のものになります。 RailsプロジェクトにDecoratorパターンを適用するとき、ともするとモデルとDecoratorを1対1で対応させたい誘惑にかられます。たとえばArticleのプレゼンテーションロジックはすべてArticleDecoratorに置く、という具合です。これはDecoratorが小さいうち
2018.03.02 Rails: Form Objectと`#to_model`を使ってバリデーションをモデルから分離する（翻訳） 概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Routing form objects with Rails 著者: Christoph Lupprich タイトルは内容に即したものに変えました。 Rails: Form Objectと#to_modelを使ってバリデーションをモデルから分離する（翻訳） Rails 5.2リリースノートをひととおり読んでみて、ActiveStorageなどに興味を惹かれたので、試してみたくなりました。本記事ではプレリリース版を用いてシンプルなアプリをビルドしました。 目的は、ユーザーがアンケート（questionnaire）を作成して結果を回収できるアプリを作成することです。最初にForm Objectを用いて
まずはサンプルクラスから始めましょう。 class SocialMediaPublisher def publish(social_media_type, user, message) social_media_api = nil case social_media_type when 'facebook' social_media_api = Facebook::API.new(user) when 'twitter' social_media_api = Twitter::API.new(user) when 'instagram' social_media_api = Instagram::API.new(user) else fail(InvalidSocialMediaType, social_media_type) end social_media_api.sign_in so
ちなみに、最初に結論だけ言っておくと、まずSandi Metzの「オブジェクト指向設計実践ガイド」を読め、という話です それだけで終わってしまいたい気持ちはあるが、不親切過ぎるしもうちょっとRails向けの話を書こうと思う。 ただ言いたいことは、よく分かってないのに使うのは止めろということ。 自分も本で書いたりした手前、それが参考にされた結果なのかもしれないが、世の中には本当に酷いクラスが存在するもので、雑にサンプルで書くと以下の様な感じのコードが存在したりする。 class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.activ
こんにちは。COUNTERWORKSアドベントカレンダー13日目担当の疋田です。 先月からエンジニアとしてJOINしました。現在、業務ではshopcounterというサービスのRailsアプリケーション開発や日々の運用、データ集計や分析を元にしたプロダクトの改善などをメインで行っています。 スタートアップのエンジニアを経験していく中で、常に素早くPDCA回してユーザからのフィードバックをプロダクトに反映することが重要になってくるため、エンジニアとしてはコードの変更のしやすさとか捨てやすさ、読みやすさってかなり重要だなーと改めて強く思ってます。 今回は3年くらいRailsやってきた中でちょっとずつ溜まってきたメンテするときこういうコード辛かったなって部分を共有できたらなと思います。 ちなみに、これらはすべて今までの自分自身もやっていた時期があるコードであり、反省の意味も込めて書いてみます。
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Essential RubyOnRails patterns — part 1: Service Objects 公開日: 2017/06/13 著者: Błażej Kosmowski サイト: selleo.com パターンの種別は原則として英語表記にしました。 2017/10/16: 初版公開 2022/03/17: 更新 Service Object（単にServiceと呼ばれることもあります）は、肥大化したActiveRecordモデルを分割し↓、コントローラをスリムかつ読みやすくするうえで非常に有用な、Ruby on Rails開発における一種の聖杯とも呼ぶべきパターンです。 肥大化したActiveRecordモデルをリファクタリングする7つの方法（翻訳） どんなときにService Objectを使うか このパターン
技術書典は書く側で参加したい気持ちはあるけど、書くネタと書く時間があるかどうか…— 神速@リリカルエンジニア (@sinsoku_listy) 2017年4月9日 あー、自分の知ってるRailsアンチパターンとか書きたいかも。自分の犯した罪(アンチパターン)を贖罪したい…。— 神速@リリカルエンジニア (@sinsoku_listy) 2017年4月9日 技術書典2 に行ったら無性に本を書きたくなったけど、本書くのは 面倒 大変です。 というわけで、とりあえずブログに記事を1つ書いてみた。 factory_girl factory_girl はテスト用データを作成するときに使う gem です。 下記は User のモデルを定義するファクトリーです。 FactoryGirl.define do factory :user do first_name "John" last_name "Doe
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Railsアプリケーションを本格的に作り込んでいくと、「エラー」とは無縁ではいられません。 しょうもないバグでエラーが発生することもありますし、ほとんど不可抗力ともいえるような大規模なネットワーク障害でエラーが発生することもあります。 エラーの種類がなんであれ、エラーが起きた場合は「原因を素早く特定し、速やかに復旧させること」と「あるエラーが引き金になって、さらに大きなエラーに引き起こさないようにすること」が重要です。 エラー処理を適切に実装していれば、原因の特定や復旧もすばやくできますし、さらに大きなエラーを引き起こす可能性
3年ほどRailsを書いてきてある程度知見が溜まってきたので、忘れないためのメモとしてKPTと導入例を交えながらダラダラと書いています。 見出しの命名規則は クラス名/ディレクトリ名の単数形をupper camel caseにしたもの + KPT です。 Keepは今後も使うもの、Problemは開発規模によっては問題が発生する(した)もの、Tryは現在使用していないが使用したほうが良いと思っているものです。 これらすべてを導入すれば上手くいくというわけでもないので、開発規模に合わせて適切に採用していくと良いと思います。 DDDやデザインパターン等見聞きはしているものの詳しいわけではないので間違っている部分等あるとは思うのでその辺りはコメントでご指摘お願いします。 はてブコメント欄で頂いた指摘内容等についてはまとめの後でまとめて返答を記載しています。 Asset (Keep) app/as
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? #経緯 casyというインターネットを使って手軽に家事代行を頼むことができるサービスのプログラマをしています。 Webだけでなく、スマホアプリも出すことにあたり、Webアプリサーバ(Rails)から機能を切り出し、APIサーバ(Rails)を別途作成し、Webアプリの場合はWebアプリサーバからAPIサーバを呼び出し、アプリからは直接APIサーバを呼び出すような仕組みにしました。 ただ、全部の機能をAPIサーバに移すのは容易なことではなかったため、いくつかの機能はまだWebアプリサーバに残っていて、アプリよりもWebのほうが機能が多い状
こんにちは。メドピアのRuby(Rails)化をお手伝いしている@willnetです。最近はよくリファクタリングをしています。 今回は、最近僕がリファクタリングしている内容についてまとめようと思います。 メドピアではFat Model/Controllerを避けるために、rubocopの設定を利用しクラスの行数が300行以下になるよう制限しています*1。最近300行を超えるモデルが出てきたので、一部の処理を別のクラスに切り出し始めました。 このとき、Railsが提供している機能であるconcernsを利用すると楽に行数を減らすことができますが、それだとrubocopの指摘を回避できるという意味しかないので、なるべく委譲(composition)を利用して処理を別クラスに移していっています*2。 複数モデルにまたがる処理を切り出す Railsアプリケーションを書いていると、複数のモデルを一度
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
