2016/08/29に開催されたAKIBA.swift×Swift愛好会 スペシャルコラボの発表資料です. 2016/08/23には簡易版も発表させていただきました。

1. チーム開発にSwiftLintを導入してみた
詳細版
AKIBA.swift×Swift愛好会スペシャルコラボ
2016/08/29

2. 自己紹介
Kaori Ikada @Origami inc.
モバイルアプリエンジニア
基本的にikamon みたいなアカウントで動き回っている

3. ことのはじまり

4. 宗教戦争勃発
2015年10月某日：
メンバ増えたし、SwiftLint入れてみよう！
と思ったら、ルールのカスタムできない！
ので、諦める
2016年5月某日：
ワークフローに関するKPTミーティングで出たProbrem に
「Swift Coding Styleが無い」！と言われる
ただ、コーディング規約とかいうドキュメントはまだ増やし
たくない

5. 本気出して、SwiftLintを導入しよう！

6. Xcode編

7. SwiftLint導入
github.com/realm/SwiftLint
git submodule でもインストールできる
Build Phases にswiftlint 実行用スクリプトを追加
※画像は本家から拝借

8. とりあえず既存コードに当ててみる
Over 999 warnings and 230 errors!

9. 怒られたルールとその理由
(force_cast):
(variable_name):
3から40文字以内にしろ(func内の小さいスコープでしか
使わない変数は対象外)
_ などの英数文字以外は禁止
小文字から始めろ
(type_name): struct は大文字から始まる名前をつけろ
(line_length): 1行につき100文字以内にしろ
(function_body_length): 関数は100行以下にしろ
(control_statement): if文などの条件式にカッコをつけるな
if (true) { -> if true {
(cyclomatic_complexity): if / else if の繰り返しが多すぎ

10. .swiftlint.yml のカスタム
開発に集中できる＆緩くなりすぎないルールファ
イルを作成する
(force_cast): 今直すとテスト必要そうなので、手をつけたくない
force_cast: warning
(line_length): Objective-C のコードも呼ぶので、line_length デフ
ォルトルールはキツい
line_length: 120

11. SwiftLint対策第一弾
ルールを緩めずにエラーを取り除く
とりあえず、今までの罪を噛み締めながら直しまくる
ルール把握のため、一番ボリュームのあるSwiftで書いた
ViewControllerについて、Warning も含め直してみた

12. 逃げの一手
すぐ直せないものはTODO コメントとルール無効コメントを
追記（TODOはwarning扱い）
// TODO: Delete temporary comment
// swiftlint:disable type_body_length
こういうのもあるらしい(ルール指定できるなら使えるかも)
swiftlint autocorrect

13. Apply SwiftLint MTG 開催
SwiftLint適用前にミーティングを用意
iOSプロジェクトにがっつりコミットする人は参加必須にし
て、後は興味ある人を募った
SwiftLintルールの紹介と、社内で使う .swiftlint.yml ルー
ルカスタム内容の共有

14. 意外と参加者多かった
開発責任者
iOSエンジニア
Growthエンジニア
デザイナー

15. MTGで話題になったこと
改行位置は？ -> 基本、Xcodeに従う
変数名の命名規則はどうする？ ->
https://swift.org/documentation/api-design-guidelines/
自動ではないけど参考になる規約->
https://github.com/raywenderlich/swift-style-guide

16. iOSプロジェクトに適用
ミーティングでルールの合意を得た後、プルリクを出す
他気になることあれば、コードレビュー中に議論
masterにSwiftLintサブモジュール化・修正コード・README
更新のdiffが入ったら、メンバーにアナウンス
各ローカルリポジトリでSwiftLintのインストールをお願いする
以降、新しいSwiftコードを書く際はSwiftLintルールに従うこ
ととする

17. Xcodeに入れることで
得られたメリット
コードレビュー前に治せる
コードレビューで指摘できる
好みの違いから生じる摩擦が減る
Objective-C由来のクセが少なくなった
.swiftlint.yml をリポジトリ管理にすれば、ruleの編集には
diffが出るのでバレる

18. Jenkins編

19. JenkinsでSwiftLintを適用する設定１
SwiftLint をインストール
Xcode のSwiftLint実行コマンドは、Debug時のみに設定
if [ "${CONFIGURATION}" = "Debug" ]; then
# swiftlint ...
fi

20. JenkinsでSwiftLintを適用する設定２
Jenkins ジョブのビルドスクリプトにswiftlintコマンドを追加する
swiftlint lint --reporter checkstyle
> swiftlint_report.xml || true
Checkstyleプラグインを設定
Viorations Plugin

21. できた- Violations Report
※ filename をたどると、該当コードもわかる

22. 定期MTGで共有
Jenkins で入れてみたよ
999+ warnings より具体的な数字がわかったよ
以前のSwiftコードに手を加える時は周辺のwarningを減らせる
ようにして、グラフが右肩下がりになるといいね！

23. Jenkinsに入れることで
得られたメリット
継続的品質の分析と改善ができる
メンバ間でlintエラーを減らしていこうという意識が芽生える

24. We are hiring!
多分採用されると思うから応募しようぜ
https://www.wantedly.com/companies/origami/projects