Androidアプリ設計パターン入門を読んだ。製本版を買ったとばかり思っていたが、電子版で出資していた。思い込みとは恐ろしいものである。
せっかく出資して購入したのだから、もっと早く読んで（アーリーアクセス版で）疑問点なり質問すればよかったなと今更後悔している。
購入した動機は、設計に関する考え方を知りたかったからだ。
考え方というと勘違いされてしまうかもしれないが、○○という設計パターンはこういうところで優れている、なんてことを知りたかったわけではない。他の人（というか日本Android界を引っ張っていくようなエンジニアの方々）が、どういうことに困ってどういう思いで設計パターンを選んでいるのだろう、というところが知りたかったのである。
その観点から言うと、やっぱりみんな困るところは一緒なんだなぁということが分かってよかった。個人的には特に4章が興味深かった。
そもそも私自身はこれまでずっとソロで開発してきているので、チーム開発の話自体が新鮮である。みんなこういう感じで開発してるのかと、そういう雰囲気が感じられる事自体が何よりありがたい。そういう意味で買って（出資して）良かったなと思っている。
正直な話、ソロ開発する上ではどの設計パターンで作るかについて神経質になる必要はないと思う。最近の私は、とりあえずActivityのライフサイクルに振り回されないように作ればいいかな程度のゆるい考え方で、設計パターンの遵守より作りやすさを優先して作っている。
本書を読んでいて思ったのは、やはり設計パターンはチーム開発において重要になってくるものだということだろう。
どの章も、チームでの開発の視点で描かれている。設計パターンの導入とチームでの開発は切っても切り離せない問題なのだ。
本書は、Androidにおいてこの設計パターンで作れば間違いがない、このパターンこそ最強であるからこれをやっておけ、という内容にはなっていない。だから、結局どのパターンを学んでおけば安泰なのか知りたい、という観点で読むと肩透かしを食らうと思う。
そもそもそんな銀の弾丸があるなら、みんながそのパターンで作っているはずだ。
私は本書を読んでいて、Fluxパターンはなんか良さそうだなと思ったのだけど（データの流れを一方通行にするというところと、状態を保持するStoreが独立してるってところが良さそうに感じた）、じゃあこのパターンでリストのスクロール位置を保存しようと思ったらちょっと大仰すぎやしないかと感じる。スクロールの度にActionを発行して、Storeの状態を更新していくのだろうか。onSavedInstanceSateで位置を保存するだけでいいんちゃうのと思ったりする。
そんなわけで銀の弾丸はない。どの設計パターンを学べばいいですかっていう人にはもしかしたら合わないかもしれない。
Android開発においては、どんな設計パターンがどういう問題を解決するために使えるのか、どういう作り方をするのかという考え方を学んでおくしかない。自分が他のチームにジョインした時に困らないように。
これからチーム開発を行っていけるようにするためには、どういう問題を解決するためにどんな設計パターンが存在していて、どんな感じにAndroidに適用してくのかの考え方を知っておくことが大事だと思う。その考え方について、本書はMVP、MVVM、Fluxといった設計パターンを、著者の考え方とあわせて書かれているので、独学で勉強していますとかチーム開発の経験がない人ほど有用であるように思う。少なくとも、ずっと独学で勉強してきた私にとってはとても有用な内容だった。
具体的にどうやって実装していくかなんて言うのは自分で手を動かしてみないとわからない。本書で大事なのは著者の頭の中身が覗ける（考え方が赤裸々に書かれている）ということである。
ああ、私も誰かと一緒にアプリ開発したい（切実）。
Android アプリ設計パターン入門 著者：日高 正博,小西裕介,藤原聖,吉岡 毅,今井 智章, 製本版,電子版 PEAKSで購入する
今までプログラムの全体像を頭の中でイメージし、後は勢いでコーディングして完成させるという作り方をしてきていました。大規模なプログラムを作ることがなかったので、今まではそれで何とかなっていたのですが、最近それも限界を感じています。
Androidのアプリを作るのに、画面がどう遷移してどういう処理が必要で・・・なんていうことを頭の中だけでは把握できません。
それに勢いだけでコーディングしていると、このクラスが一体何の働きをしているのかが分からなくなってきます。作成中はまだ大丈夫なのですが、時間が経つともうわけがわからなくなります。
1分間タイマーは勢いだけで作り上げましたが、もう機能修正とか追加とかやりたくありません。どこで何やっているか自分でも訳がわからないからです。
そんなわけで、設計方法を学ぼうかななんて思って行動を始めました。
頭の中だけでプログラムをイメージするのには限界があるので、少なくとも設計図を用意したい。設計図を作るには、どういうふうにプログラムを組み上げていくのがいいのか、その手法を知る必要がある。という感じです。
とりあえずUMLの書き方さえ知らないので、UMLの入門書を読んで、ついで実践UMLという本を図書館で借りてきて読みました。
とりあえずわかったのはこんな感じですかね。
UMLが書けることとクラス設計ができることは別の話 最初に完璧な設計書を用意するという考えは間違ってる とりあえずやってみないと始まらない UMLの書き方をマスターしたからといって、それだけでは設計書を作ることはできません。個人開発で使う分には、最低限自分が分かればいいので、細かいUMLの書き方をマスターしようとするのはちょっと脱線しすぎかもしれません。
プログラムの設計図を完璧に仕上げてからコーディングをしていくというのはウォーターフォール的発想だからやめろと実践UMLには書いてありました（意訳）。オブジェクト指向開発的には、もっとフレキシブルに設計とコーディングを行き来しながら開発していくんだそうで。
確かに、どういう作りにすればいいのかと完璧な設計を求めるあまりに、プログラムが完成しなければなんのための設計なんだという話になりますもんね。まあ今の私がそうなんですけど。
実践UMLを読んで感じたのは、内容がかなり濃い＆難しいので、とりあえず前半くらいの内容を利用して実際に設計→コーディングのサイクルを回していくのがいいのだろうと思いました。どう作っていけばスマートなのかを考えだすとキリがないので、とりあえずやってみなければ始まらない。
アプリの機能、要件を定義して、そこからどういうクラスが必要なのかを検討して、実際に作ってみる。上手くいかなければ設計しなおして、やり直す。もっといい作り方がないかなとか追い求めると何もできなくなってしまうので、とりあえず作る。そんな方針で進めてみようと思います。
それと並行して設計方法についても勉強したいなと思っています。何かおすすめがあれば教えていただきたいです。
実践UML 第3版 オブジェクト指向分析設計と反復型開発入門
