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
3.9k
値オブジェクトでアプリケーションコードを改変しよう
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
WebViewの現在地 - SwiftUI時代のWebKit - / The Current State Of WebView
marcy731
0
110
ペアプロ × 生成AI 現場での実践と課題について / generative-ai-in-pair-programming
codmoninc
1
4.3k
スタートアップの急成長を支えるプラットフォームエンジニアリングと組織戦略
sutochin26
0
330
AIと”コードの評価関数”を共有する / Share the "code evaluation function" with AI
euglena1215
1
100
今ならAmazon ECSのサービス間通信をどう選ぶか / Selection of ECS Interservice Communication 2025
tkikuc
21
3.8k
A2A プロトコルを試してみる
azukiazusa1
2
1.3k
Hypervel - A Coroutine Framework for Laravel Artisans
albertcht
1
110
なぜ適用するか、移行して理解するClean Architecture 〜構造を超えて設計を継承する〜 / Why Apply, Migrate and Understand Clean Architecture - Inherit Design Beyond Structure
seike460
PRO
3
730
High-Level Programming Languages in AI Era -Human Thought and Mind-
hayat01sh1da
PRO
0
710
第9回 情シス転職ミートアップ 株式会社IVRy(アイブリー)の紹介
ivry_presentationmaterials
1
260
「Cursor/Devin全社導入の理想と現実」のその後
saitoryc
0
700
設計やレビューに悩んでいるPHPerに贈る、クリーンなオブジェクト設計の指針たち
panda_program
6
1.9k
Featured
See All Featured
The Pragmatic Product Professional
lauravandoore
35
6.7k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
Documentation Writing (for coders)
carmenintech
72
4.9k
It's Worth the Effort
3n
185
28k
4 Signs Your Business is Dying
shpigford
184
22k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Thoughts on Productivity
jonyablonski
69
4.7k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
60k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
The Straight Up "How To Draw Better" Workshop
denniskardys
234
140k
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