投稿元:
レビューを見る
主に、非機能要件に焦点をあてて、さまざまな手法を紹介している。
ただ、具体的にこうすればよいという指針を示しているわけではない。
文章の構成が、とあるセミナーを舞台とした講師と参加者のやり取りから成り立っているので、堅苦しくなく読みやすいと思う。
自分は、品質に関するいくつかの手法の紹介が役に立った。機会があれば深堀してみて、実践投入しようと思う。
アーキテクトってどんなことを考えるべきなのか、どういう役割を担うべきなのかなどを知りたい人には、参考になる本である。
投稿元:
レビューを見る
ソフトウェアアーキテクチャを構築するに当たって、アーキテクトが何を知るべきなのかをかなりの毒とユーモアを交えて解説している。
そういう点でユーモアを理解しない人や、技術書というのは小難しく、まじめに書かれていないと気が済まないという人にはお勧めしない。(まぁそういう人は表題と表紙で既に手に取らないんだろうけど。)
内容的にはソフトウェアアーキテクチャとは何かを俯瞰した後に、要求開発(とは著者は言っていないんだけど)、人間の不可解さや曖昧さをソフトウェアとして記述できる様にするための手法として形式手法の紹介、ATAMという手法によるソフトウェアアーキテクチャに対するインスペクションの方法の紹介、アーキテクチャに対するメトリクスの手法としてのDSMの紹介、そしてまとめという構成になっています。
個人的にはATAMとDSMについては何も知らなかったので、すごく参考になったのと、DSMは実際のツールとしてかなり使えそうな感じがしています。
まぁ副題にある様にソフトウェアアーキテクトを目指そうなんて頭のイカレタ人間が目指すものなので(マテ)そういった頭のイカレタのが読むには気楽に読めて、かつ内容も深い感じでいい思うよ。
投稿元:
レビューを見る
アーキテクチャの設計、構築をするための基礎を仮想的なセミナー形式で説明しています。ジョーク交じりで教科書的な書とは一線を画しており、楽しく読めます。
投稿元:
レビューを見る
共感をもって最後まで読んだ。
説明がうまいなぁと思った。
この本にかかれていることはだいたい理解している人向けの本だと思う。
「あぁ、そうだよねぇ。」とか、「やっぱりそうなんだ。」とか、「そうそう!」とか、そういう共感が得られないと、「砕けた文章がずっと書かれているけど、内容は薄いよなぁ」とか、思っちゃって満足できないような気がする。
共感をもつことによって、自分に自身がつく。
自分だけじゃなくて、海の向こうのアーキテクチャが同じように考えていたってことがわかったことが、この本を読んでの収穫だ。
説明がうまいので、後輩に説明するときにこの本を引用すると楽ができるような気もした。
訳者がかなりの意訳をしている部分が多々あるような気がする。
原書も読みたいと思ったが、Amazonや紀伊国屋の検索とかでは見つからなかった。
投稿元:
レビューを見る
きれいごとじゃない、本音がちりばめられていて、共感。この本に出てくるキーワードを起点に、アーキテクチャの勉強を始めて見るのもよいかも。
投稿元:
レビューを見る
アーキテクチャやプラットフォームなどという言葉が流行っていますが、
本書はソフトウェア工学におけるアーキテクチャを
敷居が低く表現する努力をしています。
ソフトウェア工学そのものが進化の過程であり、
(近年進化しているのか?
以前に戻っているのか疑問に感じるところもありますが。。)
完全な正解がないと考えています。
為になったことを列挙しておきます。
・形式主義
・メトリクス
・DSM
投稿元:
レビューを見る
[○11/05/29完読]強く共感できて面白かった。意外だったのは欧米でもこういう感性でアーキテクトという職責を観ている部分があるということ。もしかしたら著者自身が日本での仕事経験があるためかもしれない。それにしても日本でアーキテクチャ関係をやっていればより深く共感できるかもしれない。欧米と日本でどれくらいの温度差があるのかはこの本からは不明だった。あと、正直、スライドに重要性があるとは思えない。最後のDSMは私もよくやる。
投稿元:
レビューを見る
海外のユーモアのノリがあわないとつらい本かもしれない。
会話形式で書いてあるので、内容は濃くないけど、
逆にアーキテクチャについて堅苦しくない感じの本は
あまり見たことがないので貴重だと思う。
投稿元:
レビューを見る
アーキテクトとして活躍するトム・エンゲルバーグさん著。そしてSpringユーザ会で、WebLogic勉強会で有名な長谷川裕一さん、土岐孝平さんによる翻訳です。
「間違いだらけのソフトウェア・アーキテクチャ」とは私にとってとってもしっくり来るタイトルです。
建築でもソフトウェアでも同じだと思いますがアーキテクチャというのは唯一の解があるものではなく、同じ目的・機能を実現するのに幾通りもの方法があります。
正解がたくさんあるのと同時に、目的・機能を実現出来ていながら明らかに不正解と言えるアーキテクチャもあります。
この本は後々ボロを出さないためにも「間違いだらけ」にならないアーキテクチャを決定するための著者なりの方法論や経験が書かれています。
ただ、方法論といっても堅苦しいものではありません。アーキテクトとしてのベストプラクティスについてのセミナーの様子を一冊の本にまとめたという設定で、筆者の視点から饒舌に語られています。
さらにセミナー受講者としてシニア・マネージャやSE、宇宙人(!)など様々な立場の人が登場し、様々な角度からの質問をぶつけてくるのに対して軽妙な語り口で筆者が答えていくという面白いスタイルになっています。
経験豊富な筆者の話をあるある(笑)、と読み物として楽しむのも良いですし、筆者の経験を疑似体験して実際の開発に役立てるのも良いと思います。
体系的に方法論を学べる本ではありませんがどのようなレベル、立場の方でも何かしら得るものがある本だと思います。
私は最近エンジニアでないお客様に見積もりの提示やその根拠の説明をしなければならないことが多いのですが、本書でクローズアップされている「非機能要件」の定義についてはちょっとヒントを貰えた気がします。
なんだかざっくりとした書評になってしまいましたが、フランクな文体で書かれており肩の力を抜いて読める面白い本です。
# そのフランクな文体が長谷川さんと土岐さんを悩ませたことと思いますが・・・
ちなみにトム・エンゲルバーグさんは Java のスペシャリストみたいですが本書は特に Java に特化した内容ではありません。モダンなオープン系システムの開発に携わっている方であればすんなりと読めるはずです。
投稿元:
レビューを見る
会話形式(?)なので気軽に読める。
アーキテクトというものに対して漠然としたイメージしかなかったが、この本を読んでその感覚が意外と間違ってないんだなと思った。
具体的な技術は紹介程度で、アーキテクトの全体像と考え方、環境などについて書かれた本。
投稿元:
レビューを見る
著者のユーモラスあふれるセミナーに参加しているかのように、対話形式で書かれており、ワクワクした気持ちで読める。
アーキテクトとは?アーキテクトが知らなければならない事や、プロジェクトの立ち上げから評価、派生開発に至るまでの一連の流れが書かれている。
話しと言っても概要レベルなので、詳細はネット等で調べる必要があるけど。
■派生開発のでは、清水さんが継承しているXDDPが紹介されている。海外でも有名になってきているんですね。
直接コンサルを受けた人間にとってはとても嬉しい事だ。
■実装ガイドライン、コーディング規約を用意して、おのおのが勝手なプログラムを作らないようにする。
■アプリケーションアーキテクチャを大きく分けると、物理層と論理層に分けられる。論理層にあるフレームワークなどは枯れて安定しているが、論理層はそのドメインによってビジネスロジックが異なるためしっかり設計する必要がある。 しかしこういう所は、外注やオフショアに出したりしている。
投稿元:
レビューを見る
アーキテクトっていうのはこういう事している、というのが分かる本。
話の中で、オブジェクト指向やらコンピュータの歴史、Webの歴史などを引き合いに出している。
セミナーで話をしている、というスタイルで本を書いているので、技術書と言うよりかはほとんどエッセイ。
読みやすいといえば読みやすい。
投稿元:
レビューを見る
読み物として。
これだけ読んで勉強になるような内容ではないが、ものすごく気軽に読み進められる。
生の声というか現職のアーキテクトが考えていることに触れられるので、別途勉強したことや知識などが身近に感じられるようになりより理解が深まる。
投稿元:
レビューを見る
会話形式で進むので、一見読み進めやすいが、内容がいったりきたりして、理解はしづらい気がする。
休憩時間に読んで、アーキテクトについて、なんとな~く知るには丁度良い。ユーモアのセンスもあるし。
なんとな~く知っておいて、細かいことについて気になったら他書を読む、という使い方が良さげ。
投稿元:
レビューを見る
「第4章 品質特性シナリオ」が一番参考になりました。そこには、こんなことが書いてあります。
まず簡単に言うと、アーキテクチャは、基本的に機能要求と非機能要求、そして制約条件と前提条件などから導かれる。ちょっと補足すると、前提条件は「お金はいくらでも使って良い」というプラスの条件、制約条件とは「予算は100万円以内」とかマイナスの条件のことって僕は区別している。
品質特性シナリオには重要な品質特性ごとに、これから作ろうとしているモノ(成果物:artifact)に対して、誰が(刺激の発生源:source of stimulus)、どんな時に(環境:environment)、どんなことをすると(刺激:stumulus)、どういう結果が(応答:response)、どれくらいで返ってくるか(応答測定:response measure)を描くんだ。
注意してほしいのは「誰が」っていうのは必ずしも人ではないってことだ。
あと「どのくらいで返ってくるか」というのも時間だけじゃない。資金などのコストやアンケート結果のパーセンテージってこともある。基本的には定量的に測定できなければならないんだけどね。
それと、これは一般的な品質特性シナリオにはないんだけど、僕は誰が(刺激の発生源:source of stimulus)ってところい、どんな状況(status)なのかっていうのも、付け加えたりするんだ。こいつは、最近のシステム利用者っていうのが、空調の効いたデスクの快適な椅子に座ってパソコンからシステムにアクセスしているだけじゃなくなってきているからなんだ。たとえば、システム利用者が屋外にいて走っていたり、自宅のソファに寝転がって画面を横にして見たりとか、そういうことも考慮する必要があるからなんだ。つまり、こうした追加項目がないと、モバイルを端末にするって話が出てこないんだな。
これを読むと、アーキテクトがアーキテクチャを作る前に分析していることってテスト技術者がテスト分析(テスト要求分析)で分析している内容と同じなんだということが分かります。
ということで、テスト関連の人は、第4章を読んでおくといいですよ。おすすめです。