Design It! ―プログラマーのためのアーキテクティング入門
- オライリージャパン (2019年11月25日発売)
- Amazon.co.jp ・本 (404ページ)
- / ISBN・EAN: 9784873118956
作品紹介・あらすじ
ソフトウェアアーキテクトのビギナーに向けて、アーキテクトの役割から、アーキテクトの仕事に必要な知識を網羅的に解説した書籍です。アーキテクチャ設計のコンテキストが現代のソフトウェア開発に合わせられています。
感想・レビュー・書評
-
ソフトウェアアーキテクチャについて書かれた一冊です。
ソフトウェアアーキテクトの役割、設計の基礎、品質特性、アーキテクチャパターン、アーキテクチャのドキュメント化、評価、チームへの共有、そしてそれらに関するアクティビティ一覧など、幅広く書かれています。
特定のパターンについてではなく、アーキテクチャというテーマで一冊書かれており、勉強になる内容が多かったです。
ステークホルダーやチームとの関わりについても書かれているのが実践的でよかったです。
ただ、どうしても抽象的な話が中心にはなるので、開発の初心者にはわかりづらいかもしれません。
また、途中で出てくる例が正直わかりづらいです。
アクティビティ一覧はおもしろそうと思いつつ、実際にやってみないことにはなにも得られないままになってしまうので、なにかしらチームでやってみるといいと思います。
と書きつつ、自分はどのアクティビティも試せておらず、どうやって実際のプロセスに組み込むかは難しそうです。詳細をみるコメント0件をすべて表示 -
プロジェクト遂行のストーリーに沿って、よくあるアーキテクチャの問題を判断、解決していく内容で読みやすかった。
個人的には、特に ADR (Architecture Decision Record) が参考になった。その技術を選んだ理由、他の候補、見直すタイミングなどをドキュメント化しておくことで、保守や次期リプレースの際にとても役立つと思った。
ストーリーの中で、ステークホルダー同士の会話などがあると更に理解しやすいと感じた。 -
これは強烈に良かった。どれくらいかというと、電子書籍で読み終えてからさらに物理書籍を注文してしまうくらい。
IBMで培われたアーキテクチャードキュメントの作り方と、そこから現実的に削ぎ落とす部分とを、いい塩梅にして示してくれていて実践的に感じる。
とても好き。
ちなみにこのタイトルは〜It!というシリーズの中の一冊らしい。 -
アーキテクチャを実践するために必要な、非技術的な振る舞いまでを含めた入門書。
いかにしてビジネスと紐付けたアーキテクチャをつくりあげるか、評価するか。そういった側面にかなりの分量を割いている本書は、現実世界と向き合うアーキテクトにとっての頼もしい道しるべとなりそうだ。
個人的には、選ばれなかったアーキテクチャを記録しておく、設計の評価をコードレビューで行うといったアクティビティに強く興味をもった。
これらは新規に作り上げるソフトウェアだけでなく、レガシーと化したソフトウェアと向き合うにあたって威力を発揮しそうだ。
基本的には非エンジニアでも読める内容、かつ非エンジニアであっても概念を理解しておくことが望ましいものだと感じた。時折出てくるテクニカルタームに怯まず、手にとってみてほしい。 -
今のところ、拾い読みしただけ。
デザインパターンとアーキテクチャパターンの違いの説明が役に立った。著者はその区別はそれほど重要ではないと言っているが、初学者が混乱しやすい点でもあると思う。
7章のアーキテクチャパターンについては、必要に応じて読むようにしたい。 -
アーキテクティングに関する本。
BDUF(Big Design Up Front)でもNDUF(No Design Up Front)でもなくENUF(Enough Desing Up Front)を行うことを推奨している。そのために、デザイン思考的なアプローチをアーキテクティングに取り入れよう、というのが本書の目新しい部分か。
現在アーキテクトとして働いている人だけでなく、これから学ぼうという初学者も対象だと書かれているが、実際にはある程度のアーキテクチャ設計経験がないと難しいかもしれない -
純粋に技術的なアーキテクチャがどうこうというよりは、チームビルディング/デザイン的な内容が主体です。
個人的にはチームリーダー的な人にはとてもオススメ。チームでできるプラクティスなども充実しており、手元に置いておきたい一冊でした。 -
読みやすい。
ほぼ素人の自分でもわかりやすかった。 -
アーキテクチャというと開発者のためのものというイメージだったけど、ステークホルダーみんなのものだと気づかされた。
ステークホルダーマップから、コンテキスト図、機能仕様、品質特性など、実装を通じて、選択してきた数々の設計判断などのすべてがアーキテクチャを形成している。
アーキテクトに必要なのは孤高にそびえ立つ、象牙の塔を描く才能ではなく、アンダーエンジニアリングでもオーバーエンジニアリングでもない最適な制約を見出す、継続的な行動、コラボレーションだ。
広く理解し、深く探求して蓄えた暗黙知を、形あるものとして作成し、評価することを継続し続けることでいい塩梅を保つことができる。
そのための、時間の使い方、マインド、コラボレーションのための銀の道具箱に詰めた38のアクティビティが紹介されている。
それなりに大きなシステムなのにアーキテクチャがいまいちだなともやもやしているなら、短時間でもいいので気に入ったアクティビティに投資してみよう。
1時間の設計が1ヶ月のコーディングに相当するということを実感できるんじゃないかな。
(経験則から言うと、それ以下の効果になりやすく、それ以上の効果が得られることはほとんどない気がしている) -
エンジニアなら読んで損はしない一冊。
設計やアーキテクチャーに興味がある人なら序文〜1章あたりで勇気づけられる人は多いはず。
アーキテクティングを象牙の塔にせず、いかに民主化していくかといった話題は参考になる。
システムを作り上げていく過程で行うアクティビティが辞書的に紹介されているのもありがたい。