事業成長を加速させるGoのコード品質改善の取り組み / Code quality improvement for Go language

by TajimaTheMemer

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

© ZOZO, Inc. 3 ショップスタッフの販売サポートツール「FAANS」とは ● WEAR, ZOZOTOWN, Yahoo!ショッピング, アパレルブランドの自社 ECへのコーディネート投稿やその成果の可視化など、ショップスタッフのオンライン接客を支援する業務支援ツール ● ZOZOTOWN上でブランド実店舗の在庫取り置きを希望した際に、ショップスタッフが FAANS上での簡単操作で取り置き対応を完結できるといった実店舗業務のサポートにも対応

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

© ZOZO, Inc. 7 機能開発の傍、様々な技術的負債の解消に取り組んでいます ● ソフトウェアのドメインモデル ● データベースのデータモデル ● Web APIのスキーマ定義 ● データベースや外部 APIといった外部コンポーネントとの連携処理 ● レイヤー構造やパッケージ構成、それらの依存管理といったサーバサイドのアプリケーションアーキテクチャ ● コード品質 ← 今日はこのお話 ● …

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

© ZOZO, Inc. 17 当初の弊チームのgolangci-lintの設定 ● golangci-lintはプロダクト立ち上げ当初から CIに導入していた。 ● yaml上では実行するLinterツールを何も指定していない、つまりデフォルトで有効化される Linterのみを実行する設定となっていた。 ● golangci-lintでデフォルトで有効化されている Linter一覧 ○ errcheck ○ gosimple ○ govet ○ ineffassign ○ Staticcheck

Slide 18

Slide 18 text

© ZOZO, Inc. 18 Linterの設定を徐々に厳しくしていく手順 ● golangci-lintの設定ファイルにおいて disable-all: trueの上でenable配下にLinterを列挙していくホワイトリスト型を採用した。 ● まずは、enable配下にデフォルトで有効化されていた Linterを明示的に指定して実質的に設定に差分がない状態とした。 ● その際、デフォルトで有効ではない、つまり未導入の golangci-lintのLinter一覧をコメントアウトする形で列挙しておく。

Slide 19

Slide 19 text

© ZOZO, Inc. 19 Linterの設定を徐々に厳しくしていく手順 ● 続いて、有効化したい Linterをコメントアウトして1つずつPull Requestを分けて有効化していく。 ● 有効化したLinterにより変更していない既存コードの部分で CIがコケるようになると開発体験が下がるため、導入時にプロジェクトコードの全範囲においてその Linterでエラーが出る箇所を修正する。腕力！ 💪

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

© ZOZO, Inc. 23 スタイルガイドの導入 ● コーディング規約はドキュメントにまとめ、チームで認識合わせできるようにしておくことはチーム開発の基本 ○ コミュニケーションコストの削減 ○ 新メンバーのオンボーディングの円滑化 ● 0から自分たちでコーディング規約を定めていくのは開発組織の規模に見合わない労力がかかり非現実的なので、一般に公開されていて信頼できるスタイルガイドにできる限り乗っかる戦略 ● 導入したGoのスタイルガイド ○ Effective Go (Go言語公式) ○ Go Code Review Comments (Go言語公式) ○ Google Go Style Guide (Google社製)

Slide 24

Slide 24 text

© ZOZO, Inc. 24 Google Go Style Guide ● 2022年11月に公開されたGoogle社によるGoのスタイルガイド。 ● Effective Goを前提としているのでスタイルガイド間のバッティングもない。 ● 読みやすく慣用的な Goのコーディングスタイルを示している。 ● 可読性が高いコードを書く上での迷いを最小化し、初心者にありがちなミスを避けられるようにすることが目的。 ● https://google.github.io/styleguide/go/

Slide 25

Slide 25 text

© ZOZO, Inc. 25 Google Go Style Guideは3章構成規範的(canonical): 規範的かつ永続的なルール標準的(normative): 一貫性を持たせるためのルール章主な対象者規範的標準的 Style Guide EveryOne Yes Yes Style Decisions Readability Mentors Yes No Best Practices Anyone Interested No No ● 3章全てをチームが従うべきスタイルガイドとして一先ず導入した。

Slide 26

Slide 26 text

© ZOZO, Inc. 26 「Style Guide」の5原則 ● 個別ケースだけでなく全体に通底する考え方も説明されていて Good！ ● 5原則 (上から重要度順) ○ Clarity (明白さ) : 目的と根拠が読み手にとって明白か ○ Simplicity (シンプル) : できる限りシンプルなやり方で目的を達成しているか ○ Concision (簡潔さ): 高いS/N比を有しているか ○ Maintainability (保守性): 保守は容易か ○ Consistency: 広範なGoogleのコードベースと一貫しているか ↓ 5原則という優先度付きの判断基準をチームの共通認識として持つことで、スタイルガイドに具体的な書き方が記載されていないようなケースにおいても実装時やレビュー時に判断しやすくなり、チームとして合意形成もしやすくなった。

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

