shtnkgm
🧵

Lint駆動開発を考える

@shtnkgm・2020/5/10

Lint Driven Development

ふと、新しい言葉として Lint駆動開発 っていうものが考えられるんじゃないかと思った。 英語の Lint Driven Development （LDD）でWeb検索すると以下の記事が2件だけヒットした。

Lintとは

Lintとは何か。調べてみると糸くずをとるブラシ、ローラーのことを lint brush 、 lint roller というらしい。

  • コンパイラではチェックされない、 バグの要因となりそうなソースコードの記述に対し、警告を行う静的解析処理 のこと
  • lintを直訳すると 「糸くず」という意味 で、乾燥機の糸くずを取り除くさまをプログラミング用語として流用したもの

参考: CodeGrid - ESLintを使ったコードの品質管理 第1回 (opens new window)

SwiftにおけるLinter

iOS、macOSアプリの開発のSwift言語におけるLinterは以下のSwiftLintがデファクトスタンダードとなっている。

https://github.com/realm/SwiftLint (opens new window)

SwiftLintではコーディングスタイルの自動フォーマットや開発プロダクト独自のカスタムルールを追加することができる。

# カスタムルールの例
# IBOutletのアクセスレベルをチェックする
private_set_iboutlet:
  included: "./Main/.*\\.swift"
  name: "IBOutlet private(set)"
  regex: "@IBOutlet weak"
  message: "IBOutletのアクセスレベルはprivate(set)にしてください"
  severity: error

# タイプセーフにするため、適切な型が利用されているかチェックする
use_custom_type:
  name: "use custom type"
  regex: "((itemId|storeId|categoryId): String)"
  message: "idを表現する型はString型でなく、独自型を利用してください"
  severity: error

このLinterをXcodeのRun Script Phasesに組み込むことで、ビルドする毎に実装ミスをワーニングやエラーとして指摘できる。さらに、CI環境のDangerプラグインとして組み込むことで、プルリクエストに対しても自動でレビューコメントを追加することができる。

特にプルリクエストを提出する前にコードをチェックできることは実装ミスや設計そぐわないコードなど、問題の早期発見に繋がり、手戻りを防止することができる。

自分の考えるLint駆動開発

自分の考えるLint駆動開発は単純にLinterが便利だから利用しようというだけでなく、 開発ワークフローの一部として取り込み、Linterを成長させながら 開発を推進していくというものになる。品質向上のための開発プロセスにおいて、Linterで自動化できる領域を継続的に増やしていくことでプロダクトの品質が次第に高まり、生産性が向上する。

Linterの導入と運用のステップは以下のようなものを想定している。

  1. プロダクトのコード品質としての理想型を決める（コーディング規約、アーキテクチャ、実装方針の定義）
  2. その型をコードテンプレートやLinterのルールに落とし込む
  3. チームメンバーが実装する
  4. コードレビューでの指摘事項はLinterのルールに追加を検討
  5. 不具合が発生した場合は、Linterのルールに追加を検討

Link-Driven Development Workflow

Lint駆動開発のポイント

Lint駆動開発を効率的に進めるための要点について整理する。

Linterになるべく指摘させない。 本末転倒なように思えるが、Linterに指摘されて、いちいち修正を繰り返すのはそれはそれで手間になる。Linterをパスできるコードテンプレートの整備や自動修正を活用することで、本当に必要なタイミングでのみ警告を行う。

Warningを放置しない。 Warningが数百件あるプロダクトでは、Warningが増えたことにすら気づかない。このような不健全な状態に陥るとLinterの効果が半減してしまう。これは割れ窓理論 (opens new window)にも近い話になる。

割れ窓理論（われまどりろん、英: Broken Windows Theory）とは、軽微な犯罪も徹底的に取り締まることで、凶悪犯罪を含めた犯罪を抑止できるとする環境犯罪学上の理論。アメリカの犯罪学者ジョージ・ケリングが考案した。「建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、やがて他の窓もまもなく全て壊される」との考え方からこの名がある。

引用: Wikipedia - 割れ窓理論 (opens new window)

Warningは放置せず、小さなWarningでも修正をし、さらに軽微な実装ミスでもWarningでなくビルドエラーにすることでより修正が促される。

コードレビューでの指摘事項は、Linterで検知できないか検討する。 これにより、同じ指摘を次からしなくてよくなり、その他のより本質的な抽象度の高い指摘が可能になる。複数人での大規模開発の場合に、コードレビューの品質の均一化にも繋がる。

不具合が発生した場合は、Linterで検知できないか検討する。 Linterは不具合の再発防止にも利用できる可能性がある。不具合が発生した理由が実装ミスにあるのであれば、Linterで利用するAPIを制限したり、必要な処理が行われていること確認すれば良い。こうすることで、長期的に開発されるプロダクトで、開発メンバーが全員変わったとしても再発防止を自動チェックすることができる。

Lintルールは資産であると考える。 Lintルールはそのプロダクトのあるべき姿をまとめた、開発参画メンバーの集合知になる。より早く導入することでより効果を生み出してくれ続ける。自動化できる領域を増やすことはチームの生産性の向上に繋がる。

@shtnkgm
Coder