Goを書き始めたばかりの頃、
正直こんな気持ちでした。
- 「シンプルすぎて不安」
- 「これ本当に正解なの？」
- 「書き方、雑じゃない？」
でも今なら分かります。
あの時の自分は、だいたい全部ズレてた ということに。
今回は、
Go初心者だった頃の自分に“今だから言えること”を10個
供養も兼ねてまとめました。
① if err != nil は、減らそうとしなくていい
最初の頃は思ってました。
「エラーハンドリング多すぎじゃない？」
でも今なら言えます。
- エラーは“制御フロー”
- 隠さないから読みやすい
- 後から追いやすい
try-catchが恋しくなる時期は、だいたい最初だけ です。
② interface は“先に切るな”
初心者の頃の自分へ。
「まだ1実装しかないのにinterface切るな」
Goのinterfaceは軽いけど、
必要になってから切れば十分。
- mockが必要になった
- 実装が2つ以上出た
- 境界を分けたい理由が言語化できた
この3つが揃ってからでいい。
③ struct は“ドメイン”として考えろ
「とりあえずstruct作るか」
→ だいたい失敗します。
structは
- ただのデータ入れ物ではない
- “意味”を持つ存在
- ビジネスルールの塊
名前を考える時間は、無駄じゃない。
④ goroutine は魔法じゃない
初心者あるある。
「並列にしたら速くなるでしょ！」
→ なりません。
- 共有状態が増える
- バグの温床になる
- 終わらないgoroutineが生まれる
まずは 同期で正しく書く。
並列はその後。
⑤ defer は便利だけど、考えなしに使うな
deferを書きすぎた結果、
- 処理順が分からなくなる
- パフォーマンスが微妙に落ちる
- 「いつcloseされるんだっけ？」問題
便利なものほど、意識して使う。
⑥ nil は怖がるものじゃない
nilは敵だと思ってました。
でも実際は、
- 「状態がない」ことを表す
- 明示的で分かりやすい
- ゼロ値と組み合わせると強い
nilをどう扱うかが、Goらしさ。
⑦ package は“フォルダ分け”じゃない
初心者の自分へ。
「packageは意味の塊で切れ」
- 技術単位で分けない
- レイヤーで切りすぎない
- “責務”で考える
importが読みやすくなる＝設計が良い。
⑧ return は早くていい
「return多すぎでは？」
→ Goでは普通です。
- ネストが減る
- 読むストレスが減る
- エラーがすぐ分かる
早く抜けるコードは、やさしいコード。
⑨ テストは“後回し”にするな
初心者の頃は、
「動いたからOK」
だったけど、
- テストがあると安心できる
- リファクタが怖くなくなる
- 設計が自然と良くなる
Goのテストは
思ってるより、だいぶ楽。
⑩ Goは“賢く書く言語”じゃない
最後に一番言いたいこと。
Goは、
- 書き手が賢く見える言語じゃない
- でも、読み手にやさしい
- チーム開発で本領を発揮する
「自分が書いて気持ちいい」より
「他人が読んで分かる」
これを受け入れた瞬間、
Goが一気に楽しくなりました。
まとめ：あの頃の自分へ
- Goは“不親切”に見えて、実は親切
- 迷ったらシンプルに戻れ
- 抽象化は後でいい
- 読みやすさは正義
もし今、
「Goむずいな…」と思っていたら、
それは順調にハマっている証拠 です。