
# はじめに
Goのベストプラクティスや命名規則をまとめておきます。

# 命名規則
Goにおける良い命名とは、
- 一貫性（ = 推測しやすい）
- 短い（ = タイピングしやすい）
- 正確（ = わかりやすい）
 
## ディレクトリ名
- なるべく1単語にする
- どうしようもない時はケバブケース(/xxx-xxxxx)
## ファイル名
- スネークケースにする
 
## MixedCaps
- Goでは変数名や関数名で単語を連結するときはアンダースコアではなくキャメルケースを使う

## パッケージ名
- パッケージがインポートされたときのアクセサの名前となる
- 簡潔に、簡明で、内容を喚起しやすいものにする
- 小文字で1単語で命名する。アンダースコアやキャメルにする必要はない
   - 例外としては `_test` suffix
- すべてのソースコードを通じてユニークである必要はない
  - もしパッケージ名の衝突が起きる場合、 エイリアスをつければOK
```go
import (
    tauth "hoge/fuga/twitter/auth"
    fauth "hoge/fuga/facebook/auth"
)
```
- パッケージのコードの中で使う関数名などは、パッケージ名を考慮して名付ける
  - `パッケージ名 + 関数名`で1セット関数名でパッケージ名を繰り返さない
  - 例えば、bufioパッケージの`Reader`という型は`bufio.Reader`で呼び出されるため、型名を`BufReader`にするべきではない
  - 呼び出す際は、`パッケージ名.関数名`で呼び出すため、型名を`Reader`としても、`bufio.Reader`と`io.Reader`などは衝突しない
- utilityパッケージにしない
  - base、util、common、lib、misc とか

## インターフェイス名
- 基本的には`method名 + er`
```go
type Reader interface {
    Read(p []byte) (n int, err error)
}
```
- 英語としておかしくても気にしなくていい

```go
type Execer interface {
    Exec(query string, args []Value) (Result, error)
}
```
- 英語的な語順を使って良い感じにすることもある

```go
type ByteReader interface {
    ReadByte() (c byte, err error)
}
```
- インターフェイスが複数のメソッドを持つ時は、インターフェイスの目的をうまく表す命名をする
  - 例: net.Conn, http.ResponseWriter, io.ReadWrite


## GetterとSetter
- Go自体はGetterとSetterを自動ではサポートしていないが、自前でGetterとSetterを作ることに関しては問題ない
- Getter名に`Get`はつけない。例えば、`owner`というunexportedなfieldがあったとして、そのGetterは`Owener()`となる
- Setter名には`Set`をつける。例えば、`owner`というunexportedなfieldがあったとして、そのSetterは`SetOwener()`となる
```go
owner := obj.Owner()
if owner != user {
    obj.SetOwner(user)
}
```

## 関数名
- 短く書く。長くなるくらいならコメントアウトで説明を書いたほうがいい

## 引数名
- 型名が説明的である場合は、引数名は簡潔に
```go
func AfterFunc(d Duration, f func()) *Timer

func Escape(w io.Writer, s []byte)
```
- 型名が曖昧な場合は引数名を説明的に
```go
func Unix(sec int64) Time

func HasPrefix(prefix []byte) bool
```

## 戻り値名
- 名前付き戻り値
  - 説明のためにのみ使われるべき

## 変数名・レシーバ名
- 英語1文字か2文字でなるべく短く命名
    - 型が`Client` であれば`c`、`cl`等
- レシーバ名は仲間のmethods間では統一する
- また、修飾語を利用しない
  - `httpClient`と`DBCreator` は両方とも`c`
- 命名は基本的にキャメルケースだが、元々略語として浸透している単語は一貫した大文字と小文字を使用
```go
ACL,API,ASCII,CPU,CSS,DNS,EOF,GUID,HTML,HTTP,
HTTPS,ID,IP,JSON,LHS、QPS、RAM、RHS、RPC、SLA、
SMTP、SQL、SSH、TCP、TLS、TTL,UDP,UI,UID,UUID,
URI,URL,UTF8,VM,XML,XMPP,XSRF,XSS
```
  
- 変数名は宣言から離れた場所で使用される名前ほど、より説明的な名前にする必要がある


## エラーの名前
- 型名
  - `〇〇Error`
- 変数名
  - 基本的には`err`
  - exportする時とかは`Err〇〇`にする（Err prefixをつける）

## map などの存在チェック
以下のように特定のキーが存在するかどうかをチェックする際には ok という変数名を使うのが慣例
```go
id, ok := tweets[tweetID]
```

# 書き方など
## レシーバについて
- レシーバのタイプはレシーバに対して一貫性をもたせる
- レシーバのタイプの使い分け
  - ポインタレシーバを使うとき
    - 迷ったとき
    - レシーバを更新したいとき
    - レシーバが大きな構造体や配列のとき
      - 大きい ≒ その構造体や配列の要素をmethodに渡すとしたとき、量が多すぎると思ったら
  - 値レシーバを使うとき
    - 変異するフィールドやポインタがない場合
    - レシーバが map、func、または chan の場合
    - レシーバの型がintやstringのような単純な基本型の場合
