自己紹介
こんにちは。助太刀アプリチームの高橋です。
助太刀iOSアプリにおける、リファクタリングに関して取り組んでいることを、この記事を通じて共有しようと思います。
今回は ワーニングの除去 について話を進めていきたいと思います。
最初はワーニング5000個
つい1年前のことですが、弊社のコードにはなんと約5000個のワーニングが出ていました！！！
内容はさまざまで、半角スペースがないとかあるとか、改行すべきであるとかないとか、タイポであるとかというものをはじめ、
「Update to recommended settings」（推奨設定へ更新してください）といったものまであり、
中でも大部分を占めているのはSwiftLintによるワーニングでした。
コードを開くたびに黄色いワーニングがはびこり、可読性は皆無でした。
ワーニングの増大
ワーニングが5000個になる前の話ですが、弊社プロジェクト内のコードはプロパティ、メソッド、ライフサイクル、エクステンションなどの表記位置がまとまっておらず実装者によってバラバラ・ぐしゃぐしゃで、可読性が低い状態でした。読みにくいゆえにちょっとした改修や、不具合修正でも何がどうなっているのかをいちいち解読する必要があり、実装の時間がかかっていました。
【例】
func 〇〇() {
....
}
override func viewWillAppear(_ animated: Bool) {
super.viewWillAppear(animated)
....
}
var 〇〇 = ""
func 〇〇() {
....
}
let 〇〇 = ""
override func viewDidLoad() {
super.viewDidLoad()
....
}
enum 〇〇 {
....
}
そこで導入したのがSwiftLintのtype_contents_orderというルールでした。（参考）
これはプロパティやメソッドの並び順を指摘するものなのですが、良い反面、これによってワーニング数が5000個に増大したのでした。
すぐに並び替えを修正してワーニング対応をしようとしていましたが、次第に施策などによってリファクタをする余裕がなくなり、5000個のワーニングは残ったままでした。
SwiftFormatの導入
チーム再編成によってようやくワーニングを消す余裕が生まれたので、
まずは半角スペースやら改行などの単純なワーニングをSwiftFormatを使って次々と自動で消していきました。
これによって約5000個のワーニングが約3500個に減りました。
しかし、SwiftLintのtype_contents_orderはSwiftFormatと互換性がなく、残りは手動で直すしかありませんでした。
手動で2500個を消す
残りの約3500個のうちtype_contents_orderが3000個を占めていました。
1週間ほどワーニング消しに専念し、2500個のワーニング消しに成功。
コードの並び順も統一されて可読性が向上しました。
残り500個はTODO:ワーニングなどなので（永遠に着手しないTODOも問題）、地道に消していこうと思います。
最後に
弊社アプリが立ち上がってから約5年は経ちますが、スタートアップゆえにその時その時のさまざまなエンジニアがさまざまな書き方で自由に書いてきたツケとして現在のジャングルコードがあり、その一つとして5000個のワーニングが野放しになっていました。
現在ではチームとしてルールや方針が定まってきたことで、ようやく負債解消の兆しが見えてきました。
あらためて 野放しはダメ、ルールは大事、だということを痛感しました。
最後まで読んでいただきありがとうございました。次回の記事でお会いしましょう。
助太刀では一緒に開発してくれるメンバを募集してます！
少しでもご興味を持っていただけたら下記よりお気軽にご連絡ください！
Discussion