失敗から学ぶGoプロジェクト~Template Repository~

Transcript

1. 失敗から学ぶGoプロジェクト ~Template Repository~ 平野 元気
2. Agenda 1. 自己紹介 2. もくもく会で作業した内容 3. なぜ、Template Repositoryを作ることにしたのか 4. プロジェクトの前提 5. チームで踏んだ失敗と改善策 6. まとめ
3. 自己紹介 - 名前 - 平野 元気 - どんなエンジニア？ - バックエンドを担当しています - Go言語を書くことが多いです - 設計も好きです - 一言 - ざっくばらんにお話ししましょう！
4. Agenda 1. 自己紹介 2. もくもく会で作業した内容 3. なぜ、Template Repositoryを作ることにしたのか 4. プロジェクトの前提 5. チームで踏んだ失敗と改善策 6. まとめ
5. もくもく会で作業した内容 - Go・gRPC・Clean Architecture・DDDを前提としたGitHub Template Repositoryを作成中
6. GitHub Template Repositoryとは？ - 新規リポジトリを作成するときに、既存リポジトリを初期設定できる - カスタムエラーやログ周りを事前に実装しておき、開発効率を向上させることが狙い - 0→1の開発が多いときに便利 - テンプレートリポジトリを作成する - https://docs.github.com/ja/repositories/creating-and-managing-repositories/creating-a-template-repository
7. Agenda 1. 自己紹介 2. もくもく会で作業した内容 3. なぜ、Template Repositoryを作ることにしたのか 4. プロジェクトの前提 5. チームで踏んだ失敗と改善策 6. まとめ
8. なぜ、Template Repositoryを作ることにしたのか - 0→1の開発が多く、開発効率を向上させるため - カスタムエラーやログ周りは開発がある程度進んだときに改修すると、工数が非常にかかってしまうの で、初期段階で綺麗に作っておきたい - 過去プロジェクトの失敗を繰り返さないため
9. Agenda 1. 自己紹介 2. もくもく会で作業した内容 3. なぜ、Template Repositoryを作ることにしたのか 4. プロジェクトの前提 5. チームで踏んだ失敗と改善策 6. まとめ
10. プロジェクトの前提 - Go言語 - クリーンアーキテクチャ - DDD - バックエンドメンバーが計13人、2チーム - 仕様が固まっていない&短納期でなし崩し的に開発がスタートしてしまった
11. Agenda 1. 自己紹介 2. もくもく会で作業した内容 3. なぜ、Template Repositoryを作ることにしたのか 4. プロジェクトの前提 5. チームで踏んだ失敗と改善策 6. まとめ
12. 1. ドメインモデル貧血症 - ドメインのビジネスロジックが他のレイヤー (ユースケース, プレゼンター等) に漏れてしまう - ユースケースに漏れることが多い - ユースケースにロジックや分岐が多い場合は、ビジネスロジックが漏れ出してる可能性大
13. 問題点 - ロジックの重複が起こる - 同じロジックがユースケースやコントローラーに散らばる - 仕様変更の際に、修正漏れが発生する可能性が上がる - テストが複雑になる - ビジネスロジックがユースケースに漏れた場合、ビジネスロジックのユニットテストが辛くなる - ユースケースはインテグレーションテストで書くため - 可読性の低下 - 各ドメインのビジネスロジックが把握しにくくなる
14. 対応策 - ビジネスロジックをドメインレイヤーに閉じ込める - ドメインモデルの各フィールドはプライベートにする - 各フィールドを参照する際は getterメソッド、値を更新する時は setterメソッドを使用する - 注意点として、setterメソッドは脳死で全フィールドに生やさず、ビジネスロジックを表現するため実装する - setterメソッドを全フィールドに実装すると、実質パブリックと変わらなくなってしまう ...
15. 2. 汎用的な値の重複 - 各ドメインモデル内で下記フィールドの重複が発生した - 名前 (苗字、名前、苗字カナ、名前カナ ) - メールアドレス - 住所 - 電話番号 - 生年月日 (年齢)
16. 問題点 - 同じor似たようなロジックが各ドメインモデルに散らばってしまう - 名前の文字列のバリデーションが、ユーザと管理画面ユーザに散らばる - 冗長なコードになる
17. 対応策 - 汎用的な値オブジェクトを初期に定義して、各ドメインモデルで使い回す - 名前 (苗字、名前、苗字カナ、名前カナ ) - メールアドレス - 住所 - 電話番号 - 生年月日 (年齢) - バリデーション、コンストラクタ、 getter、setter、testを実装しておく
18. 3. カスタムエラーの機能が足りていない - 既存の実装はStandard error model (codeとmessageのみ返す) で実装していた - プロジェクトの要件として、ユーザー登録の際に複数エラー (名前、住所、メールアドレスのバリデーション 等)を返したい場合、対応できない
19. 問題点 - 急ぎで実装したが、チーム人数が多くバッティングする &納期も短いので、満足いく実装にならなかった
20. 改善策 - Template Repositoryのカスタムエラーは、Standard error modelとRicher error model(複数エラーに 対応)どちらでも対応できるよう実装した - また、可読性向上のため、既存のカスタムエラーの実装を見直しリファクタした
21. Agenda 1. 自己紹介 2. もくもく会で作業した内容 3. なぜ、Template Repositoryを作ることにしたのか 4. プロジェクトの前提 5. チームで踏んだ失敗と改善策 6. まとめ
22. まとめ - 汎用的な実装はテンプレートリポジトリに実装しておき、開発効率を上げていきたいです - 同じ失敗は繰り返さないように、仕組みで解決していきたいですね - ご清聴ありがとうございました！