ﾅｶﾞﾓﾄ の blog

Full Cycle Developerを目指すエンジニアが有用そうな技術記事や、ポエムのようなよしなしごとを投稿するブログです。

Rails Developers Meetup 2019 Day2 参加レポート

勉強会 Ruby ポエム

Rails Developers Meetup 2019 Day2の参加レポートです。

Day1の参加レポートはこちら。 ngmt83.hatenablog.com

投稿が遅れましたが、聴講したセッションの感想を軽く述べる程度のレポートです。資料は各URLの先にリンクがあるのでそちらを参照してください。セッションの動画もアップロードされているのでよりライブ感を楽しみたい方は下のプレイリストからどうぞ。スタッフの動画班？ありがとうごじざいます。

www.youtube.com

Day2で聴講したセッションは次のとおり。

  • サービス開発初期の「時間を金で買う」技術
  • 入門 名前
  • みんながやりたがらない仕事をやって食っていく
  • モチベーションクラウド、マイクロサービス化計画
  • Ruby on Railsの正体と向き合い方
  • コードレビューしない
  • Rails 6, Progress and Maturity

サービス開発初期の「時間を金で買う」技術

https://railsdm.github.io/#session-masa-iwasaki

「エンジニアの時間は高いし、エンジニアの時給換算より安いならお金で解決すべき」というのは言葉ではわかるものの、実際に決裁権を持つ人を説得するのはなかなか難しいため、どう説得するかも実践ベースの知見があってありがたかったです。

また、採用コストとしても今時のツールを入れておいた方がいいというのは私には盲点でした。

確かに監視ツール・CIサービス・ドキュメント管理ツール・プロジェクト管理ツールなどどれが欠けても確かに不便を強いられますね。

入門 名前

https://railsdm.github.io/#session-fujimura

このぐらい名前について真剣に考えたセッションでした。哲学的な話のみでなく、実際のコード例も踏まえたいい名前・悪い名前にも言及されていて非常によかったです。

セッションとは関係ない過去のツイートですが、私が名前を大切に思っていることがわかるツイートがあったので貼っておきます。

みんながやりたがらない仕事をやって食っていく

https://railsdm.github.io/#session-idesaku

カカポがかわいいかったです。社内部活動で薄く広くリソースを確保するよりも少人数で集中的に進めるほうが費用対効果がよいというのはなるほどと感じさせられました。

また、実際に現地でプレゼンを聞いて完成するタイプのセッションでクオリティが非常に高く、満足度も高かったです。懇親会で後藤さんと話した際には「時間を割いて足を運んでもらった人に最高のセッションをしたかった」とプロ意識を感じる熱い言葉をいただきました。他にもカカポのように独自の進化を遂げた動物を筆頭にたくさんの幅広い話題をお持ちでした。

モチベーションクラウド、マイクロサービス化計画

https://railsdm.github.io/#lunch-session-linkandmotivation

泥臭く・地道にマイクロサービス化を進めている話でした。失敗も含めて発表できるところが等身大でいいと思いました。リンモチさんがもともと非WEB系で上場していた企業ということは驚きでした。

Ruby on Railsの正体と向き合い方

https://railsdm.github.io/#session-yasaichi

立ち見でしたが最高でした。言語化が上手すぎです。Rails学を語るための筆頭論文とも言うべき資料は必見です。

私は「Railsは死んだ」論に対しては「向き不向きでしょ」という立場をとるのですが、それを説明するのはあまり簡単ではありません。しかしこれからは「じゃあRailsは何に向いてるの？なんでそれに向いてるの？」と聞かれたらこれを見てくれ！と言えるようになりました。そんな決定版とも言うべきセッション・資料でした。

リスペクトの気持ちが溢れてしまったツイート

コードレビューしない

https://railsdm.github.io/#session-hanachin

攻めたタイトルですが真摯にコードレビューと向き合ったセッションでした。レビュの目的・いいレビュとは何かなど丁寧に述べられており、業務でレビュに不穏な雰囲気を感じたら思い出したいセッションでした。

