Swiftの世界的カンファレンス，try! Swiftが3月2日～4日の3日間にわたり，渋谷のサイバーエージェントのオフィスにて開催されました。

本イベントの興味深いセッションをいくつか，日ごとにレポートしていきます。まずは1日目のレポートです。

Laura Savinoさん「コードリーディングについて」

新しいコードを読み解くことを，私たちはしばしば行いますが，それはエネルギーと時間を消費します。Laura Savinoさん（@savinola）は，スラスラと新しい言語を読めるようにする方法と，進化についていく方法を話しました。

コードを解読することは大変！

コードを読んで，さらに解読するにはエネルギーと時間を要します。そのコストを下げるために意識しているポイントとして，Lauraさんは以下の3つを紹介しました。

スラングを避ける

人間の言語におけるスラング，これは知っている人しか知らない表現です。プログラミング言語においてもスラングを避けることで，平易な文となり読みやすさを上げることができます。

過度な短縮系を避ける

過度な短縮系はすぐに理解できず，読むのにエネルギーを使う必要のある表現です。「⁠書いた人にしか読めないコードはやめよう」と述べていました。

カスタムオペレータを避ける

カスタムオペレータもエネルギーが必要な表現です。

共感を大切にする

「なぜこのコードが読めないんだ？」とチームメンバーに対して思ってしまうこともあるかもしれませんが，それは自分が悪いという可能性もあります。そんな時は共感を持つ必要があると，Lauraさんは指摘します。相手にとって読めないのであれば「コード上でどこの情報が欠けているのか」を考える必要があります。

これまでに述べてきたコードの解読の必要性をなくすことで，コードに対する議論の余地がなくなります。Lauraさんは，「⁠ほんのちょっとした部分であっても，チームメンバーにとって読みづらいコードがどこかに存在してしまうことは良くない」と述べていました。

Q&Aインタビュー

セッション後，LauraさんにQ&A形式のインタビューを行いました。

• Q: セッションでも言及していましたが，C言語タイプのforループについて，プログラミング初学者にとってはfor-inよりもforループのほうが読みやすいのではないかと思います。これについてどのように考えますか。

  A: チームの目標をどこに設定するかがカギだと思います。大切なのはセッションでも言及しましたが，共感です。その上で，チームの目標設定に対してチームメンバーにとってどんなコードにするべきかがわかるキーパーソンの存在が大切だと思います。良いコードも悪いコードも知った上で判断できる人は重要です。

• Q: プログラマはこの種の話題が大好きだと思いますが，最近のホットトピックは何かありますか。

  A: 若干VCにコードが寄りがちかもしれないけれどMVCモデルで作っていくのか，それとも小さなコンポーネントに細かく切り分けて作っていくのかという話題が最近ありました。それぞれにメリット・デメリットはありますが，チームメンバーが共感して納得できるところを探すことが大切でした。

Q&Aの回答にあったように「チームの目標をどこに設定するか」というのが重要です。コードを書く時にはチームでコーディング規約をまとめておいたり，だいたいは使い回ししたりということが多いよう思いますが，チーム結成時やスタートのタイミングで都度「今回のプロジェクトで意識するところはここだよね」という認識をチームで共有するタイミングを持ち，その都度書き方を改めていくということが大切なように思いました。なににおいても前提とすることをメンバーと共有するということは大切なので，今後より意識していこうと思います。

Gwendolyn Westonさん「平常心で型を消し去る」

型を明確にすることがSwiftらしいやり方であると気づいた時，同時に時には型を消す必要があると分かります。Gwendolyn Westonさん（@purpleyay）の講演では，型とは何か，型を消すことが何を意味するか，なぜそうしたいかについて解説しました。

型とはなにか？

型には2種類あります。「⁠Concrete Type」と「Abstract Type」です。

Concrete Typeはインスタンス化できる型のことです。データを保持し，オブジェクト間でやり取りを行います。 Abstract Typeはインスタンス化ができず，データを保持したり具体的な処理を行ったりできません。抽象的な振る舞い，挙動を表すのがAbstract Typeです。

protocolでGenericsを使うには？

Gwendolynさんはポケモンを題材に説明していきました。サンプルコードはこちらです。

ポケモンの振る舞いを持つprotocol Pokemonがあって，そのProtocolに準拠したstruct Pikachuやclass Charmanderがあります。ここで，ポケモンごとに技のタイプが違うのでタイプを分けてインスタンス化することを考えます。その際にGenericsを使おうとしても，PokemonはProtocolなのでSwiftの言語仕様上，Genericsで定義できませんし，なによりProtocolはAbstract Typeなのでインスタンスを生成できません。そこで使用するのがどんな技のタイプのポケモンも扱えるclass AnyPokemonだと紹介。このAnyPokemonは型引数となるPokemonTypeの中身がどんな実装であれインスタンス化することができる特徴を持っています。ここが型消去の部分になります。そしてAnyPokemonのinitの中でattackメソッドの引数の型を固定する実装になっていると説明しました。

Q&Aインタビュー

セッション後，GwendolynさんにQ&A形式のインタビューを行いました。

• Q: 参考になるサイトなどがあれば教えてください。

  A: 一つは，実際のコードとしてReSwiftというライブラリのこの部分に使われています。また，以下の3つのサイトも参考になりますよ。

  • Generics in Swift, Part 2
  • Swift: Associated Types
  • GENERIC PROTOCOLS & THEIR SHORTCOMINGS

このセッションの前は「Swiftは型が強い！」という認識がありました。そのため，できるだけタイプセーフに型を意識したコーディングをするように心がけていましたが，このセッションを聞いて型を意識したコーディングをするにはより型について知り，柔軟性をもった書き方をできるようにしていくことが大切であるということに気づきました。こんな書き方があるんだなと，勉強になりました。