Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
Go Code Review Comment を翻訳した話
Search
Kenshi Kamata
June 01, 2017
Programming
7.8k
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Go Code Review Comment を翻訳した話
Kenshi Kamata
June 01, 2017
More Decks by Kenshi Kamata
See All by Kenshi Kamata
500万ユーザーを支える残高の冪等性 / The idempotency of the balance for 5 million Merpay users
knsh14
0
3.1k
チャネルの仕組み
knsh14
6
5.6k
Go1.10 strings.Builder の紹介
knsh14
2
1.5k
Go でインタプリタを 書いてみよう
knsh14
0
3.1k
Let’s Create An Interpreter In Go
knsh14
0
170
tvOS Leaderboard
knsh14
0
1.2k
Other Decks in Programming
See All in Programming
phperだってパンチカードでコーディングしたい
o0h
PRO
0
220
JRuby: Past, Present, and Future
headius
0
220
なぜCTOを降りてFDEを選んだのか?〜なぜプロダクト企業がFDEで顧客の現場に踏み込むのか〜
gonta
1
160
20260914 AIエージェント時代のPlatform Engineering LLM基盤とプロダクトの責務境界線
kanfab1
7
2.4k
Augmenting AI with the Power of Jakarta EE
ivargrimstad
0
470
ジョジョの世界をXRで再現する
mofurune
0
130
Are APIs Still Relevant in the AI Era?
soyuka
0
430
そのリトライ、死んだコネクションを使い回していませんか ── GoのHTTPクライアントとHTTP/2を実プロダクト障害から学び直す
myus4a
0
390
Jetpack Compose Mechanisms
skydoves
2
510
見えないものを探る要求要件定義に必要な基本的思考 / invisible-requirement-thinking
minodriven
15
7.6k
大喜利で理解するLLM as a Judge / Understanding LLM-as-a-Judge through Ogiri
rockname
0
190
[Rails World 2026] Durable orchestration on Rails: from continuation to workflow
palkan
1
480
Featured
See All Featured
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
33
5.1k
Believing is Seeing
oripsolob
1
240
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
230
23k
Building a Modern Day E-commerce SEO Strategy
aleyda
45
9.2k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
141
35k
How to Talk to Developers About Accessibility
jct
2
560
How to Think Like a Performance Engineer
csswizardry
28
2.9k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
Organizational Design Perspectives: An Ontology of Organizational Design Elements
kimpetersen
PRO
1
840
Building the Perfect Custom Keyboard
takai
2
890
[RailsConf 2023] Rails as a piece of cake
palkan
59
7.1k
Optimizing for Happiness
mojombo
378
71k
Transcript
Go Review Comment を翻訳した話 Golang Tokyo #6 鎌田健史 ( @knsh14
)
自己紹介 • 鎌田健史 • @knsh14 • KLab 株式会社 エンジニア ◦
Unity でプロト作ったりツール作った り ◦ Javascript でゲーム作ったり • Go 歴2年位
今日の要旨 • みんな Go Code Review Commentsを読もう! ◦ 転ばぬ先の杖を持とう ◦
読んだら次は Effective Goへ! • みなさんも翻訳してみて欲しい! ◦ 勉強の効率めっちゃいい
Go Code Review Commentsとは? https://github.com/golang/go/wiki/CodeReviewComments • コードレビューする際にまずは見るべき箇所をまとめたもの • Effective Go
を更に簡単にしたもの ◦ Go 版リーダブルコード • ありがちな話をまとめたもので、スタイルガイドではない ◦ 必ずしも従う必要もないし無理する必要はない
で翻訳を書きました http://qiita.com/knsh14/items/8b73b31822c109d4c497 • それなりに原文に忠実に訳したつもり ◦ 一部英語力の問題で意味不明な部分もある • なるべく原文に追従する努力 ◦ 3月くらいに見直したら更新されてたので慌てて追記
◦ Context の項もあるよ!
翻訳を書くきっかけ とある社内ツールを Go で書いて レビューお願いしたところ ボッコボコのフルボッコにされる
翻訳を書くきっかけ その時に渡されたのが Code Review Comments だった とりあえず読んだ証拠に自分で翻訳してみることに 3日くらいで全部訳しきった tenntenn に一通り読んでもらって手直ししたあと公開
翻訳してみてよかった • 業務でガリガリ書いているわけじゃないので、初学者の僕に とってはこういういきなり正解のパターンを勉強できるのは効 率が良かった • 自分で言葉に書き起こす分脳みそを使う • 英語の勉強にもなったので他の英語書籍に挑戦するハードル も下がった
もうちょっと中身を詳しく
幾つかのカテゴリに分けられる • コードの見た目を改善 ◦ Gofmt, Mixed Caps… • コメント、文章の体裁 ◦
Comment Sentences, Error String... • tips 系 ◦ Declaring Empty Slices, Named Result Parameters... • 設計の指針 ◦ Receiver Type, Don’t Panic...
コードの見た目を改善 大体はツールでなんとかしようぜな話 gofmt, goimports, golint あたりを使っておけばまず大丈夫 特に golint はめちゃくちゃ優秀
コメントや文章の体裁 コード内の文章の書き方などに関するアドバイス 「説明するものの名前で始めてピリオドで終わりましょう」なんてい うかなり具体的な説明もある 特に Error String で紹介されている「エラーで返すときの文字列 は大文字始まりにしない」はかなり意外だった
tips 系 Declaring Empty Slices や、Named Result Parameters など 間違いではないけどよりよい方法を紹介してくれるパターン
var t []string と t := []string{} の使い分けは意識して書かないと 結構やらかしてることが多そう
設計の指針になるようなもの Receiver Type はぜひ一度読んでみてほしい レシーバーを ポインタにするかどうか迷ったときの指標になる 基本的にはポインタで問題ないけれど、幾つかのパターンにハマ るときはそうでないほうがいい時もある
最後に • 良いドキュメントの翻訳はめっちゃ勉強になるので積極的に やっていきたい • Code Review Comment はぜひ皆さん目を通して欲しい! ◦
そのために日本語で訳したので