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
linter for your team rule
Search
mizkei
November 09, 2018
Programming
3
2.3k
linter for your team rule
mizkei
November 09, 2018
Tweet
Share
More Decks by mizkei
See All by mizkei
About: Go Module Proxy: Life of a query
mizkei
0
180
Goでゲームサーバーを実装して考えたこと / game server in go
mizkei
1
6.6k
Other Decks in Programming
See All in Programming
なぜ宣言的 UI は壊れにくいのか / Why declarative UI is less fragile
uenitty
29
13k
GraphQL はいいぞ! ~Laravel で学ぶ GraphQL 入門~
azuki
1
160
みんなのオブザーバビリティプラットフォームを作ってるんだがパフォーマンスがやばい #mackerelio #srenext
ne_sachirou
0
380
Polarsの成長: v0.14からv1.0までの変遷と今後の展望
zerebom
1
350
Rust.Nagoya #1
codemountains
0
170
【Go言語】golangci-lintの使い方
tomo1227
0
280
[After Kotlin Fest 2024 LT Night @ Sansan] もっともっとKotlinを好きになる!K2 Compiler Pluginで遊んでみよう!
kitakkun
2
260
コード生成を伴うLLMエージェント - 2024.07.18 Tokyo AI
smiyawaki0820
11
4.1k
継続的な活動で築く地方エンジニアの道
myamashii
2
360
ピグパーティにおけるMongoDB CommunityバージョンからAtlasへの移行事例
10969hotaka
0
130
ぼっちを避けて楽しむためのアノテコノテ / Various Tips and Tricks to Avoid Loneliness and Have Fun
nrslib
3
1.7k
初心者がおさえておきたいAWS CDKのベストプラクティス 2024
konokenj
15
7.3k
Featured
See All Featured
Web Components: a chance to create the future
zenorocha
307
41k
Unsuck your backbone
ammeep
666
57k
Robots, Beer and Maslow
schacon
PRO
157
8.1k
The Cult of Friendly URLs
andyhume
75
5.9k
Creatively Recalculating Your Daily Design Routine
revolveconf
214
11k
Building a Modern Day E-commerce SEO Strategy
aleyda
25
6.7k
How to train your dragon (web standard)
notwaldorf
79
5.5k
Put a Button on it: Removing Barriers to Going Fast.
kastner
58
3.3k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
90
47k
Making Projects Easy
brettharned
111
5.7k
Bootstrapping a Software Product
garrettdimon
PRO
304
110k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.4k
Transcript
プロジェクトのルールを チェックするためのlint mercari.go#4
目次 • 自己紹介 • golint • チームで取り入れたいルール • テストのために取り入れたいルール •
パッケージの役割を分けるために取り入れたいルール • ルールをチームで共有する方法 • ルール表現のために作成したツール「self-lint」 • まとめ
自己紹介 • 名前 ◦ 水野 敬太 • github ◦ mizkei
• twitter ◦ @mizkei11 • 仕事 ◦ Backend/マイクロサービス開発
golint
golintによるコーディングスタイルの指摘 • Effective Go や Go Code Review Comments に基づいた指摘
◦ 不要なelse ◦ コメントのフォーマット ◦ context.WithValueのkeyの型 ◦ 変数・パッケージ名 ◦ import Dot ◦ main以外でのblank import ◦ ...
golintによるコーディングスタイルの指摘 • プロジェクトにおけるコードの書き方がある程度統一される • エディタの設定をすれば、編集しながら確認可能 • reviewdog にログを食べてもらえば、github上でも指摘される 綺麗なGoのコードを書くためのルールとしては非常に有用だが、 チームのローカルルールが欲しい場合もある
チームで取り入れたいルール
特定パッケージのimport制限 • Assertなどを提供する外部パッケージ ◦ Why does Go not have assertions?
• プロジェクトにおけるテスト用パッケージ ◦ e.g. githoge.com/project/root/test ◦ テスト用のデータを用意するための便利メソッド群 ▪ 複数パッケージのテストで参照されるために一つのパッケージとして作成
プロジェクトにおけるテスト用パッケージ • テスト用のmock ◦ テストではないパッケージに含めたくない ▪ package modelをimportしてしまえば誰でも使えてしまうため • テストデータ作成便利メソッド
◦ *intなどを各パッケージのテストで書いていると手間がかかる
プロジェクトにおけるテスト用パッケージ
テストのために取り入れたいルール
特定メソッド・変数への参照制限 • テストのための時間停止用メソッドなど ◦ メソッドとして用意しない方法もあるが、テストが一手間増える ◦ 手間をかけないために楽をしたときにできてしまう副産物を テスト以外では利用できないようにしたい
テスト用に時間を停止するメソッド • 現在時刻による動作の差異がある場合をテストする時の方法 ◦ Now() time.Timeを実装したインターフェースを渡せるようにする ▪ テスト用に各種パッケージにインターフェースを渡すのが手間 ◦ グローバルにtime.Nowへの参照を持ったパッケージを作成して、
現在時刻取得はそのメソッドから行い、テスト時に差し替える ▪ テスト時に差し替える用のメソッドは `*_test.go` から参照できる必要があるため Publicなメソッドにしなければならない
現在時刻を差し替える(interface版) • interfaceを渡すべき構造体が複数ある場合など、テストでの管理が面倒
現在時刻を差し替える(global書き換え版) • build tagsを記述したファイルのみにメソッドを定義した場合、 エディタのlint設定も変更しなければならない • タグがなければ、差し替えるメソッドは機能しないが、差し替えるメソッドを TestGoFiles, XTestGofiles以外で参照することすらあってほしくはない
パッケージの役割を分けるために取 り入れたいルール
特定builtin機能の制限 • panic書く機会はほぼないため禁止してしまいたい ◦ web application書いているときなど • データの構造についてのみ記述するためのパッケージで条件分岐など不要 ◦ e.g.
githoge.com/project/root/data ◦ 構造体の定義だけ記述されていたり、 値を詰め込むだけのメソッドしか存在してほしくない
ルールの共有方法
チームでのルールの共有方法 • Wikiにまとめる ◦ 更新され続ける保証はない ◦ 読まないで書いてくる人いるかも ◦ レビューで指摘するとして、チームに入ってからの歴が浅いと 見逃してしまう可能性がある
人がチェックすると見逃す可能性を排除することはできないので、 チームルールを自動的にチェックするためのツールが欲しい
「self-lint」
self-lint • https://github.com/mizkei/self-lint • チームでの禁止事項(ローカルルール)をチェックするためのツール ◦ 特定importのチェック ◦ 特定packageのメソッドや変数への参照 ◦
panicなどのbuiltin functionの使用 • CIを利用した自動チェック ◦ golintと同じ出力形式であるため、reviewdogが食べてくれる
self-lintの設定 • target ◦ 対象のパッケージ ▪ globalは全てのパッケージ • import ◦
禁止したいパッケージを書く • ref ◦ 禁止したいパッケージの値を書く • write ◦ 禁止したいbuiltin functionを書く ▪ panic, if, switch, or for
特定importのチェック • テストファイル以外でtestパッケージはimportしてはいけない
特定パッケージの値への参照 • テスト用に作成されたメソッドを テストファイル以外で参照してほしくない
特定のbuiltinやstatementsの利用 • データを定義しているだけのパッケージでpanicしてほしくない
まとめ • lintに加えて、チームでの開発において、更に制限が欲しくなる場合に ついて述べた • チームとして設定した制限を自動チェックするために self-lintというツールを作成した