Rails 6, Progress and Maturity

https://railsdm.github.io/#keynote-session-jeremy

カンファレンス2日分の疲労があったのも手伝い、英語がほとんど理解できませんでした。すごくポジティブな気持ちになってことは覚えています。Youtubeで字幕を表示して見直したいと思います。

全編を通しての所感

RailsDMをキメた

と言っても過言ではないくらいにテンションをぶち上げてくれました。平日になり、日々の業務に戻った今(3/26)もなお余韻が感じられるほどです。最高のカンファレンスをありがとうございました。

キメた感溢れるツイート

〜そして伝説へ〜

振り返りもあるよ！

rails-developers-meetup.connpass.com

Rails Developers Meetup 2019 Day1 参加レポート

勉強会 Ruby

Rails Developers Meetup 2019が始まりました。楽しみすぎて事前にブログを投稿してしまっていた*1のですが、期待通りいや期待以上にいいカンファレンスだというのが正直な感想です。

2日間開催されますが、ボリュームが半端なく、2日終わってから参加レポートを書いていてはいつ書き終わるかわからんと思ったので、ざっくりとDay1分を早速書きました。聴講したセッションに関しての簡単な感想だけです。 聴講したセッションは次のとおり。

  • "Ask Me Anything" by DHH
  • スポンサートーク
  • アプリケーションを作るときに考える25のこと
  • 少人数でサービスをすばやく開発するためのRails活用事例
  • CSSの技術的負債との向き合い方
  • 万葉のRails新人研修のコードレビューコメントを分析してみました
  • 雑
  • 7年目を迎えたRailsアプリケーションの傾向と対策
  • 毎日の開発に役立つRailsプラグインづくりの秘訣
  • まだ40代後半のプログラマの話、あるいは50代プログラマについて考える

"Ask Me Anything" by DHH

英語のセッションで英語力うんちの私にはしっかり理解はできませんでした。しかし、多くの英語できるマンがツイートしてくれていたので、それで大枠はつかめました。togetterにまとめているので気になる方はどうぞ。 togetter.com

特に印象に残ったのは「モノリスが辛いんじゃなくて、綺麗でないコードが辛いだけだ。まずは綺麗に書き直そう」(意訳)です。

スポンサートーク

Oracleさん、Reproさん、STORES.jpさん、Speeeさんスポンサーありがとうございます。感想はこんな感じです。

ツイートにはないですが、Speeeさんの代打登壇の方の次の言葉はとても印象的でした。

かっこいいエンジニアの活動を伝えたい

コードをかけない人の中でもっとも技術に貢献する人になりたい

私はこの人をかっこいい人だと思いました。

アプリケーションを作るときに考える25のこと

「価値はあるけど難しいものに取り組もう」「Railsの使いどころ」「gemを使いこなそう」「gemはこう探そう」など盛りだくさんな内容でした。gemに関しては様々なものが紹介されていました。資料が公開され次第改めて確認したいです。

「2004年から蓄積された社内記事が読めるという福利厚生があります」という発言がとくに面白く、それは実際に魅力的だし、それを断言できるだけのドキュメンテーション文化はすごいと思いました。

少人数でサービスをすばやく開発するためのRails活用事例

「エンジニアの人件費が一番高い。Paasにお金をかけてお任せする」というのはまさにその通りだと思いました。また、Angular + IonicでPWAしてるし、サーバーはRailsだし、福岡オフィスがあるし、ピクシブさんむっちゃ面白そうだ！と思いました。

CSSの技術的負債との向き合い方

まさにCSSの負債に困っていたので聴講しました。CSSもRailsなどと同様に応急処置的な施策と、根本的解決のための施策を地道にやっていくしかないんだなと思いました。チームで話し合う際にはまずみんなでこの資料を見たいです。

万葉のRails新人研修のコードレビューコメントを分析してみました

