現在、私はObjective-Cで書かれたメインプロダクトを少しずつSwiftに書き換えている最中です。*1
おそらく奮闘中の皆さんのためにも、私が得た知見をお話ししようと思います。
なぜメインプロダクトのSwift移行が進まないのか
これは、単純にメインプロダクトは巨大で複雑であることと、メインプロダクトでユーザーに新たな価値を届けつつ、同時にSwiftに移行するのが困難であるのが原因であるように思えます。
大きなメインプロダクトは一部を書き換えるだけでも依存関係を解消するのに骨が折れます。 書き換えを進めると「え、このクラスここでも使われてるの…？」というような新事実が後から判明します。
また、メインプロダクトは、新機能の実装や改修でユーザーに新たな価値を届けなければなりません。会社の収益源となっているようなサービスの開発を長期間止め、Swiftへの移行だけに力を注ぐわけにはいきません。
機能開発と同時にアプリを別言語に書き換えるというのは、走っている自動車のタイヤを走りながら付け替えるような荒技のように思えます。なかなか難易度が高いですね。
上記のような理由でメインプロダクトのSwift移行がなかなか進んでいないのだと思います。
そこで、そのような環境下でも、少しずつSwiftに移行する方法をひねり出しました。
メインプロダクトを少しずつSwiftに移行するTips
- 新規クラスは必ずSwiftで書く
- 1度に書き換えるのは1回のQAでカバーできる範囲まで
- Utility -> View -> ViewController -> Model -> APIClientの優先度で書き換える
新規クラスは必ずSwiftで書く
新規クラスは必ずSwiftで書くようチーム内でルールを定めましょう。
既存のObjective-Cのクラスを書き換えるのは大変ですが、新規クラスをSwiftで書くのであればさほど問題ありません。
メインプロダクトの開発の主目的である「ユーザーに新たな価値を届ける」という目的を達成しつつ、Swiftのコードを増やしていけます。
1度に書き換えるのは1回のQAでカバーできる範囲まで
Swiftへの書き換えは、1度に1回のQAでカバーできる範囲内にとどめましょう。 やりすぎると事故が起きます。
例えば、画像周りで機能改修をしている場合、関連するクラスを一緒に書き換えると、機能改修と書き換えを同時にチェックすることができます。
事故は注意していなかった部分で起きることが多いため、注意が向いている部分を書き換えて一緒にQAしてしまうと安心してリリースができます。
Utility -> View -> ViewController -> Model -> APIClientの優先度で書き換える
依存度が低い部分から書き換えましょう。
特にちょっとした処理をまとめたUtilityクラスや、Viewのコードは依存する箇所が少ないため、比較的安全に移行ができます。
ViewControllerはちょっと勇気が要りますが、単体で完結していることが多いため、やる気さえあれば移行ができると思います。
問題はModelとAPIClientです。いろいろな箇所から呼び出され、依存関係も複雑なため、移行にはかなりのやる気が必要になるでしょう。*2
まとめ
メインプロダクトは巨大で複雑であり、機能開発と同時に移行を進めなくてはならないためSwiftへの移行がなかなか進みません。
新規クラスはSwiftで書くようにルールを定めたり、1度に書き換えるのを1回のQAでカバーできる範囲内にとどめる、UtilityやViewなど依存の少ない安全な部分から移行を進めることで比較的安全にSwiftに移行を進められます。
