関心の分離と単純化のためのSwiftコードの最適化 | try! Swift Tokyo 2018 Day1-5

関心の分離は、コードが再利用されないときには時期尚早な最適化とみなされることがよくありますが、我々がコードが何をしているのかを理解することに対しては大きく影響します。Swiftにおけるこの実例を紹介します。

関心の分離と単純化のためのSwiftコードの最適化

f:id:niwatako:20180301115747j:plain

ハビエル、もしくはハビと読んでください

f:id:niwatako:20180301115939j:plain

大規模チームで仕事をしています。コードレビューが大好きです。

f:id:niwatako:20180301115947j:plain

たくさんのコードをレビューします。コードベースの品質は大切だと思っています。また同僚のコードを読んで学べます。

フィードバックを

f:id:niwatako:20180301120135j:plain

各コードをどう単純化するか

f:id:niwatako:20180301120113j:plain

コードを書く時に、書くよりも読む時間が長いということです

あまり時間を書けずにやることもあるかと思います。

自分自身で課しているのは将来を考えて自信に質問をしながらコードを書いていくこと。

他の人からの共感も得ることができます。

関心の分離によって理解しやすくなります。

Swiftでやることで、拡張子やEnumと言うツールを使って動きを抽出し結果としてコードの動きがどのようになるかをみていく

コードの重複の例

f:id:niwatako:20180301120325j:plain

文字列の長さをカウントしていく。そうすると何らかのリミットを超えていく。 これを指摘すると、コードを抽出して抽象化しても意味が無いという人もいますが、カウントを二回やることで、詳細を明瞭にしていく。

形できちんとした数をカウントしていくことができる

3ヶ月後になぜUTF16 をつかってカウントしたかを分かるようにすることが重要

String上で拡張することも可能です

f:id:niwatako:20180301120442j:plain

バックエンドで実装されているからです

Objective-Cならカテゴリで行うこともできます。

こうしたシンタックスを使うほうがくどくなります。

AppleのNameSpaceとの衝突ということが起きてくる

3ヶ月後にこうした振る舞いをしたと行ったことを、意図をわかっているということになる

例を使って単純化したいと思います。先程の質問を問いながら考えていきましょう

f:id:niwatako:20180301120548j:plain

より簡単にするにはどうしたら良いでしょう

読めなくはないが読むことは難しい

このコードの最適化ということで考えると、最初はそんなに長いものではない。featureを追加していくことで、コードの後ろのロジックが不明瞭になるうことがある。

PostReplyということで他のコードでリプライを書きます

f:id:niwatako:20180301120653j:plain

Extensionにロジックを切り出します。

詳細を抽出して、この場合コレクションのフィルタリングをかけるということを行っています。

これはAutoLayoutの例です

f:id:niwatako:20180301120746j:plain

何を達成しようとしているかわかりますか?

ゴールは単純ですがシンタックスが多いことで不明瞭です。

AppleAPIの改善をしていますがまだまだ余地があります

同僚もいろいろなヘルプをしています

f:id:niwatako:20180301120823j:plain

特に我々にとっては使われるものになります

実際作成されているコードを単純化している。

もっと改善の余地があります。

f:id:niwatako:20180301120902j:plain

Constraintを起動してSuperViewに一つのViewを億 コードの行数だけでなく、コードを明確に伝えることが改善になります

目的を伝えて想像しなくていいということになる

f:id:niwatako:20180301120948j:plain

動的にレイアウトをアップデートしている enableとdisable

既知の文字列

f:id:niwatako:20180301121035j:plain

エラーを起こしやすい、テーブルビューに変更を掛けるとエラーを起こしやすい

データのところで

f:id:niwatako:20180301121101j:plain

こちらの事例

f:id:niwatako:20180301121120j:plain

ゴールはコードを抽出して変数の後ろに置くということです

f:id:niwatako:20180301121143j:plain

UserDefaultに変数を作る。

f:id:niwatako:20180301121203j:plain

こういったコードがあるアプリをたくさん目にしました ViewについてはLayoutGuidのSafeAreaが11しか対応していないが9から対応する時このようになる。独自のレイアウトガイドを作ることができる

独自のSafeAreaGuideを作った

f:id:niwatako:20180301121248j:plain

広報互換性を持った新しいAPIに紐付けることで古いAPIと同じ振る舞いをすることができる。 どのアプリでもコードを書くことができるようになる

タップに従って大きさを返ることはしたことがあるでしょうか

f:id:niwatako:20180301121341j:plain

小さすぎたら押しやすいように44×44に広げることをあちこちでしていた

そこでSubClass

f:id:niwatako:20180301121431j:plain

ヒットテストをいれて、タップ可能な表面を拡大している

こうしたクラスを作れるということがここでのポイント。

最近使い始めたのですが

f:id:niwatako:20180301121519j:plain

タップに応じてレイアウトを隠したりするといろいろ気にすることがある その代わりにStackViewを使う

最後に数週間前に手掛けた実例

たくさんのユーザー情報を使ってユーザー情報を生成しなければならなかったがIDだけでできるように鳴った

f:id:niwatako:20180301121702j:plain

f:id:niwatako:20180301121719j:plain

プロパティをすべてオプション化する オプションのViewとして個別に対応しなければならずエラーの確率が上がっていたが、自動になって有用

f:id:niwatako:20180301121756j:plain

特定のときだけ値を使う UIがその状態にあるときだけ関連付けられたViewが表示される

f:id:niwatako:20180301121847j:plain

状態の値がどこか変わると変わる

Stateの値はどのViewを見せるかということでアップデートしていく

まとめです。

私たちはコードを読むのにかなり時間をかけています

f:id:niwatako:20180301121926j:plain

面白かったら、ためになったら

  • はてなブックマークSwift タグをつけてブックマーク!
  • 「インターネットで生活を楽しく豊かにしたい」仲間を募集しています
  • Bitcoin: 3KGqXtR1ZaGVdkvcw8CCNrkDxDhdbZBYHL