コーディングスタイルの基礎訓練、用語認識のすり合わせ、初心者の発想を広げるセルフチェック、暗黙知の価値観に基づいたレビュなど、わかりやすい良いレビュをするためのヒントをたくさんもらえました。研修プログラムの公開もそうですが、研修からのフィードバックを公開し、コミュニティに還元する万葉さんの姿勢はほんとに素晴らしいです。

雑

歴戦のエンジニアはよく直面する難しい問題に自分の回答を持っていて、すぐ答えられるのがかっこよかったです。これぞプロフェッショナル。ちなみにタイトルは雑ですが、セッションは非常にわかりやすくダークローンチしてみたいと思いました。

7年目を迎えたRailsアプリケーションの傾向と対策

レールを外れる時いかにうまく外れるかというときの具体例を提示されており、非常にわかりやすかったです。セッション中に紹介された参考記事はすべて永久保存版の素晴らしい記事なので、Railsでレールを外れる前にみておきましょう。

毎日の開発に役立つRailsプラグインづくりの秘訣

gemの名前もスライドもジョジョだらけでした。松田さんがジョジョ好きだということが言葉でなく、心で理解できました。

まだ40代後半のプログラマの話、あるいは50代プログラマについて考える

エモかったです。年齢を重ねた時の生々しいつらみを述べつつも、いかに戦っていくか(戦わないか)も複数の例で説明されてわかりやすかったです。圧倒的な実力で倒せるようになりたいです。

また、序盤に「他人の人生は参考にならない」といっていて、ちょうど先日の引退会見でイチローが話していた内容と被っていたこともあり、心に強く突き刺さりました。

あくまでも秤（はかり）は自分の中にある。

それで自分なりに秤を使いながら、自分の限界を見ながら、ちょっと超えていくを繰り返していく。

イチローの引退会見を文字起こししてみた - 俺の遺言を聴いてほしい より

最後に

Day2も楽しみです。楽しみましょう！

*1:ngmt83.hatenablog.com

Rails Developers Meetup 2019が楽しみすぎる話

Ruby ポエム 勉強会

タイトルの通りです。楽しみすぎて深夜3時までこんな記事を書いてしまうくらいです。

railsdm.github.io

ここがすごいよRails Developers Meetup 2019

国内最大のRailsのMeetupです。2日間3トラック並行での開催です。大規模で単純にすごいですね。儲かるわけでもないのにその準備・運営をやりきろうという主催者には頭が上がりません。カルパスさんありがとうございます。

KEYNOTEが豪華

"Ask Me Anything" by DHH

Rails 6, Progress and Maturity

私が語るまでもないですね、Rails生みの親であるDHH氏とRails Core TeamのJeremy Daer氏の話は楽しみで仕方ないです。DHH氏への質問はこちらへどうぞ。 railsdm.herokuapp.com

まだ40代後半のプログラマの話、あるいは50代プログラマについて考える

こちらも豪華です。高橋 征義氏は技術書典の仕掛け人でもあり、Ruby, Railsに限らず日本のエンジニアリングに貢献し続けています。*1誰も避けることのできないプログラマが歳を重ねた先を考えるというテーマも非常に気になります。エモい内容でも、現実に即した実用的なケーススタディでもいずれにしても今後のキャリアの参考になりそうです。

余談ですが、Ruby歴20年以上の人ってどれくらいいるんでしょうか・・・

Ruby歴約20年のRubyist

参加者の熱も強い

techplay.jp 上記リンクで確認できますが、参加費がかかります。そして2日間のうち1日は平日です。参加したいという強い意欲がなければ参加できません。にもかかわらずチケットはすぐに売り切れました。*2

カンファレンス会場で生じる交流も非常に価値のあるものとなるでしょう。

ngmtが特に気になっているセッション

  • 少人数でサービスをすばやく開発するためのRails活用事例
  • 万葉のRails新人研修のコードレビューコメントを分析してみました
  • 7年目を迎えたRailsアプリケーションの傾向と対策
  • サービス開発初期の「時間を金で買う」技術
  • 入門 名前
  • Ruby on Railsの正体と向き合い方
  • コードレビューしない
  • 自分たちを信じられるチームが作りたくて私はこうした