## Slice
- 空スライスを定義するときは`:=`で定義しないほうがいい
  - `:=`を使わない場合（`var`で定義する場合)
    - 初期値は`nil`になる
  - `:=`を使う場合
    - 初期値はnon-nilでzero-length
    - ただし、[]string{} を JSON にエンコードするときとかはこっちが良い
```go
// good
var t []string

// bad
t := []string{}
```

## 引数
- 数byteの節約のためにポインタ型を渡さないこと
  - stringやinterfaceは固定バイトだから値を直接渡していい
- 大きな構造体や成長する可能性のある構造体はポインタ型を渡していい

## エラーハンドリング
- 本当の例外のときのみpanicをつかう
- エラーハンドリングを即座に行うことで、ネストを浅くする
  - ネストが浅い = 読み手が理解しやすい
```go
// Bad
if x, err := f(); err != nil {
    // error handling
    return
} else {
    // use x
}

// Good
x, err := f()
if err != nil {
    // error handling
    return
}
// use x
```

もしくはこの書き方もOK
```go
// Good
if err := f(); err != nil {
    // error handling
    return
}
```

## コードが長い時は`:=`をつかわないで型を明確にする
- 長いコードになってくると読み手にとって`:=`はどんどん辛くなる
- 型を指定することで見やすくなる
```go
func main(){
var x int = 2020
//do something
}
```
## 不要な変数やインポートは書かない
- 残しておきたいならコメントアウトしておくこと

## すぐにエラーハンドリングしてネストを浅くする
- ネストが浅い = 読み手が理解しやすい
  
## 便利なutilitiesを使って繰り返しを減らす
- Goには、特定の機能を実行するために最適化されたutilitiesがあるのでそれらを利用して繰り返しを減らす


# 参考記事
- https://talks.golang.org/2014/names.slide#9
- https://tanakakns.github.io/go/naming/
- https://zenn.dev/keitakn/articles/go-naming-rules
- https://tanakakns.github.io/go/naming/
- https://github.com/golang/go/wiki/CodeReviewComments

【随時更新】Goのベストプラクティスについて


# はじめに
ポートフォリオサイト（本サイト）をリニューアルしたので紹介したいと思います！

# 今回使用した技術スタック

- フロントエンド: `Next.js/TypeScript`
  - Next.js/TypeScriptに挑戦しました。CSSフレームワークはTailwind CSSを使いました。
  - 
- バックエンド: `言語とかフレームワークは特になし`
  - BlogはMarkdownファイルを読み込んでいます。
  - 画像の配信はCloudinaryから実施しています。
- ホスティング: `Vercel`
  - 特にCDを用意しなくても、GithubにPushするだけでホスティングできるのは便利
  - もともとNetlifyで試験的にデプロイしていましたが、Vercelのほうが早いという記事を何個か読んだのでVercelに切り替えました

# 特徴

## デザイン

- サイト、及びロゴは<a href="https://twitter.com/ayano58764615">@ayano58764615</a>さんにデザインしていただきました。ロゴは桜文鳥がモチーフになっています。かわいい印象の強い桜文鳥をかっこよく転換していただきました。

<img src="../../../images/buntyo.png" />
<h5 style="text-align:center;">ロゴ↑</h5>
<img src="https://res.cloudinary.com/djprqtbkw/image/upload/v1648052600/thumbnail_ixgc70.png" />
<h5 style="text-align:center;">トップページ↑</h5>

## ブログの記事管理

- ブログの記事はマークダウンで管理しています。DB やバックエンドのロジックを用意しなくていいので色々楽をできます。
- コードのシンタックスハイライトは Prism.js で実施しました。が、好みの見栄えにするためにほとんどのハイライトは上書きしてます。

```go
type Person struct {
    Name string `json:"name"`
}

func (p *Person) sayName() string {
  return p.Name
}

```

<img src="https://res.cloudinary.com/djprqtbkw/image/upload/v1648052599/markdown_hcvtvj.png" />
 <h5 style="text-align:center;">マークダウンファイルで執筆中↑</h5>

