低依存なlintから始めるスケールする開発

設定ファイルでもスクリプトでも、あらゆる構造データは lint に通すようにしている。アンチパターンを容易に見つけ出せるし、構文エラーも静的に発見できる。複数人開発では bike-shed 問題に費やす時間を減らすこともできるだろう。

Linter ♡ Docker

Linter 導入の障壁となるのは処理系の多さである。開発機であっても lint のために Ruby, Python, Haskell, Node など環境依存は増やしたくないだろう。かといってベストな linter を選ぶために処理系で制限はかけたくない。

そこで docker を用いる。次のリストはあるプロジェクトの lint コマンドの一覧である。

• docker run –rm -i hadolint/hadolint < Dockerfile
• docker run –rm -v “$PWD:/mnt” koalaman/shellcheck:stable script/*.bash
• docker run –rm -v “$PWD:/workdir” announced/erb-lint –config .erb-lint.yml __PATH_TO__/*.yml.erb
• docker run –rm -ti -v “${PWD}:/workdir” giantswarm/yamllint -c config/yamllint.yml “${1}”

このように、依存は docker だけで、多くのフォーマット (Dockerfile, Bash, ERB, YAML) の lint を実現している。

自家製イメージのススメ

使いたい linter が Docker Hub になければ自作してみよう。私も erb-lint を用意してみたが、数10分で作業は完了した（その大半は alpine へ kaminari を入れるのに費やした）。野良で放流して、本家にも一報を入れておくと喜ばれるかもしれない。

イメージのタグは linter のバージョンに合わせると分かりやすくてよいだろう。

用法容量を守って楽しい docker ライフを

もちろん要件次第なので全ての linter を docker に寄せる強迫観念に駆られる必要はない。下記のような例外もあるので、総体として開発効率が高まるツールを選択しよう。

• ウェブのフロントエンド開発であればブラウザとの連携も多いので Node はネイティブで依存しても許せるかもしれない。
• 先に例としてあげたプロジェクトは Kotlin での開発がメインなので lint は Gradle (Java系のビルドツール) に任せている。

それでは。