2019年7月8日2019年も残すところあと6ヶ月。上半期はどんな感じでiOSアプリ開発をやってたかっていうのを書いておきます。SwiftUIとかCombineとかそういった話題はありません。関数型プログラミングのチュートリアルテストコードどのような対象にテストコードを書いているかおわりに開発用ツールXcodeGenデメリットはあるもののXcodeGenが圧倒的に便利です。XcodeGenを使いたかったかというとそういうわけでもありませんでした。XcodeGenをチームで採用しようというのは難しい判断になりそうですね。言ってたので反省した。2019もう少し細かく、自分の気持の移り変わりとしては次のような感じです。「複数人のプロジェクトでXcodeGenを運用する(短所をカバーする圧倒的な良さがあるやん!という気持ち)」という感じで結局導入してみたら長所が短所を圧倒的に超えてました。長所を並べてみるとXcode関係SchemeとConfigurationの仕組みを知ることになるわざわざSchemeで設定を変えるみたいな変なことやっててもConfigurationに差し替え可能Scheme間やConfiguration間の設定値の差分がコードなのでわかりやすいファイルが実ファイル順で並ぶので細かいことを気にしなくて良くなるマルチモジュールでも構成が把握しやすいgit関係プロジェクトのファイルがコンフリクトしなくなるので気にしなくて良くなる自分が複数ファイルを先に追加してコミットする際にもそのプロジェクトファイルを分割するという作業がない短所こういうとき、短所を言えないとちょっとあやしいですからね。短所を無理やり考えてみました。実ファイルからXcode上のグループを作るため、例えばテストターゲットのファイルをプロダクション用のファイルと同じディレクトリに入れられないこの短所は長所でもあります。「テストコード用のファイルなんて別でまとまってるほうがいい」「実ファイルとXcode上のファイルが間違って配置して混乱したら困るからそれを防げてる」とも言えます。Configurationに1つのxcconfigを指定するため、自前のxcconfigから複数のincludeしていかないといけない。cocoapodsのxcconfigをincludeするのもそのうちの一つですが、ちゃんと整理して全共通用のBase.xcconfig作ったりDebug.xcconfig/Release.xcconfigを作って無駄がないように導入したくなるわけです。これはまず表を作って設定ファイルを階層的に整理していくのがいいと思います。あとまあ、ブランチを変更した際にファイルが異なっていることがあると確実にXcodeGenを実行しないといけないというのも短所かもしれません。hooksでcheckout時に常にXcodeGenするようにしてます。installをhooksに入れてたのと同じですね。一部の設定を変更するぐらいならSchemeでやるべきではないがXcodeGenならそれも面倒でもない他にはScheme関係。これはもう根本的な前提の話なんですが、例えば通信先のホスト名など、プロジェクト内の変数を入れ替える場合にConfigurationで分けてよって思うわけです。これたまにSchemeで分ける人がいてそれめちゃくちゃ面倒なのでしょうと。基本的にSchemeっていうのは複数のConfigurationを保持できるわけです。execute.で、そういった大がかかりな仕組みでわざわざ変数書き換えるためにSchemeを使うっていうのはオーバーなわけですよ。してもSchemeで変数の書き換えを分けたいんだったら、まあXcodeGenでやるとそういうのも差分わかりやすいよねってことです。Configurationで分ければいいとは思うけど。mintmintはバージョン固定できるのが特徴です。XcodeGenのバージョンをチームで揃えたりするのにラクですね。brewで特定のバージョンにするっていうのは難しいですが、mintは特定のバージョンをインストールするのも、特定のバージョンで実行するのもラクです。1.2.4https://github.com/yonaskolb/MintつまりXcodeGenやるならmintも入れるかなとは思います。SwiftFormatswiftlintも使いますが、それはそれとしてSwiftFormatも使っています。gitのpre-commitのhooksに設定していて、commitするたびにcommitしたファイルを対象にSwiftFormatが動作しています。DesktopというMacのクライアントにはUndo機能があるため、コミットしたファイルに変更があるとSwiftFormatの変更点を確認しすぐUndoしてコミットメッセージそのままコミットし直すという感じです。3ヶ月に一回くらいSwiftFormatのルールを見直すっていうのが良いと思っています。SwiftFormatもmintでインストールして使うのがいいと思います。フォーマットルールのページは分かりづらいんで貼っておきますhttps://github.com/nicklockwood/SwiftFormat/blob/master/Rules.mdリアクティブプログラミングフレームワークRxSwiftは使うが限定的に使うRxSwiftは使う場面は入力イベントが複数あって出力も複数あるときと限定してますつまり通信結果を表示したいだけの画面などはRxSwiftは使わないおそらく世の中の大半のプロの方たちにも、Rxの概念は難しいと思います。一緒に開発するメンバーがリアクティブプログラミングについて、共通の見解を持つため絶対外せないのが「RxSwift研究読本」じゃないかと思います。RxSwift研究読本1RxSwift研究読本2RxSwift研究読本3関数型プログラミングのチュートリアルRx公式の関数型プログラミングのチュートリアルっていうのがありますhttp://reactivex.io/learnrx/すでにRxがわかっている人からしたら、Rxが採用する関数型プログラミングのアイデアってこれだよなーという感じです。それを知らない人からしたらちょっと意味がわからないかもしれない。「なぜforEachからmapとかfilterを作ってんの?」って気分になるかもしれないですが、その小さな部品を作ってまた組み合わせていく、それがRxが採用する関数型プログラミングのアイデアなわけです。これはちょっとRx慣れてからやるといいと思います。テストコードどのような対象にテストコードを書いているかなるべくViewControllerは(難してく)テストしたくないので、ViewControllerに処理を集めず、必然的にViewModelやPresenterに対してテストコード書いています。自分が作ったモジュールをテストコードで再利用して見直すライブラリは正しく使えてるかしかしこのメリットに対して、時間的コストをかけすぎるとメリットに対してバランスが悪くなるとは思います。一つの機能に対するテストコードを書くときに2時間以上かけない、という制約がないと、無駄にテストコードを書いてしまったり、なんかそもそもテスト対象が複雑すぎるということに気づくきっかけになるはずです。どんなコードを書けば上記の不安が解消するのかという根本を考えずにテストコードを書こうとするとかなり大変なことになります。具体的には単体テストで済む話なのに結合テストをしてMockをたくさん作らないといけないと思い込む、とかです。Quick/NimbleかXCUnitを使うかの選定についてはQuick/Nimbleが使いたけりゃやったらいいと思っています。単体テストでもQuick/Nimbleの表現力は魅力的なので、XCUnit使ってコメントを散りばめるぐらいならQuick/Nimble使えばいいと思います。その他、このテストコード無駄だなーと自分では思っても、テストコードの書き方を他のメンバーに示すコードとして意味がある場合もあります。明らかに無駄だなーと思って書いてるとミスに気づくこともあるのでまあメリットもある。無駄なほどテストコード書いていると、そのときはじめて時間をかけないということにたどり着けるかもしれない。...というのが上半期の感想です。おわりに今年後半どうなっていくかわからないんですが、年末にはまたこっからどうなったかがあれば書いてみたいと思っています。9月はiOSDC2019で「自作して理解するリアクティブプログラミングフレームワーク」が採択されたので話す予定です。どんなことをを発表するのかの細かいことはまた違う記事にしておきます。