脱・オレオレコーディング！Swiftによるスムーズなアプリ開発のためのリファクタリング講座｜ヒカ☆ラボレポート

コーディング規約を作るところから、リファクタリングはスタート！

開発者本人にしか理解できないような、いわゆる“オレオレコーディング”が行われているアプリは、「後任者への引継ぎが非常に困難」「機能改善やバグの修正に多くの時間がかかる」など、たくさんの問題を抱えています。

それらの問題をクリアにするために有効な手段が『リファクタリング』です。

自分達がアプリのリファクタリングをする際、最初に行ったのが『コーディング規約の策定』でした。インデントやコメントの書き方、変数名や定数名の表し方、関数やクラスの表現方法といったことを、一つ一つ規約として定めていきました。

Xcodeをフル活用することで、iOSアプリ開発がスムーズに！

コーディングでは、Xcodeをフル活用しました。なぜXcodeを選んだかというと、Vimのような他のエディタだと、「使える人は使えるけど、使えない人は使えない」っていうところがあったからです。
XcodeはIDEとして使いやすいので、統合開発環境をXcodeにし、コーディング規約どおりに一括置換していきました。
それにより、バグを摘む必要がなくなったというか、一つずつファイルを直す手間が省けるようになりましたね。

またInfo.plistやBuild Settingを活用するところは、Xcodeで提供されているファイルの環境設定を用いて、開発環境と本番との差分を考慮していくことも行っていきました。

Info.plist ホスト面やAPIのパスを定義することで、手間を減らす

Info.plistでは、「Supported interface orientations」という項目の下に、自分たちで定義を追加していくことができます。ホスト面やAPIのパスや、GA（GA TRAKING ID）のような変わることがない定数については、どんどん定義を追加していき、わざわざソース内に書かなくても読めるような状態にしていきました。

Build Settings デバック用とリリース用を別々に定義することで、管理が容易に

Build setttingもinfo.plist同様、「User-Defined」の下に、自分達で定義を追加していくことが可能。私たちはこのBuild Setttingsを用いて、開発環境（デバック用）と本番環境（リリース用）を別々に定義していくことにしました。開発環境に見せるための定数と、本番でしか使わない定数をそれぞれ設定することで、開発環境のデータが本番に反映されるですとか、本番で見えるはずのものが開発環境で見えてしまう、といった状況をなくしていきました。

デザインパターンを適用するときに頼りになるSwift

また、Swiftはいろんなデザインパターンを踏襲することができます。特にベースとなるのがSingletonパターン。例えば、画像読み込みの部分にイメージマネージャーというのがあるんですが、そこのSingletonパターンを設定し値を持たせれば、viewの方に値を返してくれるんですね。「わざわざviewコントロールで頑張る必要がない」というのが魅力です。

次に、GAなどは、Adapterというデザインパターンを適用し、引数で値を分けていきました。さらに、GAの処理自体をmodelに全て任せることで、viewはできるだけ可読性を上げるといったことにも努めていきました。

さいごに

「開発を急ぎすぎた結果、ソースコードがつぎはぎだらけ…」
そんな状況に陥ってしまわぬよう、ソースコードの可読性を上げることを意識しながら開発は進めていきたいところです。
それでもリファクタリングの必要性を感じたら、気付いたところからまずやってみることが重要だと僕は考えています。
技術的負債が積み重なる前に、リファクタリングはぜひ行っていきましょう！