直感的なものもありますが、振り返るときの備忘録としてなぜ気になっているか記しておきます。

少人数でサービスをすばやく開発するためのRails活用事例

詳細は公式サイト参照

Railsは少人数で素早く開発するためのフレームワークだと私は考えています。そのRailsにとっての王道とも言えるチーム構成で、いかに素早さを突き詰めていったか非常に気になります。今話題(当社比)のピクシブ株式会社の方の発表ということもあります。

万葉のRails新人研修のコードレビューコメントを分析してみました

詳細は公式サイト参照

私は教えるのが好きで、これまでも10人程度インターンをみてきました。しかしまだまだ難しいと感じているため、研修や育てる体制が充実していると噂の株式会社万葉さんのお話を聞けるのは非常に楽しみです。

7年目を迎えたRailsアプリケーションの傾向と対策

詳細は公式サイト参照

私は次の記事が非常に好きで、何度となく参考にさせてもらいました。 tech.kitchhike.com この記事を書いた株式会社キッチハイク 小川 剛さんのトークに興味があります。

余談ですがキッチハイクというサービスは創業者の原体験がよく現れていてエモくて好きです。

サービス開発初期の「時間を金で買う」技術

詳細は公式サイト参照

そもそもRailsはサービス開発初期の時間を削減するために選定するものだと思っています。「時間を金で買う」というのは、時間を大切に捉えるRailsの方針と合致しています。どこにお金をかけるとどこの時間を抑えることができるのか、非常に気になります。

入門 名前

詳細は公式サイト参照

命名は非常に重要だと考えています。煽り気味の新書タイトル風に言うと「プログラミングは命名が9割」です。名著リーダブルコードも命名が大事ってことが全編を通して書いてありました。コードレビュでも命名は頻繁に議論されます。そんな命名に関して整理したというセッションは期待せざるを得ません。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

Ruby on Railsの正体と向き合い方

詳細は公式サイト参照

期待するしかないよなあ！

コードレビューしない

詳細は公式サイト参照

タイトルに釣られました。このセッションを聞けば今後のコードレビューがより有意義なものになるのではないかと思っています。

自分たちを信じられるチームが作りたくて私はこうした

詳細は公式サイト参照

私はいかに信頼を勝ち取るか、いかに周りを信頼するかを自分の課題だと思っています。そのためにリーダーとして実際に行動した話には非常に興味があります。

最後に

聞きたいセッションが並行トラックで被っているものもあり、すべて聞くことは難しいと思いますが、聞いたものはしっかりブログにアウトプットしていきたいと思っています。また、他の参加者がどのように感じたか、聞けなかったセッションはどんなだったかも非常に気になるので、参加者はぜひ参加レポート書いてください！

私はあなたの参加レポートを待っています。

*1:技術書典6も楽しみです、運営ありがとうございます

*2:私は有給休暇で自腹で行きます。

通勤時間ながらUdemyのすヽめ

ポエム

2019年1月に初めてUdemyのコースを購入し、勉強に取り入れました。最近になってようやくコンスタントに進める方法を見つけたので紹介します。

その方法は「通勤時間ながらUdemy」です。

通勤時間ながらUdemy概要

  • コースをWiFi環境でダウンロードしておく
  • 通勤中聞く
  • わかっている箇所は飛ばしたり、ブラウジングなど休憩をする
  • わからない箇所はブックマークをつける

ポッドキャスト感覚で使用することを推奨します。また、Udemyは動画にブックマークとコメントを残すことができます。ただ聞き流すだけでは身につかない or わからない箇所はブックマークをつけ、あとで手を動かしながら復習しましょう。

メリット

  • 聞くだけでもよく、通勤中でも取り組みやすい
  • Udemyのコースは体系的にまとめられていることが多いため、知識の抜け漏れを見つけやすい
  • コースの聴講はどんどん進むため、学習の進捗を出しやすく、達成感を得やすい
  • 英語のコースを聴講すると英語学習もできる
  • 講師の話すスピードや理解度に合わせて倍速再生ができる
  • 動画を事前にダウンロードすることで通勤時間格安simの通信低速問題が気にならなくなる

