Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Go活
Search
tkitsunai
December 13, 2019
Programming
0
140
Go活
社内でgolangを採用したときにチームメンバーに展開した資料
tkitsunai
December 13, 2019
Tweet
Share
More Decks by tkitsunai
See All by tkitsunai
TDD実践を経て変わったこと
tkitsunai
6
4k
値オブジェクトでアプリケーションコードを改変しよう
tkitsunai
0
130
hbstudy#82 SRE大全 ソフトウェアエンジニアリングによるToil削減
tkitsunai
0
2.6k
Software Development in UZABASE SRE
tkitsunai
0
3.6k
Other Decks in Programming
See All in Programming
初学者でも今すぐできる、Claude Codeの生産性を10倍上げるTips
s4yuba
16
11k
Discover Metal 4
rei315
2
130
XP, Testing and ninja testing
m_seki
3
240
MDN Web Docs に日本語翻訳でコントリビュートしたくなる
ohmori_yusuke
1
120
システム成長を止めない!本番無停止テーブル移行の全貌
sakawe_ee
1
200
チームのテスト力を総合的に鍛えて品質、スピード、レジリエンスを共立させる/Testing approach that improves quality, speed, and resilience
goyoki
5
870
AI コーディングエージェントの時代へ:JetBrains が描く開発の未来
masaruhr
1
140
チームで開発し事業を加速するための"良い"設計の考え方 @ サポーターズCoLab 2025-07-08
agatan
1
420
Claude Code + Container Use と Cursor で作る ローカル並列開発環境のススメ / ccc local dev
kaelaela
9
5.1k
AI時代の『改訂新版 良いコード/悪いコードで学ぶ設計入門』 / ai-good-code-bad-code
minodriven
13
3.5k
スタートアップの急成長を支えるプラットフォームエンジニアリングと組織戦略
sutochin26
1
5.6k
「テストは愚直&&網羅的に書くほどよい」という誤解 / Test Smarter, Not Harder
munetoshi
0
170
Featured
See All Featured
4 Signs Your Business is Dying
shpigford
184
22k
Side Projects
sachag
455
42k
KATA
mclloyd
30
14k
Rebuilding a faster, lazier Slack
samanthasiow
82
9.1k
Automating Front-end Workflow
addyosmani
1370
200k
Into the Great Unknown - MozCon
thekraken
40
1.9k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
107
19k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
Producing Creativity
orderedlist
PRO
346
40k
Optimizing for Happiness
mojombo
379
70k
Documentation Writing (for coders)
carmenintech
72
4.9k
Transcript
Go活 実用編 更新:2019/12/12
Goの何が良いのか ・マスコットの存在 ・かわいい ・エコシステムの強さ ・パッケージマネージャ、 Linter、Formatter、ビルドなど ・標準パッケージの強さ ・シンプルが故に、net/httpパッケージ、encoding/jsonパッケージなどライブラリに頼らなくても一定水準の パッケージが提供される
Goの何が良いのか 2 ・覚えることが少ない ・go routine(channel), for, if, struct(methods), interface, slice,
pointerぐらいしかまずは覚えない ・ノリ(雰囲気)で書ける ・Simple Go Way ・言語機能でやれることは高が知れてる ・Duck Typing
Goの常識 (基本) ・ゼロ値、0, false, “” ・structも同様(後述) var i int var
f float64 var b bool var s string
Goの常識 (宣言) ・型宣言(var)+初期化、型推論(:=) type,const,varはまとめてかける type ( User struct {} Human
struct {} )
Goの常識 (Struct Constructor) ・`new(Type) *Type`という組み込み関数が存在する(ゼロ値のポインタが帰ってくる) ・引数ありならFactoryをExport関数として定義する type Person struct {
name string } func NewPerson(name string) *Person { return &Person{name: name} }
Goの常識 (Panic/Recover) ・Panicを使うケースはほぼない ・Recoverでキャッチすることは可能だが ... <使うユースケース> ・アプリケーション自体を異常終了させたい ・configの読み込み、DB接続、などなど
Goの常識 (型定義) ・単純なValueを持つStructならば、型を別名として再定義できる ・別の型なので、型システムの恩恵を受けられる ・型Aliasとはちょっと違う type Name struct { Value
string } &Name{ Value: ”name” } type Name string Name(”name”)
Goの常識 (型Alias) ・リファクタリングのための機能 ・NicePerson型は名前が違うだけでGoodPerson型と同一の型 reflect.TypeOf(GoodPerson{}) == reflect.TypeOf(NicePerson{}) はTRUE type GoodPerson
struct{} type NicePerson = GoodPerson
Goの常識 (書き方) ・型推論で変数を受け取る ・できるだけzero allocationを目指す(ベンチマークテストを書いても良い)
・ファイル名は全て小文字にし、複数の単語を利用する場合は snakeケースにする ・テストは同一パッケージ内に aiueo_test.goで作り、pkg_testパッケージにする ・コード整形はgo fmtコマンドによるFormatterに全てを委ねる ・パッケージレベルのアクセス修飾子だけを考えれば良い。頭文字大文字で public 小文字でprivate Goの常識
(その他)
Goの常識 (エラーハンドリング) Goでのエラーを扱うときに流派があり、それぞれ背景がある。 <前提> ・errorはinterfaceであり、`Error() string`を持つ全ての型はerrorになれる ・errorが発生する可能性がある関数は errorを返す
Goの常識 (エラーハンドリング) ・エラーが発生しうる関数は多値で結果と errorを返すようにする ・呼び出し側が責任をもって errorを処理する func Divide(x, y int)
(int, error) { if y == 0 { return 0, errors.New(“division by zero error”) } return x + y, nil }
Goの常識 (エラーハンドリング) ・標準パッケージでの使われ方 ・エラーを値として定義する var NotFoundError = errors.New(”Not found error”)
var EOFError = errors.New(”EOF error”)
Goの常識 (エラーハンドリング) ・標準パッケージでの使われ方 ・エラーを型として定義する type NotFoundError struct { Err error
Url string } func (n *NotFoundError) Error() string { return n.Url + ”:” + n.Err.Error() }
Goの常識 (エラーハンドリング) ・エラーの返し方 ・そのまま返す results, err := doSomething() if err
!= nil { return nil, err }
Goの常識 (エラーハンドリング) ・エラーの返し方 ・独自型にして返す path := ”http://example.com/” result, err :=
GetResource(path) if err != nil { return nil, &NotFoundError{Url: path, Err: err} }
Goの常識 (エラーハンドリング) ・エラーの比較 ・errorを型や値で比較する(エラー文字列で比較してはいけない)
Goの常識 (エラーと向き合う) <現実問題> ・スタックトレース、どこでエラーになったのかが欲しい ・独自型を毎回作るのは辛い ・エラーの中身だけ取り出すの辛い ・結局最後は文字列やん?
Goの常識 (エラーと向き合う) ・エラーと向き合うためのライブラリが発展する => https://github.com/pkg/errors ・errors.Wrap()でエラーを装飾、errors.Cause()で中身を取り出す => https://github.com/golang/xerrors ・(型の場合)Unwrap()で取り出し時、返却時にxerrors.Errorf(arg)で装飾 ・Is()を使ってエラーが含まれているか判断、
As()をつかってエラーを取り出す => https://github.com/morikuni/failure ・エラーコードなどで定義していく模様、 xerrorsのいいとこ取りしている
よく使うライブラリ群(Backend API) 用途 ライブラリ おすすめ度 一言 Test https://github.com/stretchr/testify ★★★★★ 標準でgoのテストは書けなくなる
DI https://github.com/google/wire ★★★★☆ google謹製の依存注入ライブラリ Error https://godoc.org/golang.org/x/xerrors ★★★☆☆ errorのwrapの仕組みを使える REST https://github.com/gin-gonic/gin ★★★★☆ Gin, Echoあたりがデファクト 標準のみでもOK conf https://github.com/spf13/viper ★★★☆☆ 素直なConfig読み込みが可能 ORM http://doc.gorm.io/ ★★★★☆ 高機能ORMでActiveRecord風
たくさんあるライブラリ群 https://github.com/avelino/awesome-go