2019_10_30_classi_redesign.pdf

 2019_10_30_classi_redesign.pdf

2019/10/30 Rails meetupでの発表資料です

F2fd90f28907a60a863c5e9375392a89?s=128

Nakamura shinichirou

October 30, 2019
Tweet

Transcript

  1. 1.

    Copyright © 2018 Classi Corp. All Rights Reserved. Classiでの リプレースプロジェクト奮

    闘の記録 Copyright © 2018 Classi Corp. All Rights Reserved. プロダクト部 中村真一郎
  2. 3.

    Copyright © 2018 Classi Corp. All Rights Reserved. • 中村真一郎

    • Twitter、github: nakaearth • 2016年6月からClassiで業務委託で働いていた が、今年7月からClassi正社員に • 職歴 • sIer: 8年 • BtoCやBtoBのサービスやっている会社に11年近く • 現在は • Classiで、サーバサイドエンジニアとして働いています • 検索機能の作成やリプレースプロジェクトで主にサーバ サイドを担当 2 自己紹介
  3. 5.

    Copyright © 2018 Classi Corp. All Rights Reserved. • 実は10月中旬頃に体調崩して2週間入院して

    いました。 • 2週間ほぼ寝たきりで、今週月曜日に会社復 帰しました • 健康って本当大事です • 皆様も健康第一で! 4 自己紹介
  4. 6.

    Copyright © 2018 Classi Corp. All Rights Reserved. • この入院で得られた成果としては、

    • 採血と称してあらゆるところに針が刺さったお陰で採血 に対する恐怖感がなくなりました • 最初の5日間ほぼ水分だけの生活だったので痩せました • 点滴。あまり動くと漏れて腫れ上がること、体験しまし た • 点滴漏れして腕に再度点滴針刺す or 採血するのは難し い。看護師さんに採血難しい人ベスト3に入ると賞賛(?) されました 5 自己紹介
  5. 8.

    Copyright © 2018 Classi Corp. All Rights Reserved. • 学校の先生、生徒、保護者向けにサービスを

    提供(主に高校) • 日本全国の高校の50%以上に導入 7 会社紹介
  6. 10.

    Copyright © 2018 Classi Corp. All Rights Reserved. • Classiには複数の機能があるが、クラス構成がバラバラ。

    • 開発担当者が内部で開発していたり外部にお願いしたりと機能毎で違うため統 一感がない • フロントのフレームワークが機能毎でバラバラ • AngularやReactなど 9 何故リプレース
  7. 11.

    Copyright © 2018 Classi Corp. All Rights Reserved. • Rails/Rubyアップデートが難しい

    • 依存しているgemの影響でアップデートするのが難しい • テストがない • セキュリティ的に良くない • リポジトリの分け方が適切でない。 • マイクロサービスになりきってない。先ずはモノリシックにしていく 10 何故リプレース
  8. 12.

    Copyright © 2018 Classi Corp. All Rights Reserved. • 先人達のコードに敬意を払いつつも、今後のためにもコードの

    整理、gemの整理、フロントフレームワークの統一が必要 • まずはサイズ的にも大きすぎない機能「学習記録」からやって みようということで2018年7月からスタート(開発がスタートし たのは9月頃から) 11 何故リプレース
  9. 14.

    Copyright © 2018 Classi Corp. All Rights Reserved. • 前提

    • フロント側(Angular)で実装。 • サーバ側はRailsでAPIモード • テストコードの整備やlintの設定でコードの品質を保つ • 今後の機能追加がしやすいように実装していく • 既存の仕様を踏襲する 13 当初
  10. 15.

    Copyright © 2018 Classi Corp. All Rights Reserved. • 大まかな流れ

    14 当初 足回り・基盤整備・共通コンポーネント作成など 学習記録トップ画面API実装 学習記録トップ画 面API実装 仕様調査・進め方の検討
  11. 16.

    Copyright © 2018 Classi Corp. All Rights Reserved. APIサーバ •

    Controllerは薄く • 処理の結果のハンドリング、エラーハンドリング。ロジックは書かない • 処理のロジックはserviceクラスで • バリデーションはformで • 同じレスポンス返す処理が多かったので、そういう箇所は共通 のAPIで 15 当初 Controller Form Service 共通化
  12. 18.

    Copyright © 2018 Classi Corp. All Rights Reserved. 問題1 •

    既存に合わせる、仕様が複雑ということも影響しserviceクラス の複雑度が上がりコードの可読性が悪くなった。 • カテゴリ毎(クラス別・学年別・部活動別)日付毎(日、 週、月、期間)の学習時間集計APIを共通化 • レスポンスは一緒だが、処理内容が微妙に違うため 分岐が多くなる 17 当初
  13. 19.

    Copyright © 2018 Classi Corp. All Rights Reserved. 問題2 •

    完了しているのか不明確 • フロントとサーバ結合した時に問題が分かることが 多かった • 終わっているようで終わってない! 18 当初
  14. 20.

    Copyright © 2018 Classi Corp. All Rights Reserved. • 問題1は実装の課題

    • 問題2は開発プロセスの課題 19 当初
  15. 22.

    Copyright © 2018 Classi Corp. All Rights Reserved. • 大まかな流れ

    21 当初 学習記録詳細 未入力者一覧 不具合対応 全体的に見直し 未入力者一覧 生徒一覧一覧 UT
  16. 23.

    Copyright © 2018 Classi Corp. All Rights Reserved. APIサーバ •

    Controllerは薄く • 処理の結果のハンドリング、エラーハンドリング。ロジックは書かない • 読み込み処理はQueryで • 書き込み処理はusecaseで • 外部に関わる処理はinfrastructureで • バリデーションはformで • 共通化していた処理をバラす 22 現在
  17. 24.

    Copyright © 2018 Classi Corp. All Rights Reserved. • Serviceクラスでカテゴリ毎・日付毎に共通化していた箇所を解体

    • カテゴリ毎に分ける(クラス、学年、部活動) • 日付指定毎(日毎、週毎、月ごと、期間指定)に分ける • 不適切な共通化は逆に複雑度を増してしまう 23 現在 SummaryService GradeHogeSummaryQuery ClassroomHogeSummaryQuery ClassroomHogeSummaryQuery ClassroomHogeSummaryQuery ClassroomSummaryQuery GradeHogeSummaryQuery GradeHogeSummaryQuery GradeSummaryQuery
  18. 25.

    Copyright © 2018 Classi Corp. All Rights Reserved. • Serviceクラスの責務が大きくなっているので、責務を小さくす

    る • よく言えばオールマイティ。悪く言えば何でも屋になっているのを見直す。 • 集計処理などのRead処理はQueryで、登録・更新処理などの Write処理はUsecaseで行うように分割 24 現在 SummaryService CreateReportUsecase ClassroomSummaryQuery CreateReportService
  19. 26.

    Copyright © 2018 Classi Corp. All Rights Reserved. l 一つ一つのクラスの見通しが良くなった

    l どこに書くがより明確になった l テストが書きやすくなった l 共通化することで良い場合もあるが、後々複雑度を増すことも あり得る。 25 現在
  20. 27.

    Copyright © 2018 Classi Corp. All Rights Reserved. 開発プロセス l

    1週間か2週間のスプリント • スプリントに納まる範囲で機能開発 • フロント、サーバ関係なく皆で一つの機能を開発 • 最近フロントのコードも書いてます • スプリントの最後にレビューして、テスト環境で動くことを皆 んなで確認。 • 完了しているかどうか明確になる • スプリント毎に振り返りを行い、気になる点は改善する • 最近はモブプロも導入 26 現在
  21. 29.

    Copyright © 2018 Classi Corp. All Rights Reserved. l リポジトリを触る人が増えてきているので、統一感がある程度

    保たれるようにしていかなければならない l モノリシックにしていくので、機能が増える毎にビルド&ディ プロイに時間がかかる l リプレースはまだ1機能目。残りの機能を如何に効率よく進め るか 28 課題