言語など

• 今までのバックグラウンドが大体動的な言語がほとんどなので、型が便利だと思う半面、書いているときはちょっと面倒さを感じる。 
  • Rubyに比べてコードは冗長なんだけど、最初にザクザク書いていけばIDEなのであとから補完されていくので、トータル書いてる時間がすごく増えたとかはないと思う。
  • 型推論が便利
• 今はSwiftが持っているポテンシャルの10％くらいしか引き出せていないので、Swiftという言語にちゃんと入門する必要がある。
  • 静的型付き言語の気持ちにならないといけない。
  • ExtensionとかProtocolちゃんと使えている気がしない。
  • コレ読む予定 

    • 

      [改訂新版]Swift実践入門 ── 直感的な文法と安全性を兼ね備えた言語 (WEB+DB PRESS plus)
      • 作者: 石川洋資,西山勇世
      • 出版社/メーカー: 技術評論社
      • 発売日: 2018/01/17
      • メディア: 単行本（ソフトカバー）
      • この商品を含むブログを見る
    • 
      
• やっぱりUIKitとかのドキュメントがわかりにくくて、UITableViewControllerでいつも必要になる三種の神器（Cell個数指定、Cellの中身定義、Cell選択時のコールバック）をいつも忘れてググってQiita見て満足しちゃっている。
  • 翻訳しながらでもいいので、公式ドキュメントの方をちゃんと読んだほうがいいよな。。。という気持ちになってる。
  • しかしまぁ、情報量はRailsに負けないくらい多い。（きっとRails以上だよね。）
• Storyboardにまだまだ慣れない感じはする。ただ、4年前にやったときよりも理解はできているので手応えは感じる。

ライブラリなどの雑感

• CocoaPods使ってる。
• JSのときの学びだけど、あんまりUIデザインにべったり依存する部分のライブラリは入れないようにしている。
• QiitaでよくUIColorのhexを再実装したりしているけど、そういうことはしないでちゃんとライブラリから探してみるようにしている。

アーキテクチャ

• 今の所ソロプレイの予定なので、アーキテクチャはどうしようか悩み中。
• MVPかMVCか。
• サーバーサイド開発（特にRails）と違ってレールがないので、自分でレールを作る必要がある。
• 実際に4画面くらい書いた感想は、多分何も工夫しないで実装していくとViewControllerのコードが膨れ上がって死ぬな、これは。。。という気持ちになってる。
• まず、アーキテクチャよりもSwift自体の気持ちになってコードを書く必要があるかも。それで適切な責務のMVCでも十分イケる可能性もある。
• ただ、画面遷移を管理するRouterがほしいなという気持ちになってる。 
  • たんにUIView -> UIViewへの移り変わりでなく、WebViewの特定のURL -> ネイティブアプリ起動 みたいなことをやりたかったりするので、ライブラリ導入前に捨てる実装前提で、簡易的なRouter書いてみようかなと思っています。
• 画面遷移しても共有したいObject（ログイン済みユーザーの情報等）があったりするので、雑にXXXXManagerってSingleton作って使ったりしてしまったので、多分勉強が足りないと思っている。 
  • せめてデータフローは1方向にしたいな…
• アーキテクチャを選定するにはアプリケーションコードを全然書いていないので、どんどんプライベートでもアプリ作ったりコードを書いたりしないとヤバイ…と思ってる。
• これは読んだ。いい本だと思うけど理解が浅い気がしていて、あと半月したらもう1週する peaks.cc

テスト

• まだ数画面なので書いていない。
• アーキテクチャをちゃんと決めてから出ないと、どうテスト書くかみたいな戦略が未熟な故作戦が立てれない。

Firebase

• とにかくモバイル開発に必要な周辺ツールがほぼココに揃っていて便利。最高。
• とりあえずAnalyticsとかCrashlyticsとかPerformance Monitoringとか突っ込んでおいた。

まとめ

• ここから半月から約1ヶ月間、プライベートでも含めてコードを書きまくってインプットしていかないとちゃんと書ける気がしないんで、ちゃんと頑張っていこう。。。