向いている学習テーマ

かじった程度の知識・経験を持つフレームワークや言語は通勤時間ながらUdemyで学ぶのにとても向いています。*1逆に全く知らない領域は向いていません。理解に時間がかかり、動画をいちいち停止させたり、わかった気になってしまうだけだったりするためです。

例えば、私は業務でAngularを利用したWEBアプリ開発をしています。ただし、体系的に一通り学習を終えたわけではなく、既存のコードを参考にしつつその時々で検索して覚えています。必要になった時に必要な勉強をすることは悪いことではないですが、既存のコードに引っ張られすぎたり、便利な機能やベストプラクティスを知らないために回りくどい実装をしたことがありました。特にどこがわからないのかわからない状況になってしまうと、手をつけることができなくなってしまいます。そこでUdemyのコースを最初から最後までざっと通して聞くことで、自分に自信のない箇所をあぶりだすことができました。

最後に

積ん読はページめくりなど能動的に取り組まなければ進みませんが、動画教材は再生ボタンを押した後はほぼ何もしなくても進んでいくのでどんどん勉強していきましょう。

そういえばちょうど今セールやっているので買い時ですよ！Udemyコース購入駆動学習しましょう！ www.udemy.com

*1:似ているものも良さげ。Railsできる人がLaravelを学ぶなど

「マンガでやさしくわかるアンガーマネジメント」を読みました

本

感情的になることと、感情を伝えることはイコールではありません。

私が「マンガでやさしくわかるアンガーマネジメント」から得た最も重要なセンテンスです。

マンガでやさしくわかるアンガーマネジメント

マンガでやさしくわかるアンガーマネジメント

本書を読んだ経緯

本書はマンガでわかる〜シリーズがセールだったときにたくさん衝動買いしたうちの1冊です。しばらくは積ん読状態でした。

読み始めたきっかけは次の記事です。 kdnakt.hatenablog.com この記事がアンガーマネジメントを簡単にでもすぐに学んだ方がいいと私に思わせてくれました。

概要

タイトルから察する通り、怒りという感情とうまく付き合うためのノウハウやトレーニングをマンガ付きで説明するという内容になっています。小難しい専門的な話を詳細に説明するのではなく、ノウハウやTipsを明日から活かせるように噛み砕いて解説しています。文量は少なく、速読でなくとも2, 3時間で読めてしまうでしょう。これはよくまとまっているということであり、長所です。

早速活かしたいノウハウとTips

一部抜粋して紹介します。

怒りのピーク6秒をやり過ごすテクニック

怒りの現場から席を外し頭を冷やすというタイムアウト。深い腹式呼吸を意識する呼吸リラグゼーション。これらは場所を選ばずシンプルで実行しやすく、実際にやってみても効果的でした。アンガーマネジメントという言葉を知らなくてもやってる人はいると思います。

アンガーログ

どういう時に怒りを感じているのかを自覚するために怒りを感じた時に何を思ったかを記録します。実際にやってみると、怒っているときに自分は怒っていると冷静になれるところも良いです。

「べき」ログ

怒りの元を知るための「べき」を記録します。私の簡単な例としては「電車では降車が終わる前に乗り込むべきではない」という「べき」が記録されました。やり始めると、守って当然のマナーをたくさんの「べき」として記録することになりました。しかし、どれも自分が変えることのできない他人のマナー違反であり、それを怒って気分を悪くするのは生産的ではないと再認識できました。

特に響いた表現と所感

がまんではなく、〝見極めた〟と考える

怒ってもいいことを我慢してやった。自分ばかり我慢している。と溜め込んでしまうことがあります。これからはそうではなく、「怒っても事態は好転しないと見極め、怒らないことを選択した」と考えるようにしたいです。

相手を打ち負かそうとせず、わかってもらうことをゴールにする

