長年運営されているPJにSwiftLintを入れた話
これは
この記事は、YAMAPエンジニア Advent Calendar 2021 の12月20日の記事です。
(明けましておめでとうございます。大遅刻すみません)
こんにちは、iOSエンジニアをやっている竹ノ内です!
普段はYamapのiOSアプリの開発に携わっており、
長年運営されているiOSプロジェクトにSwiftLintを入れてみた際の色々を書いていきたいと思います。
そもそもSwiftLintとは
SwiftLintとはSwift用の静的解析ツールです。
細かくLinterルールを指定してあげることができ、便利です。
Homebrew, Cocoapods, Mintなどから導入することができます。
(日本語の記事であれば、Uhooiさんの記事が分かりやすいです)
弊アプリにはCocoapods経由で導入しました。
導入した背景
元々弊プロジェクトではLinterは使っておらず、また厳格なコーディングルールも指定していなかったため、メンバー同士の暗黙知でルールが存在しているような状況でした。
その為、以下のような事象が発生していました。
- 新規メンバーの学習コストが高い(実体験)
- PRレビュー時にコーディングに対する指摘が入る
- レビュワーの負担増⇧
- レビュワーによって指摘項目が変わってくるため、コードの品質にばらつきが出る
こんな感じ(自分のコードが指摘されているところ)
これらの事象を解消するため、Swiftlintの導入を開始しました。
懸念点
ただ、弊アプリは初回リリースから約8年経過しておりコード量も多く、
あまり多くのルールを適応すると修正範囲が膨大になることが予想されました。
その為、以下のような流れで導入することとしました。
- SwiftLint内でデフォルトルールからいくつか必須そうなルールピックアップする
- デフォルトのルールを全て適応する
- OptInのルールを適宜適応する
修正の流れ
デフォルトのルールからいくつかピックアップして、ビルドをかけたところ10,000個以上の警告が出ました。
これを手作業で修正するのはかなり骨が折れるので、Swiftlintのautocorrect機能を使いつつ、
autocorrectが対応していないところやロジックに関わりそうなところは
手作業で修正しつつ、作業を進めました。
swiftlint --fix && swiftlint
また、Swiftlint自体はXcodeのBuild Phaseで走らせていましたが、
開発者自身がLinterを止めるor動いていない場合も考えられるため、
CIでもSwiftlintを実行して失敗した場合はGithubでわかるようにしています。
導入する上でのTips
これまたUhooiさんと同じになりますが、導入する際は以下が役に立つかと思います。
-
1ルール1ブランチで修正する
- 弊アプリの場合は機械的な修正がメインだったので、一気にやってしまいましたが、修正範囲が膨大すぎたので、分けるべきでした。
-
全部のルールを適応しない
- ルールによっては、too muchになったり、修正範囲が大きくなってしまうことあるのでバランスを見た方が良さそうです。
終わりに
導入が終わって、また一つ属人化しない開発に近づいた気がします✌
告知
弊社ではエンジニアだけでなく他の職種も随時募集していますので、
アウトドア好きな方も、今好きじゃない方もチェックしてみてください🙏
Discussion