## Zennから記事をインポートできるようにした
- [Zennが提供してくれているRSSフィードフィード](https://zenn.dev/zenn/articles/zenn-feed-rss)を使って[自分がZennに書いた記事](https://zenn.dev/ryota_o)をインポートできるようにしました。Zennに投稿されている記事は<span style="background-color:#027d9c;display:inline-block;padding:2px 6px;border-radius:5px;">#Zenn</span>が自動でつきます。
。

# 今後の予定

- とにかく記事数を増やしたいです。
- 潰せるだけ CSS のブレを修正したいです。
  - 機能デザイン両面ともより良いものにしていきたいと思います。
- 現在個人開発中のものや、その他開発中のものも準備が出来しだい掲載したいです。
- Google Analytics を入れたいです。

最後までお読み頂きありがとうございました！これからよろしくお願いします。



ポートフォリオサイトをリニューアルしました


# はじめに

[AWS ソリューションアーキテクト アソシエイト](https://aws.amazon.com/jp/certification/certified-solutions-architect-associate/)に合格したので振り返りたいと思います。

## そもそも
前提として、試験前の自分のAWSの経験は
- AWSを使ってWebアプリケーションをコンテナデプロイをし、インターネットから使えるようにできる
- 業務で利用しているAuroraのDBをアップグレードする
  
くらいでした。その他少しだけ使ってみたり、使ったことはないが何ができるかは知っているみたいなサービスはありましたが、試験範囲の半分は正直あまりわからないというレベルでした。
# 学習期間

およそ12日くらいでした。内訳は一日あたり1〜2時間くらい + 隙間時間の確認でした。試験範囲の5割くらいは実務や趣味で利用したことがあったため、主に知らないサービスの知識のインプットに費やしました。オンプレ → AWSへの移行に利用するサービスやデータ分析系のサービスに関してはあまりイメージがつきにくかったので少し苦労しました。

# 学習方法
## この１冊で合格！ AWS認定ソリューションアーキテクト - アソシエイト テキスト&問題集

数年前に勢いで購入していた[この１冊で合格！ AWS認定ソリューションアーキテクト - アソシエイト テキスト&問題集](https://www.amazon.co.jp/%E3%81%93%E3%81%AE%EF%BC%91%E5%86%8A%E3%81%A7%E5%90%88%E6%A0%BC%EF%BC%81-AWS%E8%AA%8D%E5%AE%9A%E3%82%BD%E3%83%AA%E3%83%A5%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%88-%E3%82%A2%E3%82%BD%E3%82%B7%E3%82%A8%E3%82%A4%E3%83%88-%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88-%E5%95%8F%E9%A1%8C%E9%9B%86-%E3%82%A2%E3%82%AF%E3%82%BB%E3%83%B3%E3%83%81%E3%83%A5%E3%82%A2%E6%A0%AA%E5%BC%8F%E4%BC%9A%E7%A4%BE-ebook/dp/B07VFFX6V1) を使って一通りの知識をインプットしました。しかし、私が持っている版は少し古く最新のAWSに追いついていない部分もあったため、別のリソースを使って保管する必要がありました。

## Cloud Tech

[Cloud Tech](https://kws-cloud-tech.com/)の無料プランに登録しました。無料プランに登録すると200問の模試問題が受けられるのでこれを利用しました。実際には100問程度しか手をつけることはできませんでしたが、問題にでてきたAWSサービスで知らないものがあったら公式ドキュメントを見てひたすら覚えるという作業ができたため、「この１冊で合格！ AWS認定ソリューションアーキテクト - アソシエイト テキスト&問題集」で足りなかった部分を補完することに繋げられました。

## 公式ドキュメント

本やCloud Techで、より詳細に理解したい局面がでてきた時は[公式ドキュメント](https://docs.aws.amazon.com/)を見るようにしていました。
# 終わってみて
感想です。

- 1回ざっとインプットしたらひたすら演習問題とスキマ時間の復習をするのが一番効率的だと思いました。英単語の暗記とかと同じです。
- 実務歴1年程度というレベル感は、まさしくという感じでした。
- 試験範囲には直近自分の実務ではほとんど関わらないようなサービス（オンプレからCloudへの移行系、データ分析系)も少なからず含まれていました。しかし実際の試験ではAWSでよく利用するサービス（VPC、EC2、EBS、S3、Auto Scalingなど）をどう使うかを問う問題が多かったです。自分が受けた回ではたまたまそうだったのか、ソリューションアーキテクト プロフェッショナルへの布石なのかはわからないです。
- 勢いを止めたくないので、次は[AWS ディベロッパー アソシエイト](https://aws.amazon.com/jp/certification/certified-developer-associate/)を取りたいと思います！ 6月あたりに受けたいです。

Hello,

Welcome to

onuma-ryota.com

About Me

Skill Set

Languages・Frameworks・Library

DB・KVS

Cloud

DevOps

Others

Blog

【随時更新】Goのベストプラクティスについて

ポートフォリオサイトをリニューアルしました

AWS認定ソリューションアーキテクトアソシエイトを取得しました

Contact

Hello,

Welcome to

onuma-ryota.com

About Me

Skill Set

Languages・Frameworks・Library

DB・KVS

Cloud

DevOps

Others

Blog

【随時更新】Goのベストプラクティスについて

ポートフォリオサイトをリニューアルしました

AWS認定ソリューションアーキテクト アソシエイトを取得しました

Contact

AWS認定ソリューションアーキテクトアソシエイトを取得しました