論理的に正しいことを言い、相手を論破してしまうことがあります。打ち負かそうとした場合、論破できなければそもそも怒りは治りませんし、論破できてもわかってもらえるわけではないため、事あるごとに衝突してしまうでしょう。名著「人を動かす」*1でも「議論に勝つ最善の方法は議論を避ける事だ」といった主旨のことが書いてありましたし、論破に意味はないことを再度心に刻みました。

最後に

感情に流されず、怒りと上手に付き合えれば色んなことが少しずつやりやすくなると思います。本書には紹介したもの以外にも明日から試せる簡単なノウハウ・Tipsがたくさん詰まっています。怒りっぽかったり、溜め込んでしまう人にはおすすめです。さっと読めてしまう文量でもあるので、騙されたと思ってどうぞ。

マンガでやさしくわかるアンガーマネジメント

マンガでやさしくわかるアンガーマネジメント

*1:

人を動かす 文庫版

人を動かす 文庫版

エンジニアなので家系図をGitHub上にYAML形式で管理する

ポエム

あなたは親戚の名前や兄妹の人数など覚えているでしょうか？私は覚えられません。まして結婚して親戚の数が倍になると言うまでもないです。また、先日の母とこのような会話をしました。

母「aさん(私の嫁の叔母)って　bさん(私の嫁の父)の姉なの？妹なの？」

私「aさんはbさんの姉だよ。」

私は思いました。

これ前も聞かれなかったか？

というか、誰かが結婚する度に親戚が増えるわけだから覚えられるわけなくね？

ということで情報共有とその可視化に取り組むことにしました。

技術選定

  • 管理・更新が容易(テキストベース)
  • 図を自動生成できる

上記の条件を満たすOSSがありました。*1 github.com

kingraphとは

家系図をJavaScriptとGraphvizで作図するツールです。インストール方法などはREADMEをみましょう。

以下ではドラゴンボールの家系図を例に書き方を軽く説明します。

例: ドラゴンボールの孫悟空周りの家系図

https://github.com/nagamoto/db-family-tree/blob/master/son.png?raw=true

※牛魔王やサタンの妻はわからないのでとりあえず”牛魔王の妻”・”サタンの妻”としています

YAMLファイルの書き方

ソース: db-family-tree/son.yml at master · nagamoto/db-family-tree · GitHub

親子は次のように定義できます。簡単ですね。

parents: [悟空, チチ]
children: [悟飯, 悟天]

それぞれの人の詳細を設定することもできます。今回は兄弟の生まれた順番を図に表現するために、fullnameというプロパティを本来とは違う用途で利用しています。また、後述するスタイリングのためにclassにmaleを指定しています。

people:
  ラディッツ:
    fullname: 第一子
    class: [male]
  悟空:
    fullname: 第二子
    class: [male]

図に細かなスタイリングを施すこともできます。今回は男性であれば枠が青、女性であれば枠が赤となるように設定しました。

styles:
  male:
    color: blue
  female:
    color: red

保守運用

誰かが結婚したり、子供が生まれたりしたときにはPullRequestを投げてもらいます。*2これでエンジニアらしく、常に最新の家系図が作成されます。

最後に

マジレスをすると、そもそも結婚や出産はそう頻繁に起こることではないので、これはやりすぎです。 また、「親族にエンジニアはそう何人もいない」=「メンテナが少ない」となるため、特定の少数メンバのみが更新するというつらい運用になるでしょう。

*1:最初はPlantUMLでクラス図の記法で家系図を書こうとしていましたが、兄妹をうまく表現できず諦めました

*2:太郎くんが生まれた際に作られるブランチはdeploy-taroでしょうか

最も汎用的なパターン「完全コンストラクタ(Complete Constructor)パターン」の紹介

技術 Ruby

好きなパターンはなんですか？と聞かれたら私が真っ先に答えるのは「完全コンストラクタ(Complete Constructor)パターン」です。汎用的かつ効果的なパターンなので、多くの人に知ってもらいたくて記事を書きました。

「完全コンストラクタ(Complete Constructor)パターン」とは？