© ZOZO, Inc. 29 Goにおけるエラーハンドリング ● 業務アプリケーションでは関数 /メソッドの呼び先で発生したエラーを fmt.Errorf() (Go 1.13〜)を使って呼び先の関数/メソッドの名前や引数の値といった情報を付与する形でエラーをラップしてから上流に伝播させるのが一般的。 ○ そのまま返してしまうとエラーログからエラーの発生箇所が分かりにくくなりトラブルシューティングの難易度が上がる。 ○ なお、サードパーティライブラリを使ってスタックトレースを出す方法もある。 ※標準パッケージにスタックトレースの機構は現状存在しない。

Slide 30

Slide 30 text

Slide 31

Slide 31 text

© ZOZO, Inc. 31 After: 関数/メソッドの”呼び先側”でエラーをラップするようにした ● エラーが発生した呼び先の関数 /メソッドの情報を呼び元側ではなく呼び先側で fmt.Errorf()を使ってエラーをラップして上流に伝播させるようにした。 ● errwrapperというpackageを用意してエラーのラップ処理が関数 /メソッドの内部実装の文頭 1行で済むように簡易化した。 “err”だとエラーハンドリングが抜けている箇所を Linterで検知できなくなるため ”err”以外の命名とする

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

© ZOZO, Inc. 34 errwrapperパッケージのPros/Cons ● Pros ○ 呼び先側の関数/メソッドの先頭で一度だけエラーラッピングのロジックを記述するだけで、その関数/メソッド内で発生するエラーは自動的にラッピングされるのでラク。 ○ 呼び先の関数/メソッドの情報以外の情報を付与したいケースを除けば、呼び元ではエラーをラップする必要がなくなったのでコードがシンプルになった。 ● Cons ○ 標準的なやり方ではないため外部ライブラリの関数 /メソッドでは呼び元でエラーを適切にラップする必要があり、その分の認知負荷がかかる。

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

© ZOZO, Inc. 39 Before: ファクトリ関数を使わずにDomain層のEntityの構造体を初期化していた ● アプリケーション固有のビジネスロジックを実装する UseCase層でDomain層に実装されたEntityを表す構造体をファクトリ関数を使わずに初期化していた。 ○ 属性値のバリデーションチェックなどのドメイン層の知識が Domain層ではなくUseCase層で実装されて凝集度が下がってしまう。 → ドメインモデル貧血症 ○ 属性値の指定忘れやバリデーションチェックのし忘れによる中途半端に初期化された状態の構造体の存在を許容してしまう恐れ。 → バグの温床

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

© ZOZO, Inc. 42 After: Entityを表す構造体のファクトリ関数を定義して凝集度を高める ● ファクトリ関数内で属性値のバリデーションや変換処理が行われるため、不完全な状態の構造体が生成されることがなくなった。 ● ドメイン固有の知識が UseCase層に散らからずにDomain層に集約されたことで凝集度が高まった。 ● 例えば、複数のEntity間で共通の属性などは Defined Typeで適切に「値オブジェクト」化し、その属性のバリデーション処理を値オブジェクトの生成処理内で行うことで凝集度を高めることも有効。

Slide 43

Slide 43 text

© ZOZO, Inc. 43 ② Defined Typeによるファーストクラスコレクション ● ファーストクラスコレクション ○ 配列などのコレクションをラップする専用のクラスを持ち、そのコレクションのビジネスルールや振る舞いをそのクラス内に実装するオブジェクト指向プログラミングの実装パターン ● Defined Type ○ GoではDefined Typeを使用することで独自の新しい型を定義可能 ○ Slice型に対してDefined Typeで新たな型を定義しその型でメソッドを定義することでファーストクラスコレクションが容易に実現

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

© ZOZO, Inc. 52 ボーイスカウトルールによるコード品質改善のチーム方針 ● 既存のコードに変更を加える際はその周辺がチームの規約に沿ってなければついでに直す。 ● 利用する既存の定数 /変数/構造体/関数/メソッドも規約に沿ってなければついでに直す。 ● ただし、既存コードの品質改善のための変更により Pull Requestのレビュー負荷が高くつく場合は、改善部分を適切な粒度で別 Pull Requestとして切り出して出す。

Slide 53

Slide 53 text

© ZOZO, Inc. 53 ボーイスカウトルールは実効的なアプローチ ● 新規事業で機能開発に追われる中で継続的に既存コードを改善していく上でボーイスカウトルールは実効的なアプローチ。 ● ただし、限界があるのでボーイスカウトルールだけに頼らない。 ○ セキュリティやシステム障害のリスク、後手になると負債回収コストが増大する類の負債は、独立したタスクとして切り出し優先度を上げてしっかり工数を割いて取り組むことも大事。工数を確保する交渉力もエンジニアに求められるスキル！ 💪 ○ 定期的にチーム全員が改善タスクに専念する日を作るのも有効。