特に、オブジェクト指向の原則、プラクティスなど開発者に
とってかなり有意義な内容だと思う。
他の本でも似た内容がちらばっていることはあるが、原則、
プラクティスとしてまとまっていると理解しやすい。
欲を言えば、デザインパターンの部分が多すぎるから、減らして
安くしてほしかった。
無料のKindleアプリをダウンロードして、スマートフォン、タブレット、またはコンピューターで今すぐKindle本を読むことができます。Kindleデバイスは必要ありません。
ウェブ版Kindleなら、お使いのブラウザですぐにお読みいただけます。
携帯電話のカメラを使用する - 以下のコードをスキャンし、Kindleアプリをダウンロードしてください。
アジャイルソフトウェア開発の奥義 単行本 – 2004/6/30
ロバート・C・マーチン
(著),
瀬谷 啓介
(翻訳)
めまぐるしく変化する仕様要求にさらされながらも、迅速さを実現する「アジャイル」ソフトウェア開発。アジャイル(俊敏)性・柔軟性の達成に必要なコンセプトを1冊に凝縮。エクストリームプログラミング(XP)を含む一貫した開発プロセスを提示します。
- 本の長さ690ページ
- 言語日本語
- 出版社ソフトバンククリエイティブ
- 発売日2004/6/30
- ISBN-104797323361
- ISBN-13978-4797323368
この商品をチェックした人はこんな商品もチェックしています
ページ 1 以下のうち 1 最初から観るページ 1 以下のうち 1
商品の説明
出版社からのコメント
Software Development誌Jolt Award受賞の名著の邦訳です。
内容(「MARC」データベースより)
めまぐるしく変化する仕様要求にさらされながらも、迅速なオブジェクト指向開発を可能にする「アジャイル(俊敏)」開発を実現するために必要な3つのコンセプト(原則・デザインパターン・プラクティス)を凝縮した一冊。
登録情報
- 出版社 : ソフトバンククリエイティブ (2004/6/30)
- 発売日 : 2004/6/30
- 言語 : 日本語
- 単行本 : 690ページ
- ISBN-10 : 4797323361
- ISBN-13 : 978-4797323368
- Amazon 売れ筋ランキング: - 611,422位本 (本の売れ筋ランキングを見る)
- - 433位情報学・情報科学全般関連書籍
- - 12,359位電気・通信 (本)
- カスタマーレビュー:
著者について
著者をフォローして、新作のアップデートや改善されたおすすめを入手してください。
著者の本をもっと発見したり、よく似た著者を見つけたり、著者のブログを読んだりしましょう
著者の本をもっと発見したり、よく似た著者を見つけたり、著者のブログを読んだりしましょう
著者の本をもっと発見したり、よく似た著者を見つけたり、著者のブログを読んだりしましょう
カスタマーレビュー
星5つ中3.4つ
5つのうち3.4つ
全体的な星の数と星別のパーセンテージの内訳を計算するにあたり、単純平均は使用されていません。当システムでは、レビューがどの程度新しいか、レビュー担当者がAmazonで購入したかどうかなど、特定の要素をより重視しています。 詳細はこちら
7グローバルレーティング
虚偽のレビューは一切容認しません
私たちの目標は、すべてのレビューを信頼性の高い、有益なものにすることです。だからこそ、私たちはテクノロジーと人間の調査員の両方を活用して、お客様が偽のレビューを見る前にブロックしています。 詳細はこちら
コミュニティガイドラインに違反するAmazonアカウントはブロックされます。また、レビューを購入した出品者をブロックし、そのようなレビューを投稿した当事者に対して法的措置を取ります。 報告方法について学ぶ
-
トップレビュー
上位レビュー、対象国: 日本
レビューのフィルタリング中に問題が発生しました。後でもう一度試してください。
2004年9月22日に日本でレビュー済み
Amazonで購入
2021年9月20日に日本でレビュー済み
オブジェクト指向とデザインパターンがわかているとスラスラ読める本です。
しかし残念ながら、日本ではこの本が役に立つ現場は、ほぼありません。
・アジャイルを真似たOOPのないプロジェクト
・アジャイルだとソフトウェア開発が楽になると夢見るプロジェクト
・アジャイル開発の内容を履き違えたプロジェクト
・デザインパターンを知らない者が集まるもともこもないプロジェクト
基本は、OOPで言われる「クラスの再利用で短納期を実現」がクラスの再利用率が20%未満だったため、この本が書かれました
なので、OOP、デザインパターンは必須です。
しかし、現場ではプロジェクトやクラス図を書くことなく「アジャイル実践」がまかり通っています。
この本が伝えるべきことはそっちのけで、「アジャイル」という言葉だけがひとり歩きをし、各現場でのアジャイルが違うという事実を受け入れなければなりません。
しかし残念ながら、日本ではこの本が役に立つ現場は、ほぼありません。
・アジャイルを真似たOOPのないプロジェクト
・アジャイルだとソフトウェア開発が楽になると夢見るプロジェクト
・アジャイル開発の内容を履き違えたプロジェクト
・デザインパターンを知らない者が集まるもともこもないプロジェクト
基本は、OOPで言われる「クラスの再利用で短納期を実現」がクラスの再利用率が20%未満だったため、この本が書かれました
なので、OOP、デザインパターンは必須です。
しかし、現場ではプロジェクトやクラス図を書くことなく「アジャイル実践」がまかり通っています。
この本が伝えるべきことはそっちのけで、「アジャイル」という言葉だけがひとり歩きをし、各現場でのアジャイルが違うという事実を受け入れなければなりません。
2008年7月11日に日本でレビュー済み
この本を読むまで、はずかしながらSingletonってなんのことか知りませんでした。
16章の「singletonパターンとMonostateパターン」を読んで、はじめてああ、そうだったのかと知りました。
実際に、わかるようになったのは、TOPPERSプロジェクトのコンポーネントWGで、シングルトンという単語を耳にするようになり、内容、振舞などを検討するようになってからです。
Singletonは単一生成、monostateは単一状態なのですね。なぜ、みんな日本語で言わないのでしょうか。たしかにプログラムで書く用語は、プログラムの用語のままの方がよいことはわかります。でも、翻訳するのなら、日本語に翻訳すれば、意味がわかって、説明が同じ量でわかります。そのため、singleton(単一生成)、monostate(単一状態)でよいでしょうか。single, monoの語幹の意味の違いがまだよくわかっていません。
翻訳しない単語は、意味をわかるために、説明を訳注として追加してくださると幸いです。
単語の意味がわかれば、もうすこし理解が進むと感じました。
実際には開発しながら理解しないとだめだということ納得しました。
16章の「singletonパターンとMonostateパターン」を読んで、はじめてああ、そうだったのかと知りました。
実際に、わかるようになったのは、TOPPERSプロジェクトのコンポーネントWGで、シングルトンという単語を耳にするようになり、内容、振舞などを検討するようになってからです。
Singletonは単一生成、monostateは単一状態なのですね。なぜ、みんな日本語で言わないのでしょうか。たしかにプログラムで書く用語は、プログラムの用語のままの方がよいことはわかります。でも、翻訳するのなら、日本語に翻訳すれば、意味がわかって、説明が同じ量でわかります。そのため、singleton(単一生成)、monostate(単一状態)でよいでしょうか。single, monoの語幹の意味の違いがまだよくわかっていません。
翻訳しない単語は、意味をわかるために、説明を訳注として追加してくださると幸いです。
単語の意味がわかれば、もうすこし理解が進むと感じました。
実際には開発しながら理解しないとだめだということ納得しました。
2004年8月21日に日本でレビュー済み
全体的なアジャイル開発の進め方、という意味では割とあっさりとした、でもポイントは抑えた内容かな、と思いました。
素晴らしい点は、
開発の重要なポイントは「コードを書くこと」という観点で、
OOPの原則、デザインパターンの説明をしつつ、
アジャイル開発らしく、
「実際に動く」「変更を受け入れる」「簡潔なコード」を
重視した実装をどのように進めていくかが、
とてもよく解説されています。
「基本」と「応用」を一体化させたような印象で、
まさに「奥義」とはこういうことを言うのかもしれない、と感じました。
素晴らしい点は、
開発の重要なポイントは「コードを書くこと」という観点で、
OOPの原則、デザインパターンの説明をしつつ、
アジャイル開発らしく、
「実際に動く」「変更を受け入れる」「簡潔なコード」を
重視した実装をどのように進めていくかが、
とてもよく解説されています。
「基本」と「応用」を一体化させたような印象で、
まさに「奥義」とはこういうことを言うのかもしれない、と感じました。