『チームで育てるAndroidアプリ設計』を読んで
見出し画像

『チームで育てるAndroidアプリ設計』を読んで

じょい


はじめに

この記事はPRです。

エンジニアとしての先輩であり、飲み友達であり、この本の執筆者である釘宮さんに献本いただきましたので、レビューを書きます。

まずは釘宮さん横幕さん執筆お疲れ様でした!この本はもちろんですが、Android界隈において定期的に登壇やアウトプットを続けておられること、本当に尊敬します。


読んだ視点

自分は既にAndroidエンジニアと名乗れる者ではなく、過去に2-3年ほどAndroid開発に従事し、現在はサーバサイドやフロントエンドなど主にwebサービスの開発に携わっている立場になります。なので感想もAndroid寄りのものではないです。

ただ、私のようなエンジニアって案外いるのではないでしょうか?この本について、いまはもうAndroidやってないから全く理解できない〜ということはなかったよと言いたいです。事例はAndroidなので、代表的なアーキテクチャ知ってるという方は理解できるのではと思います。

Android開発未経験という方や、これから頑張りたい方はまず用語が分からないと思うので、理解が難しい部分が多いでしょう。ですがその際はPEAKSから出ている以下の本も合わせて読んでみると良さそうです。

別の本の話をしちゃいました。では本題です。

本の構成について

まず、前提として本書はAndroidのアーキテクチャ自体を学ぶものではなく、各々のチームでどう取り入れ運用していくかという話になります。アーキテクチャ、チームで頑張りたいけどどう進めていったらいいか分かんない!そんな課題を解決してくれる本だそうです。

全9章で構成されています。ざっくりと書くと以下です。

・1-4章:新規開発でのアーキテクチャについて

・5-8章:大規模開発でのアーキテクチャについて

・9章:新規と大規模の違いについて理解を深める

1-4章について

新規開発でのアーキテクチャとはこうすべきだ。の前に、そもそも新規開発ってこういうものだよねというところからです。ある程度ルールがないと秩序は乱れてしまう。まるで社会全体みたいな話からスタートします。アーキテクチャの必要性を理解しながら読み進めることができます。アーキテクチャを構成していく過程やチームとしてどう向き合って行くのか。また、それをどう広げていくかといった方法まで説明されていました。

以下、個人的に印象に残った箇所です。

・2章-2:選定の過程

会社のルールが選定の過程に入っていたので、一般的な本でなかなかこの視点無いかもと思いちょっと親近感がわきました。

・3章-2:選定したアーキテクチャを浸透させていく

ここにはサンプルコードを用意する事例があり丁寧すぎるとびっくりしました・・・。今までそのようなチームに入ったことはないという意味です。自分も当然やったことないです。やっていかなきゃですね。

5-8章について

チームは変化しつづけるという状態や、新メンバーが来たときなんていう大規模開発あるあるな状況が書かれていました。また、アーキテクチャはどのようなことを想定して作るべきか、そしてチーム全体で納得して進めていく中でそれはどういう効果を持つか。チームを取り巻く環境がリアルでとても読み進めやすかったです。

以下、個人的に印象に残った箇所です。

・5章-2:大規模開発をうまく進めるために必要な要素

多くのエンジニアに参考になりそうです。ちょっと意図とは違うかもしれませんがリーダブルコードを思い出しました。

・7章-1の辺りから:アーキテクチャと日常的な改善の課題について

その両方どう取り組むかという話が始まりますがこの章は一気読みしちゃいました。個人的には新規開発よりは大規模〜中規模の開発に途中からjoinすることがこれまでの経験上多かったので、共感性が刺激されました。立て続けに課題が羅列してある箇所は、経験を元に書いてあるだけあってリアリティがあります。

全体として

経験が多分に盛り込まれています。普段このような視点でプロジェクトを回しているのかと勉強になりました。

ルールは作って終わりではなく、その先を見据えている思想は繰り返し書かれていたので、お二人ともここを特に大事にされているのだなと伝わってきました。設計って自分たちのチームだけのものという意識で考えたり作ったりしますが(そもそも広めるという意識が自分は欠如している・・)、その考えを見直せるような気持ちになると思います。

9章に「成長痛を軽減」という熱いワードが出てきますが、かなり印象に残りました。成長痛とはこの本では、人の入れ替わりやプロダクトの規模の変化(=つまり時の流れに伴う様々な要因で起きる痛み)を指します。成長痛どころか骨折みたいな現場も多く存在するかもしれませんが、ここも必読です。(あ、全部必読です)

お二人のアウトプットや界隈での評判が頭に入っている状態でこの本を読んでいるので、ちょっと盲目的にさすがという感想になってしまいました。また、ここまでなるには自分はかなりの時間を要しそうだとも感じました。ただ、構成についての部分で先に書いた通り、この本の目的もプロジェクトどう進めていったらいいか分からない!そもそも時間がねえ!というような思いを解決するというものでした。きっとエンジニアとして抱えている問題について、解決のヒントになることも多いはずです。

自分の話

少し私の話になぞらえて感想を書いてみます。Androidの話ではないですがちょっと当てはめて考えてみました。私のいまの状態としては4月にちょうど新しいチームにジョインした状況であり、まさに今システムを知っていこうとしています。

さてどんな体制で、どんなシステム構成で、フレームワークは何を使っているのかな?コード規約は?デプロイのフローはどうなっているのか?いろんな視点があると思います。「ざっくりドキュメント見ておいてもらえると助かります。」みたいなときに、たしかに見ておくことはできますが、隅から隅まで読んでおくといった意味ではないでしょう。

どう効果的に見ていくかという意味では、この本にあるような視点でこれから担当するシステムやチームの体制を見てみようと感じました。

例えばどんな部分を制限しどこは制限されていないか。そのプロジェクトが進められる背景や、いまはどういうフェーズか。完璧な体制であるチームはなかなかないんです。どう作っていくか考えましょう。

目論見としてはこの本の恩恵をうけて、いい視点もってるねなんて言われたらいいなと思ったりしてます。笑

さいごに

ぜひ!




この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!
スキありがとうございます!
じょい
エンジニアしてます。平日にお休みをとって美術館に行くことがすきです。