著者をフォローする
何か問題が発生しました。後で再度リクエストしてください。
OK
レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス (日本語) 単行本(ソフトカバー) – 2019/9/19
David Scott Bernstein
(著)
著者の作品一覧、著者略歴や口コミなどをご覧いただけます
この著者の 検索結果 を表示
あなたは著者ですか?
著者セントラルはこちら
|
永瀬 美穂
(翻訳)
著者の作品一覧、著者略歴や口コミなどをご覧いただけます
この著者の 検索結果 を表示
あなたは著者ですか?
著者セントラルはこちら
|
-
本の長さ300ページ
-
言語日本語
-
出版社オライリージャパン
-
発売日2019/9/19
-
寸法21 x 15 x 2 cm
-
ISBN-104873118867
-
ISBN-13978-4873118864
よく一緒に購入されている商品
こちらもおすすめ
ページ: 1 / 1 最初に戻るページ: 1 / 1
- カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで単行本(ソフトカバー)
- テスト駆動開発Kent Beck単行本(ソフトカバー)
- 現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法単行本(ソフトカバー)
- Clean Architecture 達人に学ぶソフトウェアの構造と設計Robert C.Martin単行本
- Clean Code アジャイルソフトウェア達人の技単行本
- ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本単行本(ソフトカバー)
Kindle 端末は必要ありません。無料 Kindle アプリのいずれかをダウンロードすると、スマートフォン、タブレットPCで Kindle 本をお読みいただけます。
Kindle化リクエスト
このタイトルのKindle化をご希望の場合、こちらをクリックしてください。
Kindle をお持ちでない場合、こちらから購入いただけます。 Kindle 無料アプリのダウンロードはこちら。
このタイトルのKindle化をご希望の場合、こちらをクリックしてください。
Kindle をお持ちでない場合、こちらから購入いただけます。 Kindle 無料アプリのダウンロードはこちら。
商品の説明
出版社からのコメント
■「ITエンジニア本大賞 2020」技術書部門大賞を受賞しました(2020年2月)
内容(「BOOK」データベースより)
レガシーコードとは、バグを多く含み、壊れやすく拡張が難しいコードを指します。このようなコードの保守と管理には多大な労力がつぎ込まれることになります。しかも一度作ってしまったレガシーコードの質を上げるには、初めから質の高いコードを作るよりも膨大なコストがかかります。本書では、ソフトウェア開発において、初めからレガシーコードを作りださないためのプラクティスを9つ挙げて解説します。プロダクトオーナーは目的を語り、やり方は開発者に任せること、小さなバッチで開発を進めること、継続的に統合すること、チームメンバーで協力することなど、日々の開発に取り入れる考え方と具体的な実践について各章で分かりやすく解説します。信頼性や拡張性が高いソフトウェアをリリースしたい開発者、運用管理者、マネージャに必携の一冊です。
著者について
David Scott Bernstein(デビッド・スコット・バーンスタイン):IBM、Microsoft、Yahooを含む何百もの会社の何千人もの開発者とソフトウェアを作る情熱を共有してきた。彼の会社To Be Agile社は、テストファースト開発、ペアプログラミング、リファクタリングといったエクストリームプログラミングのプラクティスをチームに適用するのを助けている。
著者略歴 (「BOOK著者紹介情報」より)
バーンスタイン,デビッド・スコット
IBM、Microsoft、Yahooを含む何百もの会社の何千人もの開発者とソフトウェアを作る情熱を共有してきた。彼の会社To Be Agile社は、テストファースト開発、ペアプログラミング、リファクタリングといったエクストリームプログラミングのプラクティスをチームに適用するのを助けている
吉羽/龍太郎
株式会社アトラクタFounder兼CTO/アジャイルコーチ。アジャイル開発、DevOps、クラウドコンピューティングを中心としたコンサルティングやトレーニングに従事。野村総合研究所、Amazon Web Servicesなどを経て現職。認定チームコーチ(CTC)/認定スクラムプロフェッショナル(CSP)/認定スクラムマスター(CSM)/認定スクラムプロダクトオーナー(CSPO)。Microsoft MVP for Azure。青山学院大学非常勤講師(2017~)
永瀬/美穂
株式会社アトラクタFounder兼CBO/アジャイルコーチ。受託開発の現場でソフトウェアエンジニア、所属組織のマネージャーとしてアジャイルを導入し実践。アジャイル開発の導入支援、教育研修、コーチングをしながら、大学教育とコミュニティ活動にも力を入れている。産業技術大学院大学特任准教授、東京工業大学、筑波大学非常勤講師。一般社団法人スクラムギャザリング東京実行委員会理事
原田/騎郎
株式会社アトラクタFounder兼CEO/アジャイルコーチ。アジャイルコーチ、ドメインモデラー、サプライチェーンコンサルタント。Scrum@Scale Trainer/認定スクラムプロフェッショナル(CSP)。外資系消費財メーカーの研究開発を経て、2004年よりスクラムによる開発を実践。ソフトウェアのユーザーの業務、ソフトウェア開発・運用の業務の両方を、より楽に安全にする改善に取り組んでいる
有野/雅士
株式会社アトラクタアジャイルコーチ。アジャイル開発、DevOps、クラウドコンピューティングのコンサルティングやコーチを行っている。認定スクラムプロフェッショナル(CSP)/認定スクラムマスター(CSM)/認定スクラムプロダクトオーナー(CSPO)。一般社団法人スクラムギャザリング東京実行委員会理事(2016~)(本データはこの書籍が刊行された当時に掲載されていたものです)
IBM、Microsoft、Yahooを含む何百もの会社の何千人もの開発者とソフトウェアを作る情熱を共有してきた。彼の会社To Be Agile社は、テストファースト開発、ペアプログラミング、リファクタリングといったエクストリームプログラミングのプラクティスをチームに適用するのを助けている
吉羽/龍太郎
株式会社アトラクタFounder兼CTO/アジャイルコーチ。アジャイル開発、DevOps、クラウドコンピューティングを中心としたコンサルティングやトレーニングに従事。野村総合研究所、Amazon Web Servicesなどを経て現職。認定チームコーチ(CTC)/認定スクラムプロフェッショナル(CSP)/認定スクラムマスター(CSM)/認定スクラムプロダクトオーナー(CSPO)。Microsoft MVP for Azure。青山学院大学非常勤講師(2017~)
永瀬/美穂
株式会社アトラクタFounder兼CBO/アジャイルコーチ。受託開発の現場でソフトウェアエンジニア、所属組織のマネージャーとしてアジャイルを導入し実践。アジャイル開発の導入支援、教育研修、コーチングをしながら、大学教育とコミュニティ活動にも力を入れている。産業技術大学院大学特任准教授、東京工業大学、筑波大学非常勤講師。一般社団法人スクラムギャザリング東京実行委員会理事
原田/騎郎
株式会社アトラクタFounder兼CEO/アジャイルコーチ。アジャイルコーチ、ドメインモデラー、サプライチェーンコンサルタント。Scrum@Scale Trainer/認定スクラムプロフェッショナル(CSP)。外資系消費財メーカーの研究開発を経て、2004年よりスクラムによる開発を実践。ソフトウェアのユーザーの業務、ソフトウェア開発・運用の業務の両方を、より楽に安全にする改善に取り組んでいる
有野/雅士
株式会社アトラクタアジャイルコーチ。アジャイル開発、DevOps、クラウドコンピューティングのコンサルティングやコーチを行っている。認定スクラムプロフェッショナル(CSP)/認定スクラムマスター(CSM)/認定スクラムプロダクトオーナー(CSPO)。一般社団法人スクラムギャザリング東京実行委員会理事(2016~)(本データはこの書籍が刊行された当時に掲載されていたものです)
登録情報
- 出版社 : オライリージャパン (2019/9/19)
- 発売日 : 2019/9/19
- 言語 : 日本語
- 単行本(ソフトカバー) : 300ページ
- ISBN-10 : 4873118867
- ISBN-13 : 978-4873118864
- 寸法 : 21 x 15 x 2 cm
- Amazon 売れ筋ランキング: - 6,424位本 (の売れ筋ランキングを見る本)
- カスタマーレビュー:
この商品をチェックした人はこんな商品もチェックしています
ページ: 1 / 1 最初に戻るページ: 1 / 1
- SQLアンチパターン大型本
- ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本単行本(ソフトカバー)
- アジャイルサムライ−達人開発者への道−単行本(ソフトカバー)
- 入門 監視 ―モダンなモニタリングのためのデザインパターンMike Julian単行本(ソフトカバー)
- データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理Martin Kleppmann単行本(ソフトカバー)
- 正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について単行本
カスタマーレビュー
5つ星のうち4.3
星5つ中の4.3
51 件のグローバル評価
評価はどのように計算されますか?
全体的な星の評価と星ごとの割合の内訳を計算するために、単純な平均は使用されません。その代わり、レビューの日時がどれだけ新しいかや、レビューアーがAmazonで商品を購入したかどうかなどが考慮されます。また、レビューを分析して信頼性が検証されます。
トップレビュー
上位レビュー、対象国: 日本
レビューのフィルタリング中に問題が発生しました。後でもう一度試してください。
2019年9月21日に日本でレビュー済み
違反を報告
Amazonで購入
ちと3千円という価格に躊躇したが買ってよかった。アジャイルでもwater fallでも情報はwebや本に溢れている。でもそれらは本質を得ているかと言うと、初心者のための入門書である。しかしプロジェクトに従事し、そのプロジェクトが継続的なプロジェクトになると話は違ってくる。コメントが書いてない誰が書いたかわからないコード、当然単体テストなんてものはないし、あったとしても単体テストがなにをやってるかわからない。コード品質にしても、なんでクラス関数が50個もあるの?クラス使ってる意味ないじゃん!みたいな組織は多いのではないか。そういったプロジェクトを管理する人には最適であり、日本語で読める唯一の本のような気がする。「レガシーコード改善ガイド」とかマーティンファウアーの本とかはいい本だが、コード書く人よりのガイドであるので、この本とはちょっと方向性が違う。数年間同じ製品を開発し、努力しても製品品質があがらないマネージャ向けだが、若い開発者も読んで損はない本だと思う。
34人のお客様がこれが役に立ったと考えています
役に立った
2019年10月26日に日本でレビュー済み
Amazonで購入
私はプログラマーという立場からこの書籍を読んだため、主に役立ったのはコーディングとテストに関するプラクティスでした。例えば、CLEANなコードに関しての記述は、SOLID原則の知識を補強できたため、有益でした。
一方で、組織論風のことについては今まで興味がなかったため、XPやスクラムの前提知識がありませんでした。そのため「プロダクトオーナー」「バックログ」といったスクラムの専門用語や、「ペア・プログラミング」といったXPの専門用語についてすんなり頭に入るような書籍ではなく、前提知識として持っておく必要があります。
スクラムにおける「プロダクトオーナー」の視点でも書かれているし、「開発チーム」の立場から役立つことも書かれていますが、開発チームの立場に近い人間は技術的なプラクティスに関連する章を専念して読むとためになると思いました。
ただ、自分の立場とは関係ない章を読んだとしても、開発の全体像を掴むには有益です。
一方で、組織論風のことについては今まで興味がなかったため、XPやスクラムの前提知識がありませんでした。そのため「プロダクトオーナー」「バックログ」といったスクラムの専門用語や、「ペア・プログラミング」といったXPの専門用語についてすんなり頭に入るような書籍ではなく、前提知識として持っておく必要があります。
スクラムにおける「プロダクトオーナー」の視点でも書かれているし、「開発チーム」の立場から役立つことも書かれていますが、開発チームの立場に近い人間は技術的なプラクティスに関連する章を専念して読むとためになると思いました。
ただ、自分の立場とは関係ない章を読んだとしても、開発の全体像を掴むには有益です。
2019年11月27日に日本でレビュー済み
Amazonで購入
最初にレガシーコードとは何か、何故生まれるのかを説明し、レガシーコードを産まない為の9つのプラクティス(アジャイルのプラクティス)を説明しています。基本はアジャイルを説明した本なのですが、前半部でIT予算の80%が保守で、600億ドルがレガシーコードの為に喪失し、それらはウォーターフォールを始めとする間違えた方法論であると言う部分は印象深いです。また、アジャイルを丁寧に説明した本では無いので、あくまで基本は理解していて、それをどう実践するかや、プラクティスの詳細を知りたい方向けです。
2020年2月1日に日本でレビュー済み
Amazonで購入
C言語やBASIC言語は学校の座学で知っている程度、営業職などを経て、ここ最近、実務でjQueryありきのJavaScriptコードを数年ほど扱っている末端コーディング人です。
読んだ後の感想。
「自社の財産」とされているコードの大半(率直にいうとほとんど全部)が、この本で言われている「レガシーコード」だと気づくことができました。
オーダーされて旧コードに「機能拡張」などもしているのですが、それがハック的に割り込みしているだけだと自覚できました。
雑談などでもしゃべりやすい同僚から先に、本書を布教しています。わりと共感してもらえて、半年後が楽しみです。
目先の目標としては
・マネージメントの人にも読んでもらう
・本書から共通認識として取り入れられそうなことを、チームとして共有してとりくむ
・会社の経費でオライリー本を買ってもらう
というところです。
今の私にとっては、得るものが多すぎる、とても良い本です。
読んだ後の感想。
「自社の財産」とされているコードの大半(率直にいうとほとんど全部)が、この本で言われている「レガシーコード」だと気づくことができました。
オーダーされて旧コードに「機能拡張」などもしているのですが、それがハック的に割り込みしているだけだと自覚できました。
雑談などでもしゃべりやすい同僚から先に、本書を布教しています。わりと共感してもらえて、半年後が楽しみです。
目先の目標としては
・マネージメントの人にも読んでもらう
・本書から共通認識として取り入れられそうなことを、チームとして共有してとりくむ
・会社の経費でオライリー本を買ってもらう
というところです。
今の私にとっては、得るものが多すぎる、とても良い本です。
2019年11月23日に日本でレビュー済み
Amazonで購入
コードは書くよりも読むことの多い、そして開発すればするほどメンテナンス性が悪くなることを如何に防ぐかが書かれている。また、実際に開発経験が乏しくマネージャーになる人がよくやる作っても使われないシステムを作らないためにアジャイルで開発する手法などが書かれている。
開発者は品質向上のために読むべきである。しかし、初心者がこの本を読んでもわからないだろう。
この本に書かれていることを理解すれば、開発しながらコード上でうまく設計し品質向上できるようになるだろう。
開発者は品質向上のために読むべきである。しかし、初心者がこの本を読んでもわからないだろう。
この本に書かれていることを理解すれば、開発しながらコード上でうまく設計し品質向上できるようになるだろう。
2019年10月1日に日本でレビュー済み
ベストセラーになってますし、すでに読まれた方も多いと思います。間違いなく定番本の一つです。
著者がXP(エクストリームプログラミング)のコーチらしく、述べられているプラクティスの多くはXP由来となっています。
ただ、アジャイル開発手法に変わりはありませんので、スクラムでも適用できる内容です。ウォータフォール?そんな開発手法は存在しませんよ?
副題の9つのプラクティスは以下の通りです。
- やり方より先に目的、理由、誰のためかを伝える
- 小さなバッチで作る
- 継続的に統合する
- 協力しあう
- 「CLEAN」コードを作る
- まずテストを書く
- テストでふるまいを明示する
- 設計は最後に行う
- レガシーコードをリファクタリングする
自分のプロジェクトでも、これらのプラクティスは(ややアレンジはあるものの)実施しており、適切なシステム開発を行うためのミニマムセットになっています。
逆に、できてないものがある場合は、そのシステム開発は何らかの問題を抱えているということになります。
プロジェクト管理者はもちろん、システム開発に関わる全ての人が知っておくべき内容が詰まっています。
システム開発プロジェクトの新規参画者に対しては、オンボーディングで最初に読んでもらうのがいいと思います。
著者がXP(エクストリームプログラミング)のコーチらしく、述べられているプラクティスの多くはXP由来となっています。
ただ、アジャイル開発手法に変わりはありませんので、スクラムでも適用できる内容です。ウォータフォール?そんな開発手法は存在しませんよ?
副題の9つのプラクティスは以下の通りです。
- やり方より先に目的、理由、誰のためかを伝える
- 小さなバッチで作る
- 継続的に統合する
- 協力しあう
- 「CLEAN」コードを作る
- まずテストを書く
- テストでふるまいを明示する
- 設計は最後に行う
- レガシーコードをリファクタリングする
自分のプロジェクトでも、これらのプラクティスは(ややアレンジはあるものの)実施しており、適切なシステム開発を行うためのミニマムセットになっています。
逆に、できてないものがある場合は、そのシステム開発は何らかの問題を抱えているということになります。
プロジェクト管理者はもちろん、システム開発に関わる全ての人が知っておくべき内容が詰まっています。
システム開発プロジェクトの新規参画者に対しては、オンボーディングで最初に読んでもらうのがいいと思います。
VINEメンバー
絶賛されてたのでさぞかしすごい本なのだろうと思っていたが、正しいオブジェクト指向、DRY、ドメイン駆動プログラミング、デザインパターン、ビジネスロジックとデータベース関連処理の分離とか、統合開発環境Eclipseで自動的にビルドしてエラーを修正するみたいなことができていれば回避できるような話が8割くらいでした。
実質的には「クライアント交渉担当のSEと開発者でストリーを共有しよう」「テスト駆動プログラミングをしよう」「アジャイルでやろう」と言ってるだけかなあ。しかも、それぞれを具体的に説明するというよりは、重要性を説く感じが多く、肩透かしを食らった感じでした。何度も同じ話をしたり、かなり時間を無駄にしたなという感じです。
無理して全部読むことはないので、各章末の7つの戦略と12章13章だけ読めばいいんじゃないですかね。
実質的には「クライアント交渉担当のSEと開発者でストリーを共有しよう」「テスト駆動プログラミングをしよう」「アジャイルでやろう」と言ってるだけかなあ。しかも、それぞれを具体的に説明するというよりは、重要性を説く感じが多く、肩透かしを食らった感じでした。何度も同じ話をしたり、かなり時間を無駄にしたなという感じです。
無理して全部読むことはないので、各章末の7つの戦略と12章13章だけ読めばいいんじゃないですかね。