Upgrade to Pro — share decks privately, control downloads, hide ads and more …

"hey Talk" Engineers #1 STORES 予約 を支える技術

"hey Talk" Engineers #1 STORES 予約 を支える技術

E83cdc415df47ab3eae30957ae7e2d33?s=128

Yukito Ito

April 08, 2021
Tweet

Transcript

  1. STORES 予約 を支える技術 ykpythemind 2021/04/08

  2. 自己紹介

  3. ykpythemind / 伊藤薫人 スタートアップの開発責任者などを経て,2020年 1月にクービック株式会社に入社 heyに吸収され、今に至る - Ruby - TypeScript

    - Go @ykpythemind @ykpythemind
  4. 話すこと

  5. - 技術スタック - 予約開発チーム - 実際の開発風景 見せます - チャレンジングな試み

  6. 技術スタック

  7. 主な2つを紹介

  8. None
  9. サーバサイドはほぼほぼRuby on Rails ☀ 鉄板 ☀ 触ったことある人が一定数存在 ☀ なんだかんだ考えることが限定される感。 ☔

    覚えることは多い ☔ viewとの密結合が辛く、徐々にAPI化が進み、フロントエンドはNext.js (react)に 分離の方向へに進んでいる ☔ TypeScript/Reactなどと比べたときの開発体験の悪さ
  10. None
  11. エンドユーザー側の予約フロー / 新しいオーナー管理画面(開発中)で使用 ☀ 覚えることが少ない ☀ 各種最適化 - 開発環境での開発体験の良さ (zero

    config) - 何もしなくても何かパフォーマンスが良い ☔ Vercelに載せないと真価発揮しない感 (SSG/ISR) - なおSTORES 予約 ではいくつかの事情でVercelでのホスティングを断念
  12. その他

  13. 比較的枯れた技術を愚直に使用

  14. 予約開発チーム

  15. イメージ図

  16. heyの中では比較的やんちゃな開発チーム - もともとあまりRubyの経験者いなかった! - TypeScript, Scala, Perl, Go … -

    良くも悪くも「Rubyにそこまで思い入れがない」 - 各人が別々の方向を向いている独立部隊..... - だったのが、徐々に開発のテンポを掴みだしてチーム開発が加速している!
  17. 技術者として、言語やフレームワークを超えても適用 できる考え方を大事に - シンプルに書く - SOLID原則 - データベース設計 - http

    - Web標準 etc...
  18. 本質に向き合うチーム、楽しい!

  19. 実際の開発風景 見せます

  20. 予約枠の空きロジックの計算の改善

  21. 実際の予約受付画面 マルバツパネル ≒ 予約枠

  22. 🤔 その日の営業時間設定が短い すでに予約がある 予約をブロック する時間設定 メニューの所要時間で 色々変わる - 対応できるスタッフが 働いている時間か

    - 受付締め切り設定 - 設備を使える時間か etc… 30分ごとに 受け付ける設定 他
  23. 予約枠の空きロジックの計算の改善 - 古くからあるロジックで秘伝のタレ化 - 再利用性がなく、散らばっている - 最古参の @song だけが知っているロジック

  24. esaの同時編集機能で設計議論 ペアプロ / モブプロ Pull Requestで議論 / Patchの送り合い ※ 一例。Pull

    Requestだけで終わることも多い。難しいタスクはなるべく1人で悩まないよう進める
  25. 三種の神器

  26. None
  27. アイデアを持ち寄る ※ こちらのスライド資料は後ほど公開します。雰囲気 だけお楽しみください。

  28. 🥺

  29. 考えすぎない とりあえず実装してみないと分からない

  30. esa同時編集機能 + Google Meets 同時編集できれば任意のツールでOK

  31. VS Code + Live share

  32. 予約変更時には変更対象の予約を除いて取得 する必要があるから引数で渡すかー? 変数名直すわ executeって命名かcallっ て命名どっちがええの? Courseの情報から計算できるか ら引数はこれで良さそう! 時間内にあれこれ話してコードを書いていく

  33. None
  34. Pull Requestはすごい!

  35. とりあえずPull Requestの形にする - どんどん master/main ブランチに取り込んでいくスタイル - まだ使用しないコードだったら比較的ラクに入れていける - レビューで白熱したら....

    - バグっていなければ、一旦マージし提案/修正したい人は別Pull Requestを投げる - 結局コード書いていかないと分からないことが多い
  36. 歴史的経緯の話だったり、テスト手法のテクニカルな話だったり。

  37. 開発が楽しい!

  38. チャレンジングな試み

  39. Prettier for Rubyの導入

  40. https://github.com/prettier/plugin-ruby

  41. prettier - インデント等の細かい争いをなくすので好き - ruby-pluginを試してみたら完成度高かった - 他の言語の良い仕組みを取り入れたかった 当時(2020/11) は スター数100程度のプロジェクト

  42. コーディングが楽になった rubocopの Layout copをすべてoffにできた

  43. バグ見つけてPR出せた

  44. チャレンジングな試み - 技術やツール、良さそうなものは試しに入れてみる - どんどんやってください - うまく行かないものは反省して捨てる

  45. チャレンジもでき、楽しい!

  46. 俺たちなりのfun を持って開発していきます

  47. None