Slide 1

Slide 1 text

開発生産性向上のために Go Template Repositoryを 作った話 noru / x-id:@noru86kawaii golang.tokyo #37

Slide 2

Slide 2 text

自己紹介 - noru - software developer - 普段はBackend (Go) を書いたり、Infra構築したり - アプリケーション設計が好き - 最近、ポケポケにハマっています

Slide 3

Slide 3 text

最初に... - 今回お話しする内容は、今から運用していく予定です - 改善点や提案があれば、こっそり共有いただけると嬉しいです!

Slide 4

Slide 4 text

本LTで伝えたいこと - Goの新規開発が多い場合は、開発効率を上げるためにGo Template Repository も1つの選択肢として良いかも - Go Template Repositoryを作った際のライブラリ選定理由や考慮したことの一部を 紹介します

Slide 5

Slide 5 text

背景 - 直近、Goの新規開発に取り組むことが多かった - 自社事業 - 受託事業

Slide 6

Slide 6 text

各Goプロジェクトの新規開発の悩み - 似たようなカスタムラーやログ等の実装を再開発している - ライブラリ選定について都度議論している - 頻度が多いレビュー項目を減らしたい

Slide 7

Slide 7 text

自分なりに考えた解決策 - Go Template Repositoryを作ることで解決できるのでは? - サーバー、カスタムエラー、ログ等を実装した雛形の GitHubリポジトリ - 新規リポジトリを作成する際に選択できる - 設定も簡単

Slide 8

Slide 8 text

Go Template Repositoryで悩みを解決する - 似たようなカスタムラーやログ等の実装を再開発している - Template Repositoryに組み込むことで解決 - ライブラリ選定について都度議論している - Template Repositoryで使用しているライブラリの選定理由をドキュメント に残して、議論時間を短縮することが狙い - 各プロジェクトによって最適なライブラリは異なるので、参考程度に - 頻度が多いレビュー項目を減らしたい - Template Repositoryにサンプル実装を組み込む

Slide 9

Slide 9 text

- 共有ライブラリを実装する - 今回は採用しませんでした - 理由としては、メンテナンス工数をどれだけ確保できるか未知数であり、管理責任を負えないため です - Template Repositoryは、あくまで「新規開発の立ち上げを手助けする 」位置付けにしました - 各プロジェクトで、Template Repositoryを使う or 使わないを意思決定してもらう - 各プロジェクトメンバーごとで、 Template Repositoryのコードを含め責任を持つ - Template Repositoryの改善点があれば、共有していただく Go Template Repository以外の選択肢

Slide 10

Slide 10 text

Go Template Repositoryで実装したもの一覧 - APIサーバー - 環境変数 - ログ - カスタムエラー - DataBase周り - APIドキュメント - CI (GitHub Actions) - Dockerでコンテナ化 - CRUDのサンプル実装 - 便利パッケージ - DI - Lint - Test - …

Slide 11

Slide 11 text

実装背景やライブラリの選定理由を一部紹介 - ログ - バリデーション - CRUDのサンプル実装

Slide 12

Slide 12 text

ログ slogライブラリを採用 - 「標準ライブラリ」なのが選定理由 - 今後のデファクトスタンダートになっていくと思っています - 調べたところ、パフォーマンス面も問題なさそう - 構造化ログで出力する内容の精査も合わせて対応

Slide 13

Slide 13 text

バリデーション ozzo-validationライブラリを採用 (go-playground/validatorの方がよかったかも...) - ozzo-validation - メリット - コードでバリデーションできるので、コンパイルエラーに引っかかる - デメリット - メンテされていない - go-playground/validator - メリット - メンテされている - 構造体タグでバリデーションするので、網羅性の担保がしやすい (後ほど気付きました ) - デメリット - 構造体タグでバリデーションするので、コンパイルエラーにならない

Slide 14

Slide 14 text

CRUDのサンプル実装 前提 - レイヤー構造で書かれています - Domainレイヤにモデルやビジネスロジックを定義し、UseCaseレイヤでDomainレ イヤの実装を呼び出して使用する方針です (ロジックの重複防止) レビューで多かった内容 - UseCaseレイヤにビジネスロジックを実装しているので、Domainレイヤに実装して ください

Slide 15

Slide 15 text

CRUDのサンプル実装 解決策 - モデルのフィールドはprivateにして、モデルに紐づくロジックを他のレイヤから publicメソッドを使わないと使えないようにした - また、配列やマップに対するロジックもDomainレイヤで実装するサンプル例も追加 した (ファーストクラスコレクション) - 都度レビューするのではなく、Goのprivateを使用してカプセル化して、仕組みで解 決する

Slide 16

Slide 16 text

まとめ - 新規開発を頻繁に行う場合、開発生産性向上の1選択肢として、Template Repositoryも良いかもしれません - Go Template Repositoryを作るにあたって、一部のライブラリ選定理由とサンプル 実装の意図をお伝えしました

Slide 17

Slide 17 text

最後に 最後までご清聴いただきありがとうございました