目的
これから、人にも引き継いでいくので、ルールを作っていく。
ブラッシュアップは定期的に行っていくs
関数や、変数名の付け方
キャメル記法（ロウワーキャメルケースってやつ）で。いまそうなってないやつは今後直していきます。
参考：https://blog.e2info.co.jp/2015/09/24/namingrules/
役割を明確に
commonディレクトリや、utilディレクトリは禁止
長くなってもいいから役割を明確に。
〜Utilとかはなるべく使わない。
色々な機能が入らないように、プログラムが短くなるように（目標200行）名前を考える。
ただし
realmのモデル名は、ロウワーキャメルケース
propertyの定義は、スネークケースで！
NSUserDefaultsの扱い
UDWrapperを使ってください。
https://gist.github.com/fwhenin/b770228a982230bd8690
Unwrapped optionalは原則禁止
アプリが落ちる原因になりやすいので、不要の場合は使わない。
IBOutlet系の定義時などやむを得ない場合のみ。
依存性の低い作りに
protocol.delegate,callbackを駆使して、依存性の低い（単体テストをしやすい作りに。）
データベース
Realm一択。現時点では。
UnitTestコードはなるべく書く。
あまり頻繁に修正が入らないところはなるべく書いてね。
testing framework
XCUITest/XCTest
ネットワーク系はmockを使う。
https://gist.github.com/joemasilotti/7ff31584c0b6981a8f41
作る上で上記を参考にした
インスタンス変数にあまりBoolは使わない。
そのうち、そのフラグがなにを意味するかわからなくなりそうなので、避けられるときは避ける。
なるべく関数内のローカル変数で頑張ってほしい。
使い方に気をつける。といった意味が近いかも。
classメソッドで解決できるものは、classメソッド
singletonインスタンスで解決できるものはsingletonで
AppDelegateに定義するものは、protocolを用意する
アプリで共通に使うものは、classメソッド,singletonでやる。
Appdelegateでインスタンスを生成してもできるけど、
AppDelegateにインスタンスを大量に置くと、controllerでAppDelegateだらけになり、
可読性が下がり、依存性が高くなるので、あまり良くない
単体テストをしやすくするために、protocolを使う。
IBoutlet系は、weak
strongにすると、循環参照が発生する
InterfaceBuilderにあるやつを、swift側で参照するだけなので、weakで十分。
メモリ管理で不安な場合
ちゃんと、オブジェクトが終了したときに、終了したことをデバッグで確認する
具体的には、一番簡単（でもめんどいよ）の方法が、
各クラスに
deinit
メソッドを追加して、こちらがコールされるか確認する。例えば、Aって画面を閉じるときに、
Aのdelnitが呼ばれていない=メモリが残り続ける
ので、一番最悪なパターンは、電池の減りが早くなることに繋がる。
→lldbで確認する手もあるっぽい。
protocolとdelegate
宣言する際の用途によって、後ろに~protocol/~delegateにするか決める。
処理を委託するなら
~delegate
インスタンス変数は
weak var delegateXxxxx: XXXXXdelegate?
interfaceやtraitみたいな使い方をするなら
protocolとする
汎用性の高そうなものが開発中に出来た場合
targetを分けて、そちらに移し、後々FWできるか検討する。
gitのsubmoduleを使う。
社内で作った、FWはgitのsubmoduleで取り込む
使い方はこちら。(修正中)
iOSのフレームワークを作ってみる
ある機能に対してのprotocolは追加するものと同じgroup(ディレクトリ)に配置する
その前提で進めてみて、うまくいかないようであれば、別で管理するところを作るなどする。