WEB+DB PRESS Vol.106のAndroid/iOSアプリ設計を執筆しました #wdpress

平成最後の夏のWEB+DB PRESSである、WEB+DB PRESS Vol.106のAndroid/iOSアプリ設計をメルカリのエンジニア6人（@motokiee、@sota1235、@rkowase、@callipan、@86、@sue__71）で執筆しました。

WEB+DB PRESS Vol.106

WEB+DB PRESS Vol.106

自分は1章と2章の一部の執筆を担当し、iOSサンプルアプリ開発とAndroidサンプルアプリ開発のお手伝いをしました。Androidの方はガッツリ実装というよりもiOSとの差分の調整を行っていました。また全章くまなくレビューしています。

本ブログでは特集の見どころと、執筆の進め方について簡単にまとめてみました。特集を読んでいただけるとより楽しめるかと思うので、ぜひ手にとって読んでみてください。

モバイルアプリの設計に悩んだり、より良いコードを目指す方々の役に立つと幸いです。

特集の見どころ

設計という幅広いテーマを扱うので、どこまで盛り込むべきか/盛り込まないべきかを執筆メンバーでかなり議論した上でDI/MVVM/Fluxという構成になりました。

1章では本格的な解説に入る前に、モバイルアプリの設計はなぜ重要なのかを簡単にまとめています。また特集の解説のためのサンプルアプリも用意しており、その仕様についても解説しています。

特集を執筆するにあたって最もこだわったのは、共通の仕様でAndroidとiOSそれぞれのサンプルアプリを実装している点です。いまのサービス開発において、AndroidとiOSで共通の実装をすることは珍しくないというよりも、そうでない方が珍しいと思います。ただ、技術スタック的に両方を深いレベルで書ける人はそんなに多くないと思うので、執筆メンバーが豊富だったこの機会に実現できてよかったです。

現場でiOSの開発者はAndroidの開発者と、Androidの開発者はiOSの開発者と仕様について話し合うこともあると思うので、お互いの認識を合わせるのにも役立つのではないかと思います。

さて、1章でも記載していますが、2章以降は一貫して次のパターンで書かれています。

  • 設計パターンとその概念の解説
  • iOS/Swiftでの実装方法の解説
  • Android/Kotlinでの実装方法の解説

基本的には設計パターンとその概念についてをしっかりと理解することが重要だと思っています。iOS or Android特有の部分については必要に応じて学べば問題ないはずです。

それを踏まえて2章以降について簡単に説明します。

2章はDIパターンをテーマとしているのですが、最も長い9ページになりました。DIパターンは応用範囲の広い概念なので、これをわかりやすい言葉にすることに腐心しました。SwiftでもKotlinでも読めるに工夫をしているので、DIパターンがよく分からないという方はじっくり手を動かしながら読んでみてください。Swiftの解説ではSwiftの言語仕様を活用しながらDIパターン+抽象化を手厚く解説し、AndroidはDaggerを使って解説をしています。

3章はMVVM(Model-View-ViewModel)をテーマとしています。データバインディングのためにライブラリを導入しながらMVVMについて解説しています。iOSではRxSwiftをデータバインディングのために導入していますが、RxSwiftの詳細な説明はページの都合上少なめになっています。そもそもRxSwiftを導入すべきかどうかを議論し、RxSwiftについては最低限の説明にとどめ、MVVMの解説を手厚く行っています。

解説にまでは組み込めませんでしたが、個人的なこだわりとしてiOSのViewModelのテストをサンプルコードにしっかりと書いています。ViewModelのテストで困っている方の参考になるかもしれません。

4章はFluxアーキテクチャがテーマです。サンプルアプリはこの章で完成します。データフローを役割分担によってシンプルにすることで複雑な状態管理を解決しています。サンプルアプリの要件を整理しながら解説していて、その整理の流れを読んでいただけると実際の開発にも応用しやすくなると思います。

特集のまとめにも書いていますが、本特集で紹介したものをそのまま採用するのではなく、その知識をベースに工夫することをオススメします。

また、コードは一度書いたら終わりではなく日々進化していくものです。より良いコードへと進化していくことを前提にリファクタリングに励みましょう。

執筆の進め方

執筆はGitHub上で進められました。textlintやDangerを使って用語の統一を試みました。他にもPULL_REQUEST_TEMPLATE を使うなど仕組み化に力を入れてみたのですが、最後は人の手で頑張ることになったように思います。

プロの編集

今回は@inaoさんが編集をしてくださいました。もともと執筆経験のメンバーから「@inaoさんは厳しい」という話を聞いていてドキドキしていたのですが、噂通りの厳しさでした。

特集全体を通しての整合性や細かなワード一つに対するこだわりがすごくて、「これがプロの編集者なのか...!!」ということを身をもって実感することができました。技術書典で2回執筆したことがあるのですが、そのフィードバックとは全く違うレベルでした。

自分たちもコードを書くときは同じくらいのこだわりを持って書いているので、やはり神は細部に宿るのだな、ということをあらためて実感しました。

一方で一緒に執筆していたメンバーも同様にかなり厳しかったので、@inaoさんだけが厳しいというわけではありませんでした。

設計をテーマにすることは、ソフトウェアエンジニアの皆さんであれば分かると思うのですが、なかなかドキドキするものです。比較的マサカリを飛ばしやすいテーマでもあると思います。

そういう前提を執筆メンバー全員で共有できていたこともあって、各メンバーが緊張感を持って執筆に臨むことができたと思います。

自分の中では「厳しい」=「ツラい」ではないので、とても楽しむことができました。

まとめ

「執筆してみませんか」という話は社内で頂きました（補足するとバイネームではないです）。去年くらいまでは、普段の仕事+副業orカンファレンス運営という状況でとても執筆する気持ちにはなれずにいました（前述したように技術書典で少し書くくらいはやっていました）。

それでも執筆した理由は3つあって、1つは厳しいと評判の@inaoさんからお話が来ていたこと、もう1つは母親が「文章うまいんだから本でも書いてみたら」と昔から言われていたので親孝行になると思ったこと、そして最後はWEB+DB PRESSという歴史の一員になりたかったことです。

@inaoさんと関われたことはとても良い経験でした。論理を組み立てて一貫性を持った説明をするための視点は執筆に限らず役立つもので、そういった力を執筆を通して育むことができたと思います。

母親は「内容はよく分からなかった」ものの「家宝にするわ」と言っており、喜んでいることが窺えたので親孝行ができたと思います。

そして、WEB+DB PRESSという歴史の1ページに加わることができたのは本当に嬉しいです。執筆をしている過程で以下のスライドを見つけたのですが、WEB+DB PRESSは"エンジニアのハブ"です。

いままでたくさん読んできたことはもちろん、特集を書きながら過去のWEB+DB PRESSを読み返したり、知り合いの執筆経験者に連絡をとってアドバイスをもらったり、一緒に執筆しているメンバーと議論したりと「あぁ、WEB+DB PRESSはハブなんだ」ということを確かに実感しました。

読むこともそのハブに参加することなので、ぜひ読んでみてください。フィードバックお待ちしています。

最後に、ただでさえ忙しい中、一緒に執筆をしてくれた@sota1235、@rkowase、@callipan、@86、@sue__71に感謝！