SwiftLintとは？

https://github.com/realm/SwiftLint
チーム内のルールの統一に役立つコードチェックツールです。
例えば、いち関数につき３０行位内、や変数は小文字始まりで、などのルール確認ができます。
ビルド時にSwiftLintも実行するのが一般的です。
ルール規定外のコードが書かれていたらビルドできないようにする・もしくはwarningを出すという使い方ができます。

段階的に導入する

既存サービスの規模がおっきく、古いコードが残っている場合は十中八九ビルドできなくなります。
なので期間をとって段階的に導入していくのがいいと思います。

PC環境によっていは以外なところでビルドできなくなったりするので、途中から導入する際は慎重にいきましょう

段階導入のすすめ

３つの方法がとれると思います。
1. コードチェックを無視するディレクトリを増やす
2. コードチェック時にerrorを起こさないようにする
3. 修正差分のみに実行していく

この方法は、一部導入しつつ、ビルドができるようにする方法です。
もちろんこれらは段階的に修正していくことが前提です。
最初に導入したっきり修正することができないのならば入れる意味がないのでやめましょう。

1.SwiftLintの設定をいじって無視するディレクトリを増やす導入方法

1の方法では修正箇所がおおすぎる場合、長く期間をとって慎重にいきたい場合はこちらをおすすめします。
下記のように無視するディレクトリを増やしましょう。
ルールを甘くせずに、段階的にするのならばこれしかありません。
ただディレクトリ構成が適当なプロジェクトだと逆に苦労するかもしれません。

以下はswiftLintのREADMEからの引用です

excluded: # paths to ignore during linting. Takes precedence over `included`.
  - Carthage
  - Pods
  - Source/ExcludedFolder
  - Source/ExcludedFile.swift

2.swiftLintの設定をいじってerrorを起こさないようにする導入方法

ビルドでひっかかる項目が極端に少ない場合はこちらの方法をとりましょう
その項目が３項目以上になる場合はおすすめしません。
チームの為の変更なのか一時的な変更なのかがわからなくなるので混乱しやすいのと、忘れやすいので。
更新を忘れて、ルールが甘々になってしまっては導入する意味がなくなってしまいます。

disabled_rules(無視する項目)に追加する

disabled_rules: # rule identifiers to exclude from running
  - Colon
  - comma
  - control_statement

errorでなくwarningにする

type_body_length:
  - 300 # warning
  - 400 # error

3. 修正差分のみに実行していく

手を加えた箇所から実行し、徐々に改善する場合は、この方法がオススメです。
公式にも書いてあるRun Script Phaseを少し書き換えて、git diff毎に実行します。

if which swiftlint >/dev/null; then
  git diff --cached --name-only | grep .swift | while read filename; do
    swiftlint --path "$filename"
  done
else
  echo "SwiftLint does not exist, download from https://github.com/realm/SwiftLint"
fi

参考元：SwiftLintを変更のあったファイルのみに実行する方法

まとめ

以上が段階的に導入する方法と注意点でした。
Lint触ったことのある方には意味のない記事ですが、なにかの参考になれば幸いです。

もっといい方法あるよ！
などありましたらお気軽にお願いします。

既存サービスにSwiftLintを導入する際の手順と注意点