try! Swift 2018 参加レポート

iOSエンジニアのaboyです。先日東京で行われたtry! Swift 2018のday1, day2に参加しました!

とっても刺激的な2日間でしたが、今回はいくつかのトークの感想などを書いていこうと思います。

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

@Javi
https://github.com/JaviSoto/Talks/tree/master/TrySwiftTokyo2018

他の人が読んで”共感”することができて、何を達成しようとしているのかが明瞭であるようなコードを書くべきである、とのことでした。

書籍「リーダブルコード」などを読んで上記のことは頭では理解してるつもりでしたが、重要性を再認識する機会になりました。また、発表の中であげていたいくつかの最適化例のうち、アイスタイルでも意識して行なっているものがあったのは良かったです。

たとえばUITableViewを用いたリスト表示においてRowの種別をenumで管理する工夫や、 Userdefaultsを色んな層から直接操作せずにget/setを用いたラッパープロパティを用意する工夫、Viewにおける状態管理の持ち方の工夫などです。

アイスタイルではViewの状態管理は、それ用のProtocolを作って(社内ライブラリ化して)利用しています。

また、UITableViewについては、特にSectionによって要素数が動的に変わったりするような場合や、汎用的なヘッダーを差し込んだり○件以上要素があれば「もっとみる」を表示するような要件のUITableViewの場合も同様に、Section管理を分離させています。enumはとても便利ですよね。

final TableViewController: UITableViewController {

    private enum Section {
        case profile
        case sitemap
        case company

        var rows: [Row] {
            switch self {
            case .profile: return [.content(.profile)]
            case .sitemap: return [.header, .content(sitemap)]
            case .company: return [.header, .content(.guide), .content(.company)]
            }
        }

        enum Row {
            case header
            case content(ContentDetail)

            enum ContentDetail {
                case profile
                case sitemap
                case guide
                case company
            }
        }
    }

    private var sections: [Section] {
        return [.profile, .sitemap, .company]
    }

    override func numberOfSections(in tableView: UITableView) -> Int {
        return sections.count
    }

    override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        return sections[section].rows.count
    }

}

Should coders design

@zats

コーダーがデザインすべきなのか、というタイトルから、発表前はデザイナーとエンジニアの役割分担の話かと思っていましたが、聞いてみると本質はそこではありませんでした。発表内容は、デザインとは何か、なぜ重要なのか、我々エンジニアがデザインにどう関わっていくかというような内容で、デザインの意義を再認識するとともに、僕たちの作っているアプリをもう一度見直すきっかけとなるようなものでした。

また、デザイン検討段階でデザイナーに技術的に何が可能/不可能かを理解させることは重要だと言っていて、本当にその通りだと思いましたし、エンジニアにしかできないことなので使命感をもって取り組みたいです。

発表内であげていたいくつかの良いデザイン例はどれもユーザー側からすると当たり前に思えるようなものですが、実際にアプリを開発しているとだんだん視野が狭くなってきて気づけないことも多いので、定期的に思い出したい発表でした。

SwiftエンジニアのためのKotlin

@designatednerd

アイスタイルでもちょうど、「1日ちょっとでもいいからkotlinに触れてみよう!!」という”kotlinタイム”を設けるなど、kotlin導入の取り組みもなされているため、興味がありました。

別言語についての発表ではありましたが、iOSエンジニアとAndroidエンジニアが同じアプリエンジニアとして近い距離感で助け合いながら動いているアイスタイルのiOSエンジニアとして、Kotlinの話題は自分ごととして捉えるべきだと思いますし、Kotlin意欲がふつふつ湧くような内容でした。

UIImageView vs Metal

@shu223

try! Swift 2018では普段あまり意識することのないlow-levelに焦点を当てた発表がいくつかあり、そのなかで一番身近に感じた発表がこちらでした。

まず発表自体がとってもわかりやすかったです!!!

また、普段何気なく書いている処理がCPU/GPUどちらで動いているのか、正直気にしたことがなかったぼくにとってはとても新鮮で、新しい気づきとなりました。

こちらは発表が終わった後に質問をしてUITableViewのパフォーマンス改善について有益なアドバイスをいただくことができました。UITableViewのパフォーマンスはほぼ全ての画面で気にしなければいけないことなので、注意していきたいです。

スポンサーブースも楽しかったです!

発表はもちろん、スポンサーブースで他企業のエンジニアとお話しするのも楽しかったです!

ヤフーさんのブースではペアプロを用いたTDDの実演を行なっていたので30分ぐらいずーっと見ていました。

ヤフーさんのエンジニアの方が言っていたこの開発手法のメリットのうち、「自然と個々人がアプリ全体の機能・実装について詳しくなる」というメリットがとくに魅力的に感じました。アイスタイルでもちょうどアプリ全体の機能(仕様)の把握が課題としてあがっていたので、解決策のひとつになりうるかもしれないと思いました。

またGameWithさんのブースでは、アイスタイル同様最近技術ブログを始めたとのことだったので、勝手に親近感を覚えたりしました。

あと印象的だったのは畳のスペースでスプラトゥーン2を遊んでいた人がいたことです、とっても楽しそうで思わず写真撮りました。

おわりに

ぼく自身はtry! Swift初参加でしたが、とても楽しく、学びと刺激のある2日間でした。素晴らしいイベントを作ってくださってスタッフなど関係者の方々には感謝でいっぱいです。

まだまだ知らないことだらけだということが再認識できたので、これから一層勉強していきますし、業務にいいかたちで繋げていければと思います。

iOSエンジニア、新卒入社4年目 社内腕相撲大会で優勝しました Flutterが趣味