page icon

山田 昌弘

自己紹介

共同創業者&エンジニアの山田です。やまでぃって呼ばれてます。
自分の手で自由な発想でものを作るのが好きです。B型っぽい性格です。
 
趣味タグ: #サウナ #ポーカー #ソフトテニス #サイクリング

キャリアサマリー

情報系の大学・大学院を卒業した後、新卒で株式会社ディー・エヌ・エーに入社。サーバーサイドエンジニアを6年。ガラケーのソーシャルゲームや内外向けにmBaaSを作っていました。
その後、2018年3月頃からYOUTRUSTにジョインして今日までずっと開発周りを担っています。

YOUTRUSTの好きなところ

強くて優しい人達が集まり、社内外問わず皆に愛されている所。

記事

  • Meetup イベントレポート
  • Tech Blog: サービス成長に耐えうるリスト取得ロジックについて考える
  • Tech Blog: Rails on YOUTRUST <ロジックどこ置く?編>
Rails on YOUTRUST <ロジックどこ置く?編> - YOUTRUST Tech Blog
こんにちは、YOUTRUSTのやまでぃ( YOUTRUST/ Twitter )です。 前回の記事 より約4ヶ月振りの登場です。 前回の記事ではたくさんの反響ありがとうございました。まだ未読の方は是非読んでみてください。(スケーラブルなリスティングロジックについてです) 今 ONE PIECEの連載が最終章に突入して熱いとの噂をキャッチし、8月に入ってから漫画を最初から全巻読み直しています。 僕のマイサウナである 国立温泉 湯楽の里 に全巻置いてあり、毎回1000円弱でサウナに水風呂に漫画まで読めて最高です。深夜1時まで営業しており、最近土日の大半はここにいます。(何なら平日も昼間からいるときも?) Rails のロジックのクラス分けについて書きます。 弊社では キャリアSNSとHR SaaSの2つのプロダクトを提供しており、共にサーバーサイドは Ruby on Rails にて開発・運用しております。 今なお根強い人気の Ruby on Railsは、そのお作法に乗る(on Rails)ことにより、特に初期の段階では素晴らしい生産性を生み出してくれる フルスタ ックWebフレームワークですが、何も考えずにサービスの運用を続けていると段々辛くなってきます。 そう、 Fat Model(Controller)問題 ですね! 想定外の仕様変更や度重なる機能追加や試行錯誤のためのロジックを、目の前にあるModelやControllerに「後で直す...後で直す...」とつぶやきながら継ぎ足していった結果生まれてしまう、密結合で見通しが悪くテストも書きづらい悲しき スパゲッティコード 。 どうしてこうなったのか分からないまま、取り敢えず精神削って頑張って読み込んで変更してみたものの、これで良いのかイマイチ安心できない、本番に反映しても大丈夫なものだろうか?もしバグが起きてしまっていたら?未来の仲間に申し訳ない等と不安で眠れない夜もあったのではないでしょうか。 そんな経験ありませんか? 僕はあります。 そこで、今回の記事ではYOUTRUSTにおける Rails の使い方<ロジックどこ置く?編>をご紹介します。 もし「そんなことは無い」というスーパーなエンジニアの方でしたら、もうこの記事の続きは読まなくて大丈夫なので、 こちら に進んでください。 YOUTRUSTではロジックを下記のように用途別にクラスを分けています。(2022年9月現在) 初期の段階 最近のYOUTRUST 更新系ロジック→Command (app/commands/) 参照系ロジック→Query (app/queries/) 通知系ロジック→Model (app/models/notifications/) ロジックを組み合わせるもの→UseCase (app/use_cases/) ここですべてを悟ったスーパーなエンジニアの方も続きを読まなくて大丈夫なので、 こちら にお進みください。 サービスのリリースは2018年4月 20日 。運用歴4年と4ヶ月以上になります。 各 ディレクト リ内のクラス数(2022年9月現在)は以下の通りです。 ※まだControllerやModelがFatになっている箇所があり、完全にCommandやUseCase層に移行しきっている訳ではありません。 YOUTRUSTではロジックを用途別に下記のように分類して、 ディレクト リを分けて管理しています(再掲) 更新系ロジック→Command (app/commands/) 参照系ロジック→Query (app/queries/) 通知系ロジック→Model (app/models/notifications/)弊サービスにおいて通知は重大な関心事なので app/notifications/ に移行することを検討していたりします。 ロジックを組み合わせるもの→UseCase (app/use_cases/) それぞれの層の依存関係としては下記の通りです。 Controller→UseCase、Query、Command ...
  • 代表岩崎とのインタビュー記事