これはなに
最近チーム開発をしていて、SwiftLintが欲しい1と初めて思ったシーンがあったのでその紹介と、なぜ入れたいと思ったのかを紹介する記事です。
SwiftLintが欲しいと思ったシーン
- 初めての人とチーム開発をすることになったとき
- チームに新しい人が入ってきたとき
- その時々で自分が「イケてる」と思っている書き方は変わるが、将来の自分に対して「このプロダクトは、この書き方で統一させた方が一貫性が出て良い」と説得したいとき
SwiftLintが欲しいと思った理由
- 将来の自分自身に対しても、他のチームメンバーに対しても、あとから参入する人のためにも、「この書き方で統一するルールになっています」ということが示せるから
- 「このチームではこの書き方をしているので、こう直してください」みたいなのをPR時に指摘していくのは、指摘する方もされる方もエネルギーを消費してしまうから
「コーディング規約」は「朝の挨拶運動」
欲しいと思った理由の前提として、コーディング規約が整備されていることを想定しています。
まずそのコーディング規約に対して賛成と反対が出てきたり、その人によって慣れたものでない可能性があります。それは小中高などの学校教育の中で行われた、「朝の挨拶運動」みたいなものだと思いました。
我々は学校教育の中で「朝は気持ちよく挨拶した方が、された方が気持ちいいだろ！」という理不尽を体験してきましたが、それは行う側・受け手側、個々人によって考え方が異なる部分になります。そしてそういう活動に反対だからという理由でやらないでいると「ちゃんと真面目にやれよ！」「がんばってみんなでやろう？」みたいな 理由が曖昧なお叱りを人から受けてはストレスを感じてきました。
コーディング規約においては、そうすべき理由がはっきりしていることが多いのでストレスは軽減されるものの、 いちいち人が指摘するという行動にはまだストレスと疲労が発生します。
また、「朝の挨拶運動」に賛成だったからといっても、その日の体調によっては気持ちよく挨拶が出来ない日が出てきてしまうかもれません。 いちいち人が確認するという行動にはまだ疲労が発生しますし、見逃しが出てしまう可能性もあります。
「指摘されるコードを書く方が悪い」とか誰が悪いとかそういうものではなく、エネルギーを節約して、見逃しなどの人依存のミスを減らすために、SwiftLintを入れた方が良かったかもと思ったのでした。
次の開発に向けて
今のプロジェクトはちょっと切羽詰まってきているので、次のプロジェクトでは開始時にSwiftLintを入れたいと思いました。
あと @YusukeHosonuma さんに教えてもらったものですが、SwiftFormatも試してみる価値があるかもと思いました。(Warningが出て教えてくれるだけでなく、良くないところは自動で直してくれるツールっぽいです)
-
「SwiftLint」と書いたのは、自分がSwiftで開発しているから。それに関連した話になりそうだったからで、他の言語・環境においてもLintを入れる動機とかは同じようなものになると思う ↩