コンストラクタですべてのプロパティ(メンバ変数)を設定し終える(完全な状態)を作るパターンです。setterは作らず、プロパティがコンストラクタの実行後に変わることはありません。

簡単な例

四則演算を行うCalculatorClassをRubyで書くと次のようになります。*1プロパティをinitilizeで設定した後は一切変更していません。

class Calculator
  attr_reader :operand1, :operand2

  def initialize(operand1:, operand2:)
    @operand1 = operand1; @operand2 = operand2
  end

  def sum
    operand1 + operand2
  end

  def difference
    operand1 - operand2
  end

  def product
    operand1 * operand2
  end

  def quotient
    operand1 / operand2
  end
end

※attr_readerはgetterメソッドのようなものをまとめて定義してくれると思ってください。詳しくはこちら

長所

  • 可読性が高まる
  • 単一責任原則(SRP)を守りやすい

可読性が高まる理由

完全コンストラクタに則ったクラスはその性質上、IF(インターフェース)がシンプルになりクラス内の見通しがよくなります。また、クラスを呼び出す側においても、プロパティをまとめて入力してインスタンス化し、目的のメソッドを実行するというシンプルな流れになります。そこかしこでsetterが呼ばれ、状態が変わることがないため非常に見通しがよくなります。

ccc = CompleteConstructorClass.new(x, y, z) 
ccc.do

単一責任原則(SRP)を守りやすい理由

操作に必要なプロパティすべてをまとめて入力するため、多種多様な責務をクラスに持たせることが難しいです。*2また、インスタンス化後にプロパティを変更できないため、メソッド実行結果は(基本的に)同じ結果を返します。そのためメソッド実行後にインスタンスを使い捨てることが多く、使い回して多数の責務を持つような実装にはしづらくなります。一度インスタンス化してしまえば、メソッド実行結果は同じものを返すため、テストも非常に行いやすいです。

具体例: Finderパターンを完全コンストラクタで実装

Railsで構築されたあるSNSアプリで、ユーザは氏名・生年月日・性別・出生都道府県・現住都道府県のような情報を持つ。そのアプリでユーザを複雑な条件で絞り込みたいときに(Finderパターン)を使うとして、それを完全コンストラクタで実装します。

class UserFinder
  attr_reader :gender, :age, :today, :born_in_prefecture, :living_in_prefecture

  def initialize(gender: nil, age: nil, born_in_prefecture: nil, living_in_prefecture: nil)
    @gender = gender; @age = age; @today = Date.current
    @born_in_prefecture = born_in_prefecture; @living_in_prefecture = living_in_prefecture
  end

  def find
    query = User.all
    query = query.where(gender: gender) if gender
    query = query.where(born_in_prefecture: born_in_prefecture) if born_in_prefecture
    query = query.where(born_in_prefecture: living_in_prefecture) if living_in_prefecture
    query = query.where(birth_day: period_covered) if age

    return query
  end

  private

    def period_covered
      from_date = today - (age + 1).year + 1.day
      to_date = today - age
      from_date..to_date
    end
end

このように検索の実装部分が多少複雑でも、利用時は次のとおりで「大阪生まれで今東京に住んでいる20才」を検索するということが一目瞭然になります。

result = UserFinder.new(age: 20, born_in_prefecture: "大阪", living_in_prefecture: "東京").find

Finderパターン以外にのデザインパターンとも相性がよく組み合わせて使用することでよりよい設計ができるようになります。

総括

「完全コンストラクタ(Complete Constructor)パターン」はシンプルなパターンで覚えやすいのに、汎用的かつ効果的なのでぜひ利用してください！

おまけ: デザインパターンに関する参考資料

オブジェクト指向における再利用のためのデザインパターン

オブジェクト指向における再利用のためのデザインパターン

www.techscore.com masato-hi.hatenablog.jp

*1:Mathモジュール使えとか野暮なことは言わないでください

*2:多種多様な責務を果たすにはインスタンス化する際に大量のプロパティをまとめて入力しなければならないため