#objective-c

// hope for the best, prepare for the worst | Objective-C

アプリを長い間運用していると、その間に仕様が変わったりリファクタをしたりで今まで使っていたコードがいらなくなることがあります。

そのときに要らなくなったものはちゃんと消しておかないとコード量がかさみ、コードの可読性が下がったりビルド時間が無駄にかかるようになったりといいことがありません。

今回はいらなくなったクラスを消すためのTipsをメモしていこうと思います。

まずは、Xcode上でできること。 ただし、この方法はObjective-Cにしか使えません。。

Related Items

View > Standard Editor > Show Related Items を選択すると、そのファイルに関係するクラスの一覧を確認することができます。

.hファイルで確認し Included By を見るとそのファイルを import しているクラスが一覧できるので、これを見て誰からも import されていないクラスは消すことができます。

誰からも import されていないクラスは以下のようにそのクラスの .mファイルしか表示されません。

ただし、注意が必要なのは、以下のようにstoryboardでビューの遷移が定義されている場合です

この場合でも Related Items > Included By にはそのクラスの .mファイルしか表示されないので、使われていないのかstoryboardからのみしか使われていないのか判別できません。

誤って消してしまうとアプリがバグってしまうので気を付ける必要があります。

ちなみにswiftも Related Items 自体は使えますが、Included By はグレーアウトされた状態になります。

次にサードパーティ製のツールを使う場合。

まずはObjective-C

fui (https://github.com/dblock/fui)

使い方は README に書いてあるとおりですが「fui find」を実行すると、使われていないクラスの一覧が表示されます。

こちらは先程の Related Item とは違い、storyboard上で使われていると一覧には表示されません。

次にSwift

fus (https://github.com/tsabend/fus)

これは上述の fui を参考にSwift版を作ったものだそうです。

こちらも使い方は README に書いてありますが「fus find」を実行することで使われていないクラスの一覧が表示されます。

また、こちらも fui と同様storyboardで使われている場合は一覧に表示されませんでした。

ただし、 fui / fus の注意点としては、storyboardでそのクラスが使われていたとしても、そのクラスへの遷移が定義されていない場合はそのSceneとクラスファイルがともにごみとなってプロジェクト内に溜まっていってしまいます。

例えば

もともと UINavigationControllerのRootとなっていたのはBだが、仕様が変りAにつなぎ直され、Bはstoryboard上で取り残されてしまった。

みたいなケースです。

このケースは fui / fus では探しきれないので自分でstoryboard内を探しにいかないとダメそうです。

そもそもそんな中途半端なことすんじゃねーって感じですけどね。

最後に使えなかった方法を一応メモ。

Build Settings > warnings - All languages で Unused Functions を YES にする方法。

そもそも Unused Functions はデフォルトで YES です。

名前的に使われていないメソッドの検索に使えそうと思ったんですが、これは Objective-C の .hファイルにメソッドが定義されているのにその実装がない場合に警告を出すものでした。

Build Settings > Other Warning Flags に何か使えそうなオプションは無いのかと探してみたのですがなさそうでした。（参考：Warning-Options）

まとめ

バシッと不要なコードを探して消せる方法っていうのはなかなかなさそうでした。

AppCodeを使うと使われていないメソッドに警告を出してくれる機能があるようですが（参考：Code Analysis）、私はXcode派なのでちょっと微妙。 Code Analysisの機能を使いたいときだけAppCodeを使うって手もあるかもしれませんが、これ有料なのでやっぱり微妙。

あと、実装方法について、遷移をstoryboard上で定義するのは保守性が低い気がしました。

遷移の実装に色んな方法があると検索性が落ちます。

また、storyboard上で遷移を定義すると下のスクショのような表示になりますが、矢印は全部ViewControllerの真ん中から同じように伸びていて、直感的にどこが起因となって遷移が発生するのかすごくわかりづらいです。

個人的には全ての遷移をstoryboard上で定義するには無理があるため全てコードで実装するように統一したほうがいいのではないかと思います。

自分一人で実装している場合や、保守しないアプリではstoryboardを使った実装は楽ですし良いのですが、長いこと保守するアプリでは当時の実装者がいなくなったり新しいメンバーが入ってきたりします。

そんなとき何がどこに実装してあるのかわからない状態だとコードに手をいれる際容易にデグレが起きます。

また、もう当たり前となっているかもしれませんが、storyboardは画面毎に分けたほうがいいです。

Storyboard上に複数画面を配置していると、上の例で出てきたようなSceneの取り残しが発生したり、画面が増えることでstoryboardを開くのも時間がかかるため、一つの画面を探すにも骨と心が折れます。

あとは基本ですが不要なコードはちゃんと消していくことを心がけたいですね。

あとで使うかもと思ってコメントアウトするのもやめたいですね。

そういう場合は一旦消してまた必要になったらgitのコミットログから遡ればいいと思います。

After the WWDC break, here is a summary of what is new in iOS11

A curious tool that uses AI to help you program. Stackoverflow on steroids?

While you are trying to grasp everything from the WWDC here is something to relax: hilarious suggestions to control the volume

Articles

Protocol composition in Swift and Objective-C, by @jesse_squires

Push Notifications Tutorial: Getting Started, by @j_vesza

Exploring the new String API in Swift 4, by @johnsundell

Capturing Values In Swift Closures, by @MarcoSantaDev

WWDC 2017: An In Depth Look At the New App Store, by @weareprolific

Even Swiftier Objective-C, by @steipete and @bukovinski

Tools/Controls

PinLayout, by @mirego

SplitViewDragAndDrop, @marioiannotta

Themes, by @onmyway133

Business

Agile at Scale – Outcome Driven (or Broken), by Tyner Blain

Storytelling Should Be the Number One Skill You Want to Improve, by @Jonwestenberg

How to Not Take Feedback Personally, by Claire Lew.

Why You Need to Build an MVP App (and 5 tips on how to do it), by Jessi Salonen

For an Inclusive Culture, Try Working Less, by @richarmstrong

UI/UX

A Checklist for Registration and Login Forms on Mobile, by @rbudiu

Best Practices for Modals / Overlays / Dialog Windows, by @msNaema

Credits

“Now this is how you compile something in Objective-C . . . but of course that isn’t how you do it in swift.”

“But why did Apple make it different on their own computers?”

// it is going to be... | Objective-C