Goを書き始めて1年ちょっとが経ちます。普段の何気ない開発の中でGo実装気づいたり、教えてもらったりなtipsをまとめてみました。皆さんの日々の開発がちょっと良くなればいいなと思います。

## 1. t.Paralelをサブテストにつけたのに、トップテスト関数にはつけない

サブテストに`t.Parallel()`をつけたなら、トップレベルの関数にも`t.Parallel()`をつけるようにしましょう。トップレベルにつけないと、結果的にトップレベルのテスト関数が終わった際にサブテストのテスト結果が逐次処理されるだけになり並列化の恩恵を受けることができません。詳しくはメルカリさんの[ブログの内容](https://engineering.mercari.com/blog/entry/how_to_use_t_parallel/)が参考になります。
![img](/mosaic-code.jpg)


## 2. Wrapをつけて、エラーの追跡をしていない

エラーハンドリングする際は`Wrap`してスタックトレースするようにした方がいいと思います。sentry等で本番運用していてエラーが起きた際にどこでどの経路を辿って発生したエラーなのかがわかるので、障害対応のスピードも早まります。`Wrap`はhttps://github.com/pkg/errors で利用することができます。スタックトレースは`New`などでも呼び出すことができます。ただ、独自エラーで返したり、追跡しやすいようにエラーメッセージを追加したりとある程度使う関数は限られていると思います。よく使われるのは`Wrap`と`WithStack`だと思います。

|           |                                                         |                                                                          | 
| --------- | ------------------------------------------------------- | ------------------------------------------------------------------------ | 
| Wrap      | 与えられたerrにメッセージを追加してスタックトレースする | メッセージ付きでエラーをラップしたい時に使う                             | 
| WithStack | 与えられたerrを元にスタックトレースする                 | 外部ライブラリのエラーや独自エラーなどをスタックトレースしたい場合に使う | 

## 3. Functional Optionパターンを使いすぎる

Go初学者の方でとくFunctional Optionパターンを使い、デフォルト引数を実現しよう！のように考えている人がいる気がします。確かにポインタを渡さないなど安全性の面などでも非常にすぐれて機能だと思います。一方でテストの際に[mock利用できない](https://zenn.dev/sanpo_shiho/articles/c06f6b156029a5)問題も発生します。また個人的に記述量が増えるのが気になっていました。オプション1つ増やすだけで関数1つ増やす必要があります。ケースバイケースですが、気軽にFOPを実装する前に構造体や可変長引数を一度検討するのもいいのではないかと思います。



Goを書き始めて1年ちょっとが経ちます。普段の何気ない開発の中でGo実装気づいたり、教えてもらったりなtipsをまとめてみました。皆さんの日々の開発がちょっと良くなればいいなと思います。

## 1. t.Paralelをサブテストにつけたのに、トップテスト関数にはつけない

サブテストに`t.Parallel()`をつけたなら、トップレベルの関数にも`t.Parallel()`をつけるようにしましょう。トップレベルにつけないと、結果的にトップレベルのテスト関数が終わった際にサブテストのテスト結果が逐次処理されるだけになり並列化の恩恵を受けることができません。詳しくはメルカリさんの[ブログの内容](https://engineering.mercari.com/blog/entry/how_to_use_t_parallel/)が参考になります。
```go
func TestTopFunc(t *testing.T) {
	t.Parallel()  // 追加(サブテストを追加した際、トップレベルのテストにも追加しないと逐次処理になる)

	// サブテスト実行
	for _, tt := range tests {
		tt := tt
		t.Run(tt.name, func(t *testing.T) {
			t.Parallel()  // 追加

			.
			.
			.
		})
	}
}
```


## 2. Wrapをつけて、エラーの追跡をしていない

エラーハンドリングする際は`Wrap`してスタックトレースするようにした方がいいと思います。sentry等で本番運用していてエラーが起きた際にどこでどの経路を辿って発生したエラーなのかがわかるので、障害対応のスピードも早まります。`Wrap`はhttps://github.com/pkg/errors で利用することができます。スタックトレースは`New`などでも呼び出すことができます。ただ、独自エラーで返したり、追跡しやすいようにエラーメッセージを追加したりとある程度使う関数は限られていると思います。よく使われるのは`Wrap`と`WithStack`だと思います。

|           |                                                         |                                                                          | 
| --------- | ------------------------------------------------------- | ------------------------------------------------------------------------ | 
| Wrap      | 与えられたerrにメッセージを追加してスタックトレースする | メッセージ付きでエラーをラップしたい時に使う                             | 
| WithStack | 与えられたerrを元にスタックトレースする                 | 外部ライブラリのエラーや独自エラーなどをスタックトレースしたい場合に使う | 

## 3. Functional Optionパターンを使いすぎる

Go初学者の方でとくFunctional Optionパターンを使い、デフォルト引数を実現しよう！のように考えている人がいる気がします。確かにポインタを渡さないなど安全性の面などでも非常にすぐれて機能だと思います。一方でテストの際に[mock利用できない](https://zenn.dev/sanpo_shiho/articles/c06f6b156029a5)問題も発生します。また個人的に記述量が増えるのが気になっていました。オプション1つ増やすだけで関数1つ増やす必要があります。ケースバイケースですが、気軽にFOPを実装する前に構造体や可変長引数を一度検討するのもいいのではないかと思います。



1. t.Paralelをサブテストにつけたのに、トップテスト関数にはつけない

続きを読むには単価診断を受けてください（30秒）