【2022年】リファクタリング・コーディング技術の本「人気・おすすめの10冊」

コードには守るべき原則やアンチパターンなどがあります。それらを認識した上でプログラムを書くことで、保守性、再利用性、可読性などが高く運用しやすいコードとすることができます。

長く使えるコード、未来の自分やチームメンバーにとっても良いコード、を書けるよう、リファクタリング、コーディング作法を身に着けましょう。

こちらでは、リファクタリング、コーディング技術に関する書籍を人気とともに紹介していきます。

 

 

Kindle Unlimited 1ヶ月無料

kindle_unlimited_sale
 
  • 1ヶ月無料で読み放題
  • 1ヶ月以内でも解約可能
  • 解約後も1ヶ月まで利用可


 

リファクタリング・コーディング技術の参考書「最新の人気ランキング 20冊」

今人気の「リファクタリング・コーディング技術の参考書」をランキングで一覧したのが以下です。

(2022/01/25 12:07 更新)
Rank製品価格
1
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)...
発売日 2012/06/23
Dustin Boswell, Trevor Foucher (オライリージャパン)
総合評価
(4.5)
2,640円
2,640円
2,640円
2
2,618円
2,487円
2,618円
2,618円
3
レガシーコード改善ガイド
発売日 2016/01/15
マイケル・C・フェザーズ (翔泳社)
総合評価
(4.5)
4,620円
4,158円
4,620円
4,620円
4
4,840円
4,598円
4,840円
4,840円
5
増補改訂版 Java言語で学ぶデザインパターン入門
発売日 2014/03/12
結城 浩 (SBクリエイティブ)
総合評価
(4.3)
4,180円
3,762円
4,180円
2,748円
6
4,180円
3,762円
4,180円
4,180円
7
レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス...
発売日 2019/09/19
David Scott Bernstein (オライリージャパン)
総合評価
(4.3)
3,190円
3,190円
3,190円
8
2,034円
2,218円
2,464円
2,104円
9
リファクタリング 既存のコードを安全に改善する(第2版)...
発売日 2019/12/06
MartinFowler (オーム社)
総合評価
(4.6)
4,840円
4,356円
4,840円
4,840円
10
オブジェクト指向における再利用のためのデザインパターン...
ガンマ,エリック, ジョンソン,ラルフ, ヘルム,リチャード, ブリシディース,ジョン (ソフトバンククリエイティブ)
総合評価
(3.6)
5,280円
(+159pt)
5,280円
5,280円
11
Code Complete 第2版 上 完全なプログラミングを目指して
発売日 2014/04/02
スティーブ マコネル (日経BP)
総合評価
(4.5)
6,710円
6,375円
6,710円
6,710円
12
新装版 リファクタリング 既存のコードを安全に改善する...
発売日 2017/07/15
MartinFowler (オーム社)
総合評価
(4.1)
4,562円
4,620円
4,620円
4,250円
13
Head Firstデザインパターン ―頭とからだで覚えるデザインパターンの基本...
発売日 2005/12/02
Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates (オライリージャパン)
総合評価
(4)
5,060円
5,060円
5,060円
14
2,838円
2,838円
2,838円
2,838円
15
Java言語で学ぶリファクタリング入門
発売日 2014/03/12
結城 浩 (SBクリエイティブ)
総合評価
(4.2)
5,400円
3,520円
3,520円
1,045円
16
独習デザインパターンC++
発売日 2015/03/27
株式会社テクノロジックアート (翔泳社)
総合評価
(3.4)
7,664円
3,600円
3,740円
3,740円
17
パターン指向リファクタリング入門~ソフトウエア設計を改善する27の作法...
発売日 2005/08/04
ジョシュア・ケリーエブスキー, 小黒 直樹, 村上 歴, 高橋 一成 (日経BP)
総合評価
(4.8)
5,233円
4,400円
5,587円
18
リファクタリング―プログラムの体質改善テクニック (Object Technology Series)...
マーチン ファウラー (ピアソンエデュケーション)
総合評価
(4.1)
977円
5,280円
825円
19
2,398円
2,278円
2,398円
2,398円
20
リファクタリング・ウェットウェア ―達人プログラマーの思考法と学習法...
発売日 2009/04/27
Andy Hunt (オライリージャパン)
総合評価
(3.5)
3,080円
(+152pt)
3,080円
3,080円
 

以降でおすすめ・注目の本をピックアップしていきます。

Kindle版のある本なら試し読みも可能。大概目次まで見れるので、概要もつかめるので、サンプル試読がおすすめです。

 

リファクタリング・コーディング技術の本 人気ランキング/5冊詳細

以下が「リファクタリング・コーディング技術の本」人気ランキングと人気の5冊詳細です。

(2022/01/25 12:07 更新)
Rank製品価格
1
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)...
発売日 2012/06/23
Dustin Boswell, Trevor Foucher (オライリージャパン)
総合評価
(4.5)
2,640円
2,640円
2,640円
2
2,618円
2,487円
2,618円
2,618円
3
レガシーコード改善ガイド
発売日 2016/01/15
マイケル・C・フェザーズ (翔泳社)
総合評価
(4.5)
4,620円
4,158円
4,620円
4,620円
4
4,840円
4,598円
4,840円
4,840円
5
増補改訂版 Java言語で学ぶデザインパターン入門
発売日 2014/03/12
結城 浩 (SBクリエイティブ)
総合評価
(4.3)
4,180円
3,762円
4,180円
2,748円
 

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

「美しいコードを見ると感動する。優れたコードは見た瞬間に何をしているかが伝わってくる。そういうコードは使うのが楽しいし、
自分のコードもそうあるべきだと思わせてくれる。本書の目的は、君のコードを良くすることだ」(本書「はじめに」より)。

コードは理解しやすくなければならない。本書はこの原則を日々のコーディングの様々な場面に当てはめる方法を紹介します。
名前の付け方、コメントの書き方など表面上の改善について。コードを動かすための制御フロー、論理式、変数などループとロジックについて。
またコードを再構成するための方法。さらにテストの書き方などについて、楽しいイラストと共に説明しています。

日本語版ではRubyやgroongaのコミッタとしても著名な須藤功平氏による解説を収録。
 
内容サンプル

(引用元Amazon)

 
目次
理解しやすいコード
第1部 表面上の改善(名前に情報を詰め込む
誤解されない名前
美しさ
コメントすべきことを知る
コメントは正確で簡潔に)
第2部 ループとロジックの単純化(制御フローを読みやすくする
巨大な式を分割する
変数と読みやすさ)
第3部 コードの再構成(無関係の下位問題を抽出する
一度に1つのことを
コードに思いを込める
短いコードを書く)
第4部 選抜テーマ(テストと読みやすさ
「分
時間カウンタ」を設計・実装する)
付録 あわせて読みたい

↓全て表示↑少なく表示
Users Voice
仕事、趣味問わずプログラミングをする方におすすめです!内容は言語ではなく誰が見ても理解できるコードを書くには?をテーマに書いてます。勉強になりました! (参考:YahooShopping)

↓全て表示 ↑少なく表示
コーディング界隈でよく名前の挙がる名著ですが、非常に読みやすく、短期間で読了できました。 初学者からベテランまで活用できる内容となっております。 (参考:YahooShopping)

↓全て表示 ↑少なく表示
わかりやすいイラストと例え、そしてカジュアルな語り口でともすれば難解になりがちなプログラミングの概念を学ぶことができました。 (参考:YahooShopping)

↓全て表示 ↑少なく表示
内容サンプル

(引用元Amazon)

 
著者略歴
ボズウェル,ダスティン(Boswell,Dustin)
カリフォルニア工科大学で理学士号を取得。その後、カリフォルニア大学サンディエゴ校で修士号を取得。Google社で5年間勤務し、ウェブクローリング用のインフラなどさまざまなプロジェクトに携わる

フォシェ,トレバー(Foucher,Trevor)
10年以上もの間、Microsoft社でWindows2000やOneCare、Google社でWeb master Toolsなどのソフトウェアプロジェクトを送り出してきた。現在は独立コントリビュータ・マネージャ・テクニカルリードである

角征典(カドマサノリ)
1978年山口県生まれのプログラマ(本データはこの書籍が刊行された当時に掲載されていたものです)

↓全て表示↑少なく表示

  

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

(概要)
「コミュニケーションにおける不確実性を減らすには?」
「技術的負債を解消する方法とは?」
「経営陣とエンジニア間の認識のずれを解消するには?」
エンジニアリングにおける課題を解決する思考の整理方法やメンタリング手法を,さまざまな企業の技術組織アドバイザリーを務めている著者が解説。若手を戦力として育て上げ,成長する組織を設計・運営するためにおすすめの1冊です。

(こんな方におすすめ)
・開発チームの生産性を上げたいエンジニア
・社内組織を改善したい経営者

(目次)
Chapter 1 思考のリファクタリング

1-1 すべてのバグは,思考の中にある
1-2 不確実性とエンジニアリング
1-3 情報を生み出す考え方
1-4 論理的思考の盲点
1-5 経験主義と仮説思考
1-6 全体論とシステム思考
1-7 人間の不完全さを受け入れる
Chapter 2 メンタリングの技術

2-1 メンタリングで相手の思考をリファクタリング
2-2 傾聴・可視化・リフレーミング
2-3 心理的安全性の作り方
2-4 内心でなく行動に注目する
Chapter 3 アジャイルなチームの原理

3-1 アジャイルはチームをメンタリングする技術
3-2 アジャイルの歴史
3-3 アジャイルをめぐる誤解
3-4 アジャイルの格率
Chapter 4 学習するチームと不確実性マネジメント

4-1 いかにして不確実性を管理するか
4-2 スケジュール予測と不確実性
4-3 要求の作り方とマーケット不安
4-4 スクラムと不安に向き合う振り返り
Chapter 5 技術組織の力学とアーキテクチャ

5-1 何が技術組織の“生産性”を下げるのか
5-2 権限委譲とアカウンタビリティ
5-3 技術的負債の正体
5-4 取引コストと技術組織
5-5 目標管理と透明性
5-6 組織設計とアーキテクチャ

↓全て表示↑少なく表示
 
目次
1 思考のリファクタリング(すべてのバグは、思考の中にある
不確実性とエンジニアリング ほか)
2 メンタリングの技術(メンタリングで相手の思考をリファクタリング
傾聴・可視化・リフレーミング ほか)
3 アジャイルなチームの原理(アジャイルはチームをメンタリングする技術
アジャイルの歴史 ほか)
4 学習するチームと不確実性マネジメント(いかにして不確実性を管理するか
スケジュール予測と不確実性 ほか)
5 技術組織の力学とアーキテクチャ(何が技術組織の“生産性”を下げるのか
権限委譲とアカウンタビリティ ほか)

↓全て表示↑少なく表示
Users Voice
組織論について書籍で読んだことがなく新社会人になり組織について気になったので購入しました。 「不確実性」への対処がこの本で一貫したテーマなので,込み入った話をしていても頭の片隅に置いておくと読みやすいです. 新卒エンジニアでも,読んでいて学びの多い本なので読むタイミングは選ばない本だと思います.強いて言うなら働き方や将来像に対して「不安」を感じたときに読むのがベストかもしれません. どんな立場でも「不安」に駆り立てられないときはないと思います. この本に書いてある通り見えないものを見えるように行動することで,不安ではなくなり悩みは考えるへと変化します. それは,技術的なことでも,経営においても,アジャイルにおいても同様です. 見えないから不安であり,情報が非対称だから思い通りにならないことが一貫してかかれています. この本の良いところは,個人から集団へとシフトして説明していくことだと思います. そのおかげで,大体の立場において通じる考えを得ることができる本となっています. 不確実性を対処できることが,「エンジニアリング」ということを考えると全てのエンジニアが目指す像はこれなのかもしれない,と思いました. (参考:YahooShopping)

↓全て表示 ↑少なく表示
組織における情報の透明性、
開発における見積りの不確実性を解決しようとしたときに、
どういうことを考えていけばいいのか、
最初の一歩の踏み出し方を教えてくれる本な気がしました。
どの章でも、どの問題でも、
まずは何がわかっていて、何がわかっていないのか、
無知の知ではないが、わかっていないことを知ることを基礎としている気がします。
組織のマネージメントを考えたときに、
この本を読むことで知識の整理、行動の促進、自身の立ち位置の把握と、
振り返りを生むことが多い本だと思いました。
(以下抜粋。○:完全抜粋、●:簡略抜粋)
●「エンジニアリング」とは一体何でしょうか。
(中略)
私たちは、自分たちが日々行っている「エンジニアリング」とは一体何なのかをよく知らないということです。
(中略)
エンジニアリングとは、つまるところ、「実現」していくための科学分野だといえるでしょう。(P.10-11)
●不確実性コーン。プロジェクト初期においての見積もりは、見積もりに対して4倍から1/4の範囲で誤差があります。後半になればなるほどその誤差は減ります。つまり「実現」するエンジニアリングで重要なのは「どうしたら効率よく不確実性を減らしていけるのか」という考え方なのです。(P.12)
●シャノンは、不確実性の量をエントロピーと呼びました。例として天気として、明日は晴れか雨だけだとします。明日は晴れが50%(雨が50%)の場合1bit、晴れが80%(雨が20%)の場合0.72bit、晴れが100%(雨が0%)の場合0bit。(本にはエントロピーの式がある)発生する確率が偏っているほど、不確実性の量は減っていくことがわかります。(P.15)
○全体論とシステム志向は、「人は、問題を個人の責任にしたり、全体像を見失った局所的最適な思考をしてしまう」ので、それが全体像ではないかもしれない、問題は関係性にあるのではないあかという視点と問題解決のための目を提供し、行動を促すものでした。(P.67)
○「情報の非対称性」と「限定的理性」、この2つが、組織における人間の不完全さを加速させ、組織に忍んでいる理不尽の増幅装置となってしまうのです。(P.69)
○「情報の透明性」とは、意思決定と意思決定に関わる情報が、組織内に正しく整合性をもって伝達されるように継続して努力し、何かわからない決定があったとしても、それを隠そうとしたわけではなく、抜けてしまったのか、自分が聞き逃したのだから、直接聞いてみようという関係性をつくることです。情報公開が情報の透明性を作るわけではありません。(P.72)
●メンターとメンティの関係性の条件。
・謙虚:お互いに弱さを見せられる
・敬意:お互いに敬意を持っている
・信頼:お互いにメンティの成長期待をもっている(P.81)
●「悩む」と「考える」の違い
(中略)
「悩んでいる」というのは、頭の中に様々なことが去来し、ぐるぐると思考がめぐり続け、もやもやが取れない状態だと考えています。
(中略)
この状態になったときには、サポートが必要dふぇ、共���考えるための戦略を立てていく必要があります。(P.87)
○メンターは、メンティの問題を直接解くことはできません。メンターができることは、問題を「簡単な問題に変換する」ことだけです。(P.96-97)
●認知フレームを発見する「キーワード」(P.101)
(それぞれの系で抜粋。相手の裏側を考えるのに非常に有効に思える)
こちら系 :この会社 :同じ側にいるように思えるが、実は一体感を持っていない。
あちら系 :あの部署は:同じくくりにいるはずなのに、向こう側と線引きしている。
極端系  :いつも  :ゼロ一で、グラデーションなしの物事判断
すべき系 :~すべき :「~すべき」という枠組みの中で限定的に考えている
決めつけ系:どうせ :感情的に決めていて、事実確認なしで推論している
●承認(アクノレッジメント)の3つの段階(P.112)
存在承認:挨拶を始め、相手がここにいることに対するメッセージ。
行動承認:行動に対して言葉で出して伝える。例えばほめること。
結果承認:できあがったものに対して主観を込めて伝える。ほめるより広い範囲への承認。
○マネジメントとは、対象となる○○の資源・資産・リスクを管理し、効果を最大化する手法(P.136)
○「アジャイル」状態とは、具体的にどのような状態でしょうか。それは以下のような状態のいのことを意味しています。
・情報の非対称性が小さい
・認知の歪みが少ない
・チームより小さい限定合理性が働かない
・対人リスクを取れていて心理的安全性が高い
・課題・不安に向き合い不確実性の削減が効率よくできている
・チーム全体のゴール認識レベルが高い(P.141)
●SECIモデル(P.151)
共同化・表出化・連結化・内面化という各フェーズを繰り返していくことで、知識というものが発展的に組織的に蓄積されます。
・共同化:組織において共通の経験を積み重ねることで、暗黙的な経験的な知識が共有されているフェーズ。共同化を促すためには、経験や思い、信念などをストーリーテリングする場が必要になる。
(異なる人が独自に実施)
・表出化:体感的で明文化されていない経験的知識の共通点や抽象的な構造・類似点を見つけモデル化していく工程。これはメンタリング的な対話によって引き出されていく。
(構造化、類似点の抽出によりモデリング、文章化)
・連結化:複数の形式的な知識を積み重ねて、1つの知識体系を作るフェーズ。そのためには、形式知を共有・編集・結合させるような場が必要で、Wikiなどのシステムはそのようなことを目的としている。
(Wikiなどによる凝縮して他の人ができるようにする)
・内面化:形式知として生まれた知識体系を知識として覚えている状態から、実践や行動を通じて、体感的・身体的に「理解できた」という状態に変えるフェーズ
(文書化された知識を実践や行動に移すが、ゆっくりと見ながらでもよい練習している状態)
○「見積り」について考えてみましょう。ソフトウェア開発は同じことを二度と繰り返す必要が基本的にないので、毎回どこかしら初めての作業になります。そのため、作業見積もりというのはいい加減なもので、正解とは限りません。ですが、作業実績であればどうでしょうか。これは過去の実例なので正確な数値です。これをもとに将来を見通すほうが、より正確になるはずです。(P.177)
(アジャイルに限らず予測と実績を取得しておくことで、初めて改善できる。やるやらを考える時にも、なんのためにやるのか、測定できる何が改善されるのかを考えないといけないということ。)
○プロジェクト型チームはレスポンスタイムを最適化する。
プロダクト型チームはスループットを最適化する。(P.179)
●見積りは、あくまで予測です。しかし、この予測を「ノルマ」として扱ってしまった場合、それが達成できないときに能力や評価の問題にされる可能性が出てしまいます。
(中略)
予測を「ノルマ」にした途端、それを達成するための過負荷な労働が生まれ、クオリティは下がってしまいます。あるいは、スケジュールの予測精度はどんどんと下がってしまいます。このようなことを避けるために、エンジニアは次からは防衛的で悲観的なケースで見積りを行うとします。(P.190)
●2点見積り、3点見積り(P.193)
●エピック→テーマ→ストーリー→タスク(P.208)
○すでに成功しているビジネスであれば、公開されている情報からでもリーンキャンバスを再現することはできるでしょう。成功しているビジネス10個程度ピックアップして、そこからリーンキャンバスを想像するという練習を繰り返すと、プロダクトのもつ本質が見えてくるようになります。
 仮説検証における仮説は、十分な情報があるところとから導かれる正解ではありません。わずかな痕跡からでもよいのではっきりとした具体的なイメージをもつことで、はじめて仮説と現実の違いを認識することができます。(P.220)
○技術的負債は「見ることができない」(P.256)
●技術的負債というと抽象度が高く見ることができないが、解決方法を調査検討することで何が問題が見えてきます。見えてこればそれはただのタスクでしかありません。(P.264)
●システム外注における取引コスト
・探索のコスト:クオリティの高い外注先を探す、関係を構築するコスト
・交渉のコスト:契約条件をまとめるコスト
・監督のコスト:品質の監視、維持、検収をするコスト(P.276) (参考:honto)

↓全て表示 ↑少なく表示
しっくりきました。めちゃくちゃ参考になりました。
本のタイトルに「組織論」とありますが、実際には「ソフトウェア開発における不確実性がもたらす問題と、その対処方法」について書かれた本だと思います。「組織論」としてまとめられているのは、デマルコの「ソフトウェア開発における問題のほとんどは技術的なものではなく社会学的なものである」という考えや、コンウェイの法則という「ソフトウェアは開発する組織の状態に依存する」という考えがベースになっているからのようです。つまり、良い組織であればソフトウェア開発もうまくいくし、組織に何らかの問題があればプロダクトにもひずみが出る、ってことです。プロマネ(プロジェクトマネジメント、プロダクトマネジメント)やアジャイル開発、チームビルディングに興味がある人には、きっと役立ちます。
メンタリングやアジャイルなど、書いてある視点が多様すぎて、一見何について書かれた本か理解しにくいかもしれません。また、この本では、章ごとに、個人→ペア→チーム→組織の順で、不確実性による問題点が書かれているのですが、この、組織論でありながら個人や一対一のペアの話から組み立てられた章立てが、少しとっつきにくくしているところがあると思います。ただ、チームや組織の問題を理解するため必要な流れになっていて、最後まで読むことで、すっきりと全体を理解できると思います。(ですので飛ばさずに順を追って読むことをおすすめします)
簡単に要約です。
ソフトウェア開発における不確実性とは、なんのことでしょうか?不確実性は大別すると「未来のことがわからない」と「他人のことがわからない」の2つに分けられます。そして不確実性は、情報を生み出すことで潰すことができます。
前者の未来に対しては、経験主義・仮説主導をベースに行動から情報を得ていくことが必要とされます。論理的思考には盲点がありそれだけでは足りたないとされます。またシステム思考で全体を俯瞰し、問題を正しく認識しないといけません。
後者の他人に対してはコミュニケーションを取ることが求められます。ただそこには、情報の非対称性と、それによる限定合理性が働くため、簡単にはうまく行きません。
・・・と、ここまでが第一章の内容で、個人の思考を変える必要性が説かれています。そしてこの考えがベースとなり、他者へのメンタリング、アジャイル、組織論へと段々と領域を広げて話が展開していきます。
エンジニアに限らず他職種の人にも役立つと思います。興味持たれた方はぜひ。 (参考:honto)

↓全て表示 ↑少なく表示
著者略歴
広木大地(ヒロキダイチ)
株式会社レクター取締役。1983年生まれ。筑波大学大学院を卒業後、2008年に新卒第1期として株式会社ミクシィに入社。同社のアーキテクトとして、技術戦略から組織構築などに携わる。同社メディア開発部長、開発部部長、サービス本部長執行役員を務めた後、2015年退社。株式会社レクターを創業し、技術と経営をつなぐ技術組織のアドバイザリーとして、多数の会社の経営支援を行っている(本データはこの書籍が刊行された当時に掲載されていたものです)

↓全て表示↑少なく表示

  

レガシーコード改善ガイド

レガシーコード改善ガイド
(著)マイケル・C・フェザーズ
発売日 2016/01/15
総合評価
(4.5)
(2022/01/25 12:07時点)

保守開発のためのリファクタリング!

本書は、システム保守の現場でありがちな、構造が複雑で理解できないようなコードに対する分析手法・対処手法について解説します。つまり、「コードを理解し、テストできるようにし、リファクタリングを可能にし、機能を追加できるテクニックを紹介している書籍です。

本書には、以下のことが記載されています。
●仕様が分からないコードの分析方法
●仕様が分からないコードの修正方法、またテストコードの追加方法
●コードの修正で、疎結合な設計に部分的に改善する方法

また、本書には、以下のことは記載されていません。
●COBOLなどで記述されているメインフレーム上のアプリケーションの改修方法

【 対象読者】
●現行のシステムが仕様が分からず保守作業に悩む、保守担当者
●現行のシステムの修正作業は可能であるもののデグレーションに悩む、保守担当者
●疎結合な設計手法を知りたい技術者

本書はJava、C、C++でサンプルを記述していますが、記載されているテクニックは言語依存するものではないため、他の言語(Delphi、Visual Basic、COBOL、FORTRAN)でも使えます。

※本電子書籍は同名出版物を底本として作成しました。記載内容は印刷出版当時のものです。
※印刷出版再現のため電子書籍としては不要な情報を含んでいる場合があります。
※印刷出版とは異なる表記・表現の場合があります。予めご了承ください。
※プレビューにてお手持ちの電子端末での表示状態をご確認の上、商品をお買い求めください。


↓全て表示↑少なく表示
 
内容サンプル

(引用元Amazon)

 
目次
第1部 変更のメカニズム
第1章 ソフトウェアの変更
1.1 ソフトウェア変更の4つの理由
1.2 危険な変更
第2章 フィードバックを得ながらの作業
2.1 単体テストとは
2.2 上位レベルのテスト
2.3 テストによる保護
2.4 レガシーコードの変更手順
第3章 検出と分離
3.1 協調クラスの擬装
第4章 接合モデル
4.1 巨大な用紙の文字の羅列
4.2 接合部
4.3 接合部の種類
第5章 ツール
5.1 自動リファクタリングツール
5.2 モックオブジェクト
5.3 単体テストハーネス
5.4 一般的なテストハーネス
第2部 ソフトウェアの変更
第6章 時間がないのに変更しなければなりません
6.1 スプラウトメソッド
6.2 スプラウトクラス
6.3 ラップメソッド
6.4 ラップクラス
6.5 まとめ
第7章 いつまで経っても変更作業が終わりません
7.1 理解すること
7.2 遅延時間
7.3 依存関係の排除
7.4 まとめ
第8章 どうやって機能を追加すればよいのでしょうか?
8.1 テスト駆動開発(TDD)
8.2 差分プログラミング
8.3 まとめ
第9章 このクラスをテストハーネスに入れることができません
9.1 いらだたしいパラメータ
9.2 隠れた依存関係
9.3 複雑な生成
9.4 いらだたしグローバルな依存関係
9.5 恐るべきインクルードの依存関係
9.6 玉ねぎパラメータ
6.7 別名のパラメータ
第10章 このメソッドをテストハーネスで動かすことができません
10.1 隠れたメソッド
10.2 言語の「便利な」機能
10.3 検出できない副作用
第11章 変更する必要がありますが、どのメソッドをテストすればよいのでしょうか?
11.1 影響の調査
11.2 前方向の調査
11.3 影響の伝播
11.4 影響調査のためのツール
11.5 影響スケッチの単純化
第12章 1ヶ所にたくさんの変更が必要ですが、関係するすべてのクラスの依存関係を排除すべきでしょうか?
12.1 割り込み点
12.2 絞り込み点で設計を判断する
12.3 絞り込み点の落とし穴
第13章 変更する必要がありますが、どんなテストを書けばよいのかわかりません
13.1 仕様化テスト
13.2 クラスの仕様を明らかにする
13.3 狙いを定めたテスト
13.4 仕様化テストを書くための経験則
第14章 ライブラリへの依存で身動きが取れません
第15章 私のアプリケーションはAPI呼び出しだらけです
第16章 変更できるほど十分に私はコードを理解していません
16.1 メモを取る/スケッチを描く
16.2 印を付ける
16.3 試行リファクタリング
16.4 使用していないコードを削除する
第17章 私のアプリケーションには構造がありません
17.1 システムのストーリーを話す
17.2 白紙のCRC
17.3 会話の吟味
第18章 自分のテストコードが邪魔になっています
18.1 クラスの命名規約
18.2 テストコードの配置
第19章 私のプロジェクトはオブジェクト指向ではありませんが、どうすれば安全に変更できるでしょうか?
19.1 簡単なケース
19.2 困難なケース
19.3 新しい振る舞いの追加
19.4 オブジェクト指向の長所の活用
19.5 すべてはオブジェクト指向
第20章 このクラスは大きすぎて、もうこれ以上大きくしたくありません
20.1 責務の把握
20.2 その他の技法
20.3 先へ進む
20.4 クラスの抽出後
第21章 同じコードをいたるところで変更しています
21.1 最初のステップ
第22章 モンスターメソッドを変更する必要がありますが、テストを書くことができません
22.1 モンスターの変種
22.2 自動リファクタリング機能でモンスターに立ち向かう
22.3 手作業によるリファクタリングに挑戦
22.4 戦略
第23章 どうすれば何も壊していないことを確認できるでしょうか?
23.1 超集中編集
23.2 単一目的の編集
23.3 シグネチャの維持
23.4 コンパイラまかせ
23.5 ペアプログラミング
第24章 もうウンザリです。何も改善できません
第3部 依存関係を排除する手法
第25章 依存関係を排除する手法
25.1 パラメータの適合
25.2 メソッドオブジェクトの取り出し
25.3 定義の補完
25.4 グローバル参照のカプセル化
25.5 静的メソッドの公開
25.6 呼び出しの抽出とオーバーライド
25.7 Factory Methodの抽出とオーバーライド
25.8 getメソッドの抽出とオーバーライド
25.9 実装の抽出
25.10 インタフェースの抽出
25.11 インスタンス委譲の導入
25.12 静的setメソッドの導入
25.13 リンクによる置き換え
25.14 コンストラクタのパラメータ化
25.15 メソッドのパラメータ化
25.16 パラメータのプリミティブ化
25.17 メソッドと変数の引き上げ
25.18 依存関係の押し出し
25.19 関数ポインタによる関数の置き換え
25.20 getメソッドによるグローバル参照の置き換え
25.21 サブクラス化とメソッドのオーバーライド
25.22 インスタンス変数の入れ替え
25.23 テンプレートによる再定義
25.24 テキストによる再定義
付録A リファクタリング
A1 メソッドの抽出
付録B 用語集

↓全て表示↑少なく表示
Users Voice
レガシーコードで悩んでたので何かのヒントが得られるかと思って購入しました。 これから頑張って読みたいと思います (参考:YahooShopping)

↓全て表示 ↑少なく表示
レガシーコードをいかにHackしてテストケースの作成やリファクタリングを行うかの本。
JavaやC++はともかくCでリンカを変えて本番コードからテスト用のモックを参照するというのは目から鱗でした。
既に存在するレガシーコードに対してのアプローチを前提に書かれているため大抵の現場で役に立つと思われますw(サンプルコードはJava/C++/Cが中心だけど別言語でもたぶん置き換えは可能)
リファクタリングに伴う影響の調査
  ↓
本番コードをテストコードで保護&本番コードに依存性を注入しテストしやすくする
  ↓
本番コードを修正
といった石橋を叩きすぎて渡るというポリシーが素敵。プロなら品質を担保するためにこれくらいやるべきですよねw
ただし内容は非常に難しいので、最低でも「リファクタリング プログラムの体質改善テクニック」や「クリーンコード」を読んでいることが前提かと。
http://booklog.jp/users/sue445/archives/4894712288
http://booklog.jp/users/sue445/archives/4048676881
読み終わった本の中で仕事中にもすぐ手にとりたい物は机の上に立てているのですが、この本は表紙の「テストがないコードはレガシーコードだ!」が非常にショッキングなため机の上にみんなに表紙が見えるように置いていますw (参考:honto)

↓全て表示 ↑少なく表示
2ヶ月前に途中まで書いたコードの続きを最近覚えたTDDでと思ったら、テストするためにはリファクタリングが必要で、リファクタリングにはテストが必要でとデッドロックしたので読んだ。
リファクタリング発展編。アンチパターン的な。でも人ごとではなく身の回りで常に見かける現実なのでお役立ち度は高い。自動テストがない状態のコードをどのようにテスト可能、リファクタリング可能な状態に持っていくか。テストのないコードを変更することが如何に大変かの例をこれでもかと見せられることでテストの重要性をヒシヒシと感じる本。サンプルはJava7割、C/C++3割。
自動テストがあれば素早いフィードバックが得られる。すると、間違いにすぐに気づいて手戻りが減る、デグレードを起こさない安心が得られる。直接的な効果だけでなく、対象コードについての記憶が残っているうちに対処できるので思い出す手間が不要だし、手動確認による繰り返し作業がなくなって退屈しないし、何より結果がすぐ出て頻繁に達成感が得られるのは楽しい、と良いこと尽くめ。
最近はJMockitとかのモックフレームワークでバイトコードから差し替えられるのでレガシーコードのジレンマは当時ほどではないのかもしれない。 (参考:honto)

↓全て表示 ↑少なく表示
内容サンプル

(引用元Amazon)

 
著者略歴
フェザーズ,マイケル・C.(Feathers,Michael C.)(フェザーズ,マイケルC.)
Object Mentor社勤務。現在、TDD(テスト駆動開発)、リファクタリング、オブジェクト指向設計、Java、C#、C++、XP(エクストリームプログラミング)に関するトレーニングやメンタリングを世界レベルで実践している。またCppUnit(JUnitをC++に移植したテスティングフレームワーク)、およびFitCPP(FITをC++に移植した統合テスティングフレームワーク)のオリジナル開発者でもある。ACMおよびIEEE会員

平澤章(ヒラサワアキラ)
ウルシステムズ株式会社ディレクター。金融機関向け第3次オンラインシステムなどのシステム開発業務や技術コンサルティング業務に従事した後、2001年より現職

越智典子(オチノリコ)
1988年株式会社オージス総研入社。オブジェクト指向技術に携わった後、2001年に同社を退社。以後、フリーランスの翻訳者として活動中

稲葉信之(イナバノブユキ)
ウルシステムズ株式会社シニアコンサルタント。テクマトリックス株式会社でアプリケーションサーバーのサポートや日本語化対応、およびシステム開発業務に従事した後、2007年より現職。現職では基幹システムの開発や、開発案件の技術支援に従事している

田村友彦(タムラトモヒコ)
ウルシステムズ株式会社シニアコンサルタント。ICカードの通信プロトコルからWebアプリケーションまで、さまざまなソフトウェア開発をさまざまな言語・環境で経験してきた。2006年より現職。現在は、技術的な支援を行う立場でシステム開発に携わる

小堀真義(コボリマサヨシ)
ウルシステムズ株式会社シニアコンサルタント。Webアプリケーションやセキュリティ基盤の開発を経験し、2006年より現職(本データはこの書籍が刊行された当時に掲載されていたものです)

↓全て表示↑少なく表示

  

リファクタリング(第2版): 既存のコードを安全に改善する (OBJECT TECHNOLOGY SERIES)

ソフトウェア開発の名著、第2版登場!
リファクタリングは、ソフトウェアの外部的な振る舞いを保ったままで、内部の構造を改善する作業を指します。本書はリファクタリングのガイドブックであり、リファクタリングとは何か、なぜリファクタリングをすべきか、どこを改善すべきか、実際の事例で構成され、ソフトウェア開発者にとって非常に役立つものとなっています。
本第2版では、約20年前のオリジナル原稿の構成は変わらないものの、大幅に書き換えられているほか、サンプルコードがJavaからJava Scriptになるなど、現代的にアレンジされています。
 
内容サンプル

(引用元Amazon)

 
目次
リファクタリングー最初の例
リファクタリングの原則
コードの不吉な臭い
テストの構築
カタログの紹介
リファクタリングはじめの一歩
カプセル化
特性の移動
データの再編成
条件記述の単純化
APIのリファクタリング
継承の取り扱い
Users Voice
リファクタリングに関する基本的な姿勢や考え方に関しては参考になる。
ただ、具体的な方法についてはこの本でしか得られない情報というものはほとんどなくリーダブルコード、プログラマが知るべき97のことなどの有名所を読んでいればだいたいエッセンスとしては知っているなというものが多かった気がする。数ポイントを得るには読んだ方がいいが他の本を読んでいるならプラスになる事は少ないかなというイメージ。 (参考:honto)

↓全て表示 ↑少なく表示
リファクタリングを実装に合わせて行うのは同感。
実行速度のチューニングはリファクタリングと相反していると考えがちだが、実は違う点はハッとした。基本に忠実にしっかり計測したい。
カタログは全体を通してざっくり読んだので、必要に応じて読み返したい。
データベースリファクタリングも少し気になった。 (参考:honto)

↓全て表示 ↑少なく表示
内容サンプル

(引用元Amazon)

 
著者略歴
児玉公信(コダマキミノブ)
(株)情報システム総研代表取締役社長。技術士(情報工学)、博士(情報学)。情報処理学会情報システムと社会環境研究会主査

友野晶夫(トモノマサオ)
フリーランスプログラマー

平澤章(ヒラサワアキラ)
ウルシステムズ株式会社所属。メインフレームからオープンシステム、マイコンまで多種多様なシステム開発を経験した後、2001年にウルシステムズのスタートアップに参画し、現在に至る

梅澤真史(ウメザワマサシ)
Smalltalkエバンジェリスト。2003年度IPA未踏ソフトウェア創造事業スーパークリエータ。(株)オージス総研、(株)豆蔵にてオブジェクト指向関連のコンサルティング、開発業務に従事した後、合同会社ソフトウメヤを立ち上げ現在に至る。SORABITO株式会社の技術フェローも兼任(本データはこの書籍が刊行された当時に掲載されていたものです)

↓全て表示↑少なく表示

  

増補改訂版 Java言語で学ぶデザインパターン入門

歴史を変えた1冊、待望の改訂版誕生。

※この電子書籍は、「固定レイアウト型」で配信されております。説明文の最後の「固定レイアウト型に関する注意事項」を必ずお読みください。

※この電子書籍には付録DVDのデータは含んでおりません。電子書籍に記載のURLからPCでダウンロードしてお使い下さい。

「この本で初めてデザインパターンが理解できた」「UMLとイラストを交えた解説がとてもわかりやすい」と、多くの読者から絶賛された大ロングセラーの増補改訂版。原典『デザインパターン』で紹介された全23のパターンを、Javaによる実装を含めて解説。

2001年6月の初版刊行以来、「最もわかりやすいデザインパターン解説書」と、多くの読者から支持されてきた前著の増補改訂版です。改訂にあたっては、前著の内容を全面的に見直して、文章や表記をより適切な表現に改めています。また、デザインパターンについて、読者が誤解しやすい点、間違いやすい点を、「Q&A」として追加しています。デザインパターンについて学び、実践で利用したいプログラマはもちろん、オブジェクト指向の本質を理解したい人に最適の1冊です。

●目次
はじめに
UMLについて
デザインパターンを学ぶ前に
デザインパターンに慣れる
第1章 Iterator ― 1つ1つ数え上げる
第2章 Adapter ― 一皮かぶせて再利用
サブクラスにまかせる
第3章 Template Method ― 具体的な処理をサブクラスにまかせる
第4章 FactoryMethod ― インスタンス作成をサブクラスにまかせる
インスタンスを作る
第5章 Singleton ― たった1つのインスタンス
第6章 Prototype ― コピーしてインスタンスを作る
第7章 Builder ― 複雑なインスタンスを組み立てる
第8章 Abstract Factory ― 関連する部品を組み合わせて製品を作る
分けて考える
第9章 Bridge ― 機能の階層と実装の階層を分ける
第10章 Strategy ― アルゴリズムをごっそり切り替える
 ほか

固定レイアウト型に関する注意事項(必ずお読みください)
この電子書籍は、全ページ画像の「固定レイアウト型」で配信されております。以下の点にご注意し、購入前にプレビュー表示をご確認の上、ご購入ください。

■使用できない機能
・文字拡大(ピンチイン・ピンチアウトは可能ですが、画面におさまらない場合は画面をスワイプ)/文字のコピー/マーク/ハイライト/文字列検索/辞書の参照/Web検索/引用

■推奨環境
・タブレットなど大きいディスプレイを備えた端末
・Wi-Fiネットワーク経由でのダウンロード(Kindle端末の場合)

↓全て表示↑少なく表示
 
内容サンプル

(引用元Amazon)

 
目次
第1部 デザインパターンに慣れる
第2部 サブクラスにまかせる
第3部 インスタンスを作る
第4部 分けて考える
第5部 同一視
第6部 構造を渡り歩く
第7部 シンプルにする
第8部 状態を管理する
第9部 無駄をなくす
第10部 クラスで表現する
Users Voice
実際にソースが書いてあってわかりやすい。 (参考:YahooShopping)

↓全て表示 ↑少なく表示
「この本で初めてデザインパターンが理解できた」「UMLとイラストを交えた解説がとてもわかりやすい」と、多くの読者から絶賛された大ロングセラーの増補改訂版。原典『デザインパターン』で紹介された全23のパターンを、Javaによる実装を含めて解説。
2001年6月の初版刊行以来、多くの読者から圧倒的に支持されてきた前著の増補改訂版です。改訂にあたっては、前著の内容を全面的に見直して、文章や表記をより適切な表現に改めています。
また、デザインパターンについて、読者が誤解しやすい点、間違いやすい点を、巻末に「Q&A」として追加しています。
デザインパターンについて学び、実践で使用したいプログラマはもちろん、オブジェクト指向の本質を理解したい人に最適の1冊です。 (参考:honto)

↓全て表示 ↑少なく表示
もちろんこの本だけでデザインパターンを完璧に習得しようとしたら不足なのはわかってるよ。でもさ「スッキリわかるJava」なんかでやっとJavaやオブジェクト指向の入り口までたどり着いた人間にとっては、本書が救世主のように感じられたヨ。これから先GoF本とかリファクタリングとかも読むと思うけど、イキナリじゃ難しすぎる。だからJavaに入門した後、次に読むにはこういうわかりやすい本が有用。 (参考:honto)

↓全て表示 ↑少なく表示

   

リファクタリング・コーディング技術の本 最新・高評価のおすすめの5冊

以下が「リファクタリング・コーディング技術の本」最新・高評価のおすすめの5冊詳細です。

(2022/01/25 12:01 更新)
Rank製品価格
1
4,180円
3,762円
4,180円
4,180円
2
リファクタリング 既存のコードを安全に改善する(第2版)...
発売日 2019/12/06
MartinFowler (オーム社)
総合評価
(4.6)
4,840円
4,356円
4,840円
4,840円
3
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)...
発売日 2012/06/23
Dustin Boswell, Trevor Foucher (オライリージャパン)
総合評価
(4.5)
2,640円
2,640円
2,640円
4
Code Complete 第2版 上 完全なプログラミングを目指して
発売日 2014/04/02
スティーブ マコネル (日経BP)
総合評価
(4.5)
6,710円
6,375円
6,710円
6,710円
5
レガシーコード改善ガイド
発売日 2016/01/15
マイケル・C・フェザーズ (翔泳社)
総合評価
(4.5)
4,620円
4,158円
4,620円
4,620円
 

Game Programming Patterns ソフトウェア開発の問題解決メニュー impress top gear...

開発経験に基づくパターン実践の極意!
パターン誕生の背景/エッセンス/適用条件/サンプルを解説。

ゲームプログラミングを含むソフトウェア開発の現場で、デザインパターンをより的確に利用するための解説書。著者は、米国大手ゲーム会社エレクトロニック・アーツでゲーム開発に従事。その経験に基づき、GoFや著者独自のパターンについて考察。より容易に変更できる洗練されたアーキテクチャ、ゲームに求められる実行速度といった視点を重視しつつ、幅広く応用できるパターンやゲーム必須のパターンを取り上げています。本書は、『Game Programming Patterns』の翻訳書です。米国アマゾンで60以上のレビューを集め、その9割が星5つと評価されています(2015年8月)。

【以下、本書イントロダクションより抜粋】
私がこの本で提供したいのは、解決策のメニューのようなものです。この本の各々の章では、単独でコードに適応可能なアイデアを解説しています。役立つものをメニューから選んで組み合わせることができます。

↓全て表示↑少なく表示
 
内容サンプル

(引用元楽天Books)

 
Users Voice
Webフロントエンドの複雑化に伴い、フロントエンドの設計手法の整備は現代の重要な課題だ。
そんななか、複雑なフロントエンドを何十年も構築してきたのは『ゲーム』の世界だ。
つまり状態をUIに変換していくにあたりどうモデリングするか、ゲームプログラミングからこそ学ぶ点があると思い、本書を手に取った。
この本は、いわゆるデザインパターンをどう道具としてフロントエンドで使っていくかを表したものである。
特定の技術スタックに依存した内容でないため、普遍的な知識を学ぶことができた。
特にコマンドパターンは見方を変えればFluxであり、現代Webフロントエンドにも繋がってくる考え方だ。
やはりこうした自分の領域にとらわれないすぎない知識収集が、最先端を歩んでくためには必要になってくるだろうと再確認した。 (参考:honto)

↓全て表示 ↑少なく表示
内容サンプル

(引用元楽天Books)

 
  

リファクタリング 既存のコードを安全に改善する(第2版)

リファクタリング 既存のコードを安全に改善する(第2版)
(著)MartinFowler
発売日 2019/12/06
総合評価
(4.6)
(2022/01/25 12:07時点)
※このKindle本はプリント・レプリカ形式で、Kindle Paperwhiteなどの電子書籍リーダーおよびKindle Cloud Readerではご利用いただけません。Fireなどの大きいディスプレイを備えたタブレット端末や、Kindle無料アプリ (Kindle for iOS、Kindle for Android、Kindle for PC、Kindle for Mac) でのみご利用可能です。また、文字列のハイライト、検索、辞書の参照、引用については、一部機能しない場合があります。文字だけを拡大することはできません。
※プリント・レプリカ形式は見開き表示ができません。
※この電子書籍は紙版書籍のページデザインで制作した固定レイアウトです。

ソフトウェア開発の名著、第2版登場!
 リファクタリングは、ソフトウェアの外部的な振る舞いを保ったままで、内部の構造を改善する作業を指します。本書はリファクタリングのガイドブックであり、リファクタリングとは何か、なぜリファクタリングをすべきか、どこを改善すべきか、実際の事例で構成され、ソフトウェア開発者にとって非常に役立つものとなっています。
 本第2版では、約20年前のオリジナル原稿の構成は変わらないものの、大幅に書き換えられているほか、サンプルコードがJavaからJava Scriptになるなど、現代的にアレンジされています。


第2版翻訳にあたって
初版の「本書に寄せて」
はじめに
Chap.1 リファクタリング-最初の例
Chap.2 リファクタリングの原則
Chap.3 コードの不吉な臭い
Chap.4 テストの構築
Chap.5 カタログの紹介
Chap.6 リファクタリングはじめの一歩
Chap.7 カプセル化
Chap.8 特性の移動
Chap.9 データの再編成
Chap.10 条件記述の単純化
Chap.11 APIのリファクタリング
Chap.12 継承の取り扱い
文献リスト 
訳者あとがき
索引

↓全て表示↑少なく表示
 
内容サンプル

(引用元Amazon)

 
目次
リファクタリングー最初の例
リファクタリングの原則
コードの不吉な臭い
テストの構築
カタログの紹介
リファクタリングはじめの一歩
カプセル化
特性の移動
データの再編成
条件記述の単純化
APIのリファクタリング
継承の取り扱い
Users Voice
リファクタリングに関する基本的な姿勢や考え方に関しては参考になる。
ただ、具体的な方法についてはこの本でしか得られない情報というものはほとんどなくリーダブルコード、プログラマが知るべき97のことなどの有名所を読んでいればだいたいエッセンスとしては知っているなというものが多かった気がする。数ポイントを得るには読んだ方がいいが他の本を読んでいるならプラスになる事は少ないかなというイメージ。 (参考:honto)

↓全て表示 ↑少なく表示
リファクタリングを実装に合わせて行うのは同感。
実行速度のチューニングはリファクタリングと相反していると考えがちだが、実は違う点はハッとした。基本に忠実にしっかり計測したい。
カタログは全体を通してざっくり読んだので、必要に応じて読み返したい。
データベースリファクタリングも少し気になった。 (参考:honto)

↓全て表示 ↑少なく表示
内容サンプル

(引用元Amazon)

 
著者略歴
児玉公信(コダマキミノブ)
(株)情報システム総研代表取締役社長。技術士(情報工学)、博士(情報学)。情報処理学会情報システムと社会環境研究会主査

友野晶夫(トモノマサオ)
フリーランスプログラマー

平澤章(ヒラサワアキラ)
ウルシステムズ株式会社所属。メインフレームからオープンシステム、マイコンまで多種多様なシステム開発を経験した後、2001年にウルシステムズのスタートアップに参画し、現在に至る

梅澤真史(ウメザワマサシ)
Smalltalkエバンジェリスト。2003年度IPA未踏ソフトウェア創造事業スーパークリエータ。(株)オージス総研、(株)豆蔵にてオブジェクト指向関連のコンサルティング、開発業務に従事した後、合同会社ソフトウメヤを立ち上げ現在に至る。SORABITO株式会社の技術フェローも兼任(本データはこの書籍が刊行された当時に掲載されていたものです)

↓全て表示↑少なく表示

  

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

「美しいコードを見ると感動する。優れたコードは見た瞬間に何をしているかが伝わってくる。そういうコードは使うのが楽しいし、
自分のコードもそうあるべきだと思わせてくれる。本書の目的は、君のコードを良くすることだ」(本書「はじめに」より)。

コードは理解しやすくなければならない。本書はこの原則を日々のコーディングの様々な場面に当てはめる方法を紹介します。
名前の付け方、コメントの書き方など表面上の改善について。コードを動かすための制御フロー、論理式、変数などループとロジックについて。
またコードを再構成するための方法。さらにテストの書き方などについて、楽しいイラストと共に説明しています。

日本語版ではRubyやgroongaのコミッタとしても著名な須藤功平氏による解説を収録。
 
内容サンプル

(引用元Amazon)

 
目次
理解しやすいコード
第1部 表面上の改善(名前に情報を詰め込む
誤解されない名前
美しさ
コメントすべきことを知る
コメントは正確で簡潔に)
第2部 ループとロジックの単純化(制御フローを読みやすくする
巨大な式を分割する
変数と読みやすさ)
第3部 コードの再構成(無関係の下位問題を抽出する
一度に1つのことを
コードに思いを込める
短いコードを書く)
第4部 選抜テーマ(テストと読みやすさ
「分
時間カウンタ」を設計・実装する)
付録 あわせて読みたい

↓全て表示↑少なく表示
Users Voice
仕事、趣味問わずプログラミングをする方におすすめです!内容は言語ではなく誰が見ても理解できるコードを書くには?をテーマに書いてます。勉強になりました! (参考:YahooShopping)

↓全て表示 ↑少なく表示
コーディング界隈でよく名前の挙がる名著ですが、非常に読みやすく、短期間で読了できました。 初学者からベテランまで活用できる内容となっております。 (参考:YahooShopping)

↓全て表示 ↑少なく表示
わかりやすいイラストと例え、そしてカジュアルな語り口でともすれば難解になりがちなプログラミングの概念を学ぶことができました。 (参考:YahooShopping)

↓全て表示 ↑少なく表示
内容サンプル

(引用元Amazon)

 
著者略歴
ボズウェル,ダスティン(Boswell,Dustin)
カリフォルニア工科大学で理学士号を取得。その後、カリフォルニア大学サンディエゴ校で修士号を取得。Google社で5年間勤務し、ウェブクローリング用のインフラなどさまざまなプロジェクトに携わる

フォシェ,トレバー(Foucher,Trevor)
10年以上もの間、Microsoft社でWindows2000やOneCare、Google社でWeb master Toolsなどのソフトウェアプロジェクトを送り出してきた。現在は独立コントリビュータ・マネージャ・テクニカルリードである

角征典(カドマサノリ)
1978年山口県生まれのプログラマ(本データはこの書籍が刊行された当時に掲載されていたものです)

↓全て表示↑少なく表示

  

Code Complete 第2版 上 完全なプログラミングを目指して

Code Complete 第2版 上 完全なプログラミングを目指して
(著)スティーブ マコネル
発売日 2014/04/02
総合評価
(4.5)
(2022/01/25 12:07時点)
ソフトウエア開発の方法論を幅広く網羅した入門書。上巻は設計やプログラミング、下巻はテストやデバッグを扱う。1993年発行の第1版を、Webアプリケーションの普及などを踏まえて大幅に改定した。著者はソフトウエア工学の第一人者で、知識体系「SWEBOK」の構築を主導する。計1200ページを超える大部だが、ソフト開発プロセスを建築設計にたとえるなど、難解になりがちな内容を分かりやすくまとめている。
本書は効果的なコンストラクションプラクティスについての知識を集めた、実践的なプログラミング解説書です。ソフトウェア開発プラクティスは目覚しい進歩を遂げていますが、一般のプログラマにはなかなか浸透しません。本書は、業界の第一人者らの知識と、一般の商用プラクティスとの橋渡しをします。10年前の第1版とコンセプトは同じですが、第2版は、全体を通じてオブジェクト指向の考え方が反映されたものになっています。また、「リファクタリング」の章が追加され、サンプルコードはC++、C#、Java、Visual Basicなどにアップデートされています。本書は、ソフトウェア開発の総合ガイドを求めている経験豊富なプログラマ、経験の浅いプログラマを教育する技術指導者、正式なトレーニングを受けたことのない独学プログラマ、これから社会に出る学生や新人プログラマなどを特に対象としています。本書で説明されている研究成果や過去の経験は、高品質なソフトウェアを作成し、問題を少なく抑えて作業をより短期間で行うのに役立ちます。また、大きなプロジェクトを制御し、要求の変更に応じてソフトウェアの保守や修正を適切に行うのにも役立ちます。

↓全て表示↑少なく表示
 
目次
第1部 基礎を固める(ソフトウェアコンストラクションへようこそ
ソフトウェア開発への理解を深めるメタファ ほか)
第2部 高品質なコードの作成(コンストラクションにおける設計
クラスの作成 ほか)
第3部 変数(変数の使用
変数名の力 ほか)
第4部 ステートメント(ストレートなコードの構成
条件文の使用 ほか)

↓全て表示↑少なく表示
Users Voice
「完璧なプログラムを目指して」というタイトルどおりの内容で、バグのないコードを目指す高い志のもとに書かれた本です。 もともと、プログラミングの書き方や命名規則はある程度自信はあったのですが、後輩のコードレビューをするときになぜこう書くのかなかなか説明できないことが多かったです。この本を読んでから、それを旨い理由をつけて説明できるようになりました。本のボリュームが半端ないので、飽き飽きする部分はあるのですが、プログラミング作法のなってない後輩をもったら買って損はないのではないでしょうか (参考:YahooShopping)

↓全て表示 ↑少なく表示
既に知ってたことも体系的にまとめられているので、非常に良い本だと思います。ざっと斜め読みしてどこに何が書いてあるか把握しておき、必要な時にその都度活用するのが良いと思います。 (参考:YahooShopping)

↓全て表示 ↑少なく表示
本書は効果的なコンストラクションプラクティスについての知識を集めた、実践的なプログラミング解説書です。
ソフトウェア開発プラクティスは目覚しい進歩を遂げていますが、一般のプログラマにはなかなか浸透しません。本書は、業界の第一人者らの知識と、一般の商用プラクティスとの橋渡しをします。
10年前の第1版とコンセプトは同じですが、第2版は全体を通じてオブジェクト指向の考え方が反映されたものになっています。また、「リファクタリング」の章が追加され、サンプルコードはC++、C#、Java、Visual Basicなどにアップデートされています。
本書は、ソフトウェア開発の総合ガイドを求めている経験豊富なプログラマ、経験の浅いプログラマを教育する技術指導者、正式なトレーニングを受けたことのない独学プログラマ、これから社会に出る学生や新人プログラマなどを特に対象としています。
本書で説明されている研究成果や過去の経験は、高品質なソフトウェアを作成し、問題を少なく抑えて作業をより短期間で行うのに役立ちます。また、大きなプロジェクトを制御し、要求の変更に応じてソフトウェアの保守や修正を適切に行うのにも役立ちます。
■目次
『Code Complete』への賛辞
はじめに
第1部 基礎を固める
第1章 ソフトウェアコンストラクションへようこそ
第2章 ソフトウェア開発への理解を深めるメタファ
第3章 2回測って、1度で切る:上流工程の必要性
第4章 コンストラクションの重要な決断
第2部 高品質なコードの作成
第5章 コンストラクションにおける設計
第6章 クラスの作成
第7章 高品質なルーチン
第8章 防御的プログラミング
第9章 擬似コードによるプログラミング
第3部 変数
第10章 変数の使用
第11章 変数名の力
第12章 基本的なデータ型
第13章 特殊なデータ型
第4部 ステートメント
第14章 ストレートなコードの構成
第15章 条件文の使用
第16章 ループの制御
第17章 特殊な制御構造
第18章 テーブル駆動方式
第19章 制御構造の問題
参考文献
索引  
著者紹介 (参考:honto)

↓全て表示 ↑少なく表示
著者略歴
マコネル,スティーブ(McConnell,Steve)
Construx Softwareのチーフソフトウェアエンジニアを務め、同社のソフトウェアエンジニアリングプラクティスを監督。また、SWEBOKプロジェクトを率いている。これまでに、Microsoft、Boeing、その他シアトル地域の企業で、ソフトウェアプロジェクトに従事。『Rapid Development』と『Code Complete』は、『Software Development』誌でその年の最優秀ソフトウェア開発書籍に与えられるJolt Excellence賞を受賞。また、Software Development Productivity賞を受賞したSPC Estimate Professionalの指導的開発者でもあった。1998年の『Software Development』誌の読者アンケートでは、ソフトウェア業界において最も影響力のある人物として、Bill Gates、Linus Torvaldsと共に選ばれている。ウィットマンカレッジで学士号を取得し、シアトル大学でソフトウェアエンジニアリングの修士号を取得。現在はワシントン州のベルビュー在住(本データはこの書籍が刊行された当時に掲載されていたものです)

↓全て表示↑少なく表示

  

レガシーコード改善ガイド

レガシーコード改善ガイド
(著)マイケル・C・フェザーズ
発売日 2016/01/15
総合評価
(4.5)
(2022/01/25 12:07時点)

保守開発のためのリファクタリング!

本書は、システム保守の現場でありがちな、構造が複雑で理解できないようなコードに対する分析手法・対処手法について解説します。つまり、「コードを理解し、テストできるようにし、リファクタリングを可能にし、機能を追加できるテクニックを紹介している書籍です。

本書には、以下のことが記載されています。
●仕様が分からないコードの分析方法
●仕様が分からないコードの修正方法、またテストコードの追加方法
●コードの修正で、疎結合な設計に部分的に改善する方法

また、本書には、以下のことは記載されていません。
●COBOLなどで記述されているメインフレーム上のアプリケーションの改修方法

【 対象読者】
●現行のシステムが仕様が分からず保守作業に悩む、保守担当者
●現行のシステムの修正作業は可能であるもののデグレーションに悩む、保守担当者
●疎結合な設計手法を知りたい技術者

本書はJava、C、C++でサンプルを記述していますが、記載されているテクニックは言語依存するものではないため、他の言語(Delphi、Visual Basic、COBOL、FORTRAN)でも使えます。

※本電子書籍は同名出版物を底本として作成しました。記載内容は印刷出版当時のものです。
※印刷出版再現のため電子書籍としては不要な情報を含んでいる場合があります。
※印刷出版とは異なる表記・表現の場合があります。予めご了承ください。
※プレビューにてお手持ちの電子端末での表示状態をご確認の上、商品をお買い求めください。


↓全て表示↑少なく表示
 
内容サンプル

(引用元Amazon)

 
目次
第1部 変更のメカニズム
第1章 ソフトウェアの変更
1.1 ソフトウェア変更の4つの理由
1.2 危険な変更
第2章 フィードバックを得ながらの作業
2.1 単体テストとは
2.2 上位レベルのテスト
2.3 テストによる保護
2.4 レガシーコードの変更手順
第3章 検出と分離
3.1 協調クラスの擬装
第4章 接合モデル
4.1 巨大な用紙の文字の羅列
4.2 接合部
4.3 接合部の種類
第5章 ツール
5.1 自動リファクタリングツール
5.2 モックオブジェクト
5.3 単体テストハーネス
5.4 一般的なテストハーネス
第2部 ソフトウェアの変更
第6章 時間がないのに変更しなければなりません
6.1 スプラウトメソッド
6.2 スプラウトクラス
6.3 ラップメソッド
6.4 ラップクラス
6.5 まとめ
第7章 いつまで経っても変更作業が終わりません
7.1 理解すること
7.2 遅延時間
7.3 依存関係の排除
7.4 まとめ
第8章 どうやって機能を追加すればよいのでしょうか?
8.1 テスト駆動開発(TDD)
8.2 差分プログラミング
8.3 まとめ
第9章 このクラスをテストハーネスに入れることができません
9.1 いらだたしいパラメータ
9.2 隠れた依存関係
9.3 複雑な生成
9.4 いらだたしグローバルな依存関係
9.5 恐るべきインクルードの依存関係
9.6 玉ねぎパラメータ
6.7 別名のパラメータ
第10章 このメソッドをテストハーネスで動かすことができません
10.1 隠れたメソッド
10.2 言語の「便利な」機能
10.3 検出できない副作用
第11章 変更する必要がありますが、どのメソッドをテストすればよいのでしょうか?
11.1 影響の調査
11.2 前方向の調査
11.3 影響の伝播
11.4 影響調査のためのツール
11.5 影響スケッチの単純化
第12章 1ヶ所にたくさんの変更が必要ですが、関係するすべてのクラスの依存関係を排除すべきでしょうか?
12.1 割り込み点
12.2 絞り込み点で設計を判断する
12.3 絞り込み点の落とし穴
第13章 変更する必要がありますが、どんなテストを書けばよいのかわかりません
13.1 仕様化テスト
13.2 クラスの仕様を明らかにする
13.3 狙いを定めたテスト
13.4 仕様化テストを書くための経験則
第14章 ライブラリへの依存で身動きが取れません
第15章 私のアプリケーションはAPI呼び出しだらけです
第16章 変更できるほど十分に私はコードを理解していません
16.1 メモを取る/スケッチを描く
16.2 印を付ける
16.3 試行リファクタリング
16.4 使用していないコードを削除する
第17章 私のアプリケーションには構造がありません
17.1 システムのストーリーを話す
17.2 白紙のCRC
17.3 会話の吟味
第18章 自分のテストコードが邪魔になっています
18.1 クラスの命名規約
18.2 テストコードの配置
第19章 私のプロジェクトはオブジェクト指向ではありませんが、どうすれば安全に変更できるでしょうか?
19.1 簡単なケース
19.2 困難なケース
19.3 新しい振る舞いの追加
19.4 オブジェクト指向の長所の活用
19.5 すべてはオブジェクト指向
第20章 このクラスは大きすぎて、もうこれ以上大きくしたくありません
20.1 責務の把握
20.2 その他の技法
20.3 先へ進む
20.4 クラスの抽出後
第21章 同じコードをいたるところで変更しています
21.1 最初のステップ
第22章 モンスターメソッドを変更する必要がありますが、テストを書くことができません
22.1 モンスターの変種
22.2 自動リファクタリング機能でモンスターに立ち向かう
22.3 手作業によるリファクタリングに挑戦
22.4 戦略
第23章 どうすれば何も壊していないことを確認できるでしょうか?
23.1 超集中編集
23.2 単一目的の編集
23.3 シグネチャの維持
23.4 コンパイラまかせ
23.5 ペアプログラミング
第24章 もうウンザリです。何も改善できません
第3部 依存関係を排除する手法
第25章 依存関係を排除する手法
25.1 パラメータの適合
25.2 メソッドオブジェクトの取り出し
25.3 定義の補完
25.4 グローバル参照のカプセル化
25.5 静的メソッドの公開
25.6 呼び出しの抽出とオーバーライド
25.7 Factory Methodの抽出とオーバーライド
25.8 getメソッドの抽出とオーバーライド
25.9 実装の抽出
25.10 インタフェースの抽出
25.11 インスタンス委譲の導入
25.12 静的setメソッドの導入
25.13 リンクによる置き換え
25.14 コンストラクタのパラメータ化
25.15 メソッドのパラメータ化
25.16 パラメータのプリミティブ化
25.17 メソッドと変数の引き上げ
25.18 依存関係の押し出し
25.19 関数ポインタによる関数の置き換え
25.20 getメソッドによるグローバル参照の置き換え
25.21 サブクラス化とメソッドのオーバーライド
25.22 インスタンス変数の入れ替え
25.23 テンプレートによる再定義
25.24 テキストによる再定義
付録A リファクタリング
A1 メソッドの抽出
付録B 用語集

↓全て表示↑少なく表示
Users Voice
レガシーコードで悩んでたので何かのヒントが得られるかと思って購入しました。 これから頑張って読みたいと思います (参考:YahooShopping)

↓全て表示 ↑少なく表示
レガシーコードをいかにHackしてテストケースの作成やリファクタリングを行うかの本。
JavaやC++はともかくCでリンカを変えて本番コードからテスト用のモックを参照するというのは目から鱗でした。
既に存在するレガシーコードに対してのアプローチを前提に書かれているため大抵の現場で役に立つと思われますw(サンプルコードはJava/C++/Cが中心だけど別言語でもたぶん置き換えは可能)
リファクタリングに伴う影響の調査
  ↓
本番コードをテストコードで保護&本番コードに依存性を注入しテストしやすくする
  ↓
本番コードを修正
といった石橋を叩きすぎて渡るというポリシーが素敵。プロなら品質を担保するためにこれくらいやるべきですよねw
ただし内容は非常に難しいので、最低でも「リファクタリング プログラムの体質改善テクニック」や「クリーンコード」を読んでいることが前提かと。
http://booklog.jp/users/sue445/archives/4894712288
http://booklog.jp/users/sue445/archives/4048676881
読み終わった本の中で仕事中にもすぐ手にとりたい物は机の上に立てているのですが、この本は表紙の「テストがないコードはレガシーコードだ!」が非常にショッキングなため机の上にみんなに表紙が見えるように置いていますw (参考:honto)

↓全て表示 ↑少なく表示
2ヶ月前に途中まで書いたコードの続きを最近覚えたTDDでと思ったら、テストするためにはリファクタリングが必要で、リファクタリングにはテストが必要でとデッドロックしたので読んだ。
リファクタリング発展編。アンチパターン的な。でも人ごとではなく身の回りで常に見かける現実なのでお役立ち度は高い。自動テストがない状態のコードをどのようにテスト可能、リファクタリング可能な状態に持っていくか。テストのないコードを変更することが如何に大変かの例をこれでもかと見せられることでテストの重要性をヒシヒシと感じる本。サンプルはJava7割、C/C++3割。
自動テストがあれば素早いフィードバックが得られる。すると、間違いにすぐに気づいて手戻りが減る、デグレードを起こさない安心が得られる。直接的な効果だけでなく、対象コードについての記憶が残っているうちに対処できるので思い出す手間が不要だし、手動確認による繰り返し作業がなくなって退屈しないし、何より結果がすぐ出て頻繁に達成感が得られるのは楽しい、と良いこと尽くめ。
最近はJMockitとかのモックフレームワークでバイトコードから差し替えられるのでレガシーコードのジレンマは当時ほどではないのかもしれない。 (参考:honto)

↓全て表示 ↑少なく表示
内容サンプル

(引用元Amazon)

 
著者略歴
フェザーズ,マイケル・C.(Feathers,Michael C.)(フェザーズ,マイケルC.)
Object Mentor社勤務。現在、TDD(テスト駆動開発)、リファクタリング、オブジェクト指向設計、Java、C#、C++、XP(エクストリームプログラミング)に関するトレーニングやメンタリングを世界レベルで実践している。またCppUnit(JUnitをC++に移植したテスティングフレームワーク)、およびFitCPP(FITをC++に移植した統合テスティングフレームワーク)のオリジナル開発者でもある。ACMおよびIEEE会員

平澤章(ヒラサワアキラ)
ウルシステムズ株式会社ディレクター。金融機関向け第3次オンラインシステムなどのシステム開発業務や技術コンサルティング業務に従事した後、2001年より現職

越智典子(オチノリコ)
1988年株式会社オージス総研入社。オブジェクト指向技術に携わった後、2001年に同社を退社。以後、フリーランスの翻訳者として活動中

稲葉信之(イナバノブユキ)
ウルシステムズ株式会社シニアコンサルタント。テクマトリックス株式会社でアプリケーションサーバーのサポートや日本語化対応、およびシステム開発業務に従事した後、2007年より現職。現職では基幹システムの開発や、開発案件の技術支援に従事している

田村友彦(タムラトモヒコ)
ウルシステムズ株式会社シニアコンサルタント。ICカードの通信プロトコルからWebアプリケーションまで、さまざまなソフトウェア開発をさまざまな言語・環境で経験してきた。2006年より現職。現在は、技術的な支援を行う立場でシステム開発に携わる

小堀真義(コボリマサヨシ)
ウルシステムズ株式会社シニアコンサルタント。Webアプリケーションやセキュリティ基盤の開発を経験し、2006年より現職(本データはこの書籍が刊行された当時に掲載されていたものです)

↓全て表示↑少なく表示

   

リファクタリング・コーディング技術の本「Kindle Unlimited 読み放題 人気本ランキング」

「Kindle Unlimited」は、Amazonの定額本読み放題サービス。

最近はKindle Unlimitedで読める本もどんどん増えており、雑誌、ビジネス書、実用書などは充実のラインナップ。

以下がKindle Unlimitedで読み放題となるリファクタリング・コーディング技術の本の一覧です。

30日無料体験も可能なので、読みたい本があれば体験期間で無料で読むことも可能です。

(2022/01/25 12:01 更新)
 

リファクタリング本「新書一覧(2020年、2021年刊行)」

IT技術・プログラミング言語は、最新情報のキャッチアップも非常に重要、すなわち新書は要チェック

ということで、2020年以降に発売したリファクタリング本の新書一覧(発売日の新しい順)が以下です。

(2022/01/25 12:07 更新)
製品価格
リファクタリング:Rubyエディション
発売日 2020/03/21
ジェイ・フィールズ, シェーン・ハービー, マーティン・ファウラー (復刊ドットコム)
総合評価
(4.5)
8,800円
8,800円
8,800円
リファクタリング 既存のコードを安全に改善する(第2版)...
発売日 2019/12/06
MartinFowler (オーム社)
総合評価
(4.6)
4,840円
4,356円
4,840円
4,840円
2,398円
2,278円
2,398円
2,398円
レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス...
発売日 2019/09/19
David Scott Bernstein (オライリージャパン)
総合評価
(4.3)
3,190円
3,190円
3,190円
1,200円
2,618円
2,487円
2,618円
2,618円
新装版 リファクタリング 既存のコードを安全に改善する...
発売日 2017/07/15
MartinFowler (オーム社)
総合評価
(4.1)
4,562円
4,620円
4,620円
4,250円
2,838円
2,838円
2,838円
2,838円
レガシーコード改善ガイド
発売日 2016/01/15
マイケル・C・フェザーズ (翔泳社)
総合評価
(4.5)
4,620円
4,158円
4,620円
4,620円
4,180円
3,762円
4,180円
4,180円
C#実践開発手法 (マイクロソフト公式解説書)
発売日 2015/06/04
Gary McLean Hall (日経BP)
総合評価
(4.1)
1,955円
5,500円
5,500円
独習デザインパターンC++
発売日 2015/03/27
株式会社テクノロジックアート (翔泳社)
総合評価
(3.4)
7,664円
3,600円
3,740円
3,740円
Code Complete 第2版 上 完全なプログラミングを目指して
発売日 2014/04/02
スティーブ マコネル (日経BP)
総合評価
(4.5)
6,710円
6,375円
6,710円
6,710円
400円
増補改訂版 Java言語で学ぶデザインパターン入門
発売日 2014/03/12
結城 浩 (SBクリエイティブ)
総合評価
(4.3)
4,180円
3,762円
4,180円
2,748円
Java言語で学ぶリファクタリング入門
発売日 2014/03/12
結城 浩 (SBクリエイティブ)
総合評価
(4.2)
5,400円
3,520円
3,520円
1,045円
2,034円
2,218円
2,464円
2,104円
2,750円
2,750円
2,750円
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)...
発売日 2012/06/23
Dustin Boswell, Trevor Foucher (オライリージャパン)
総合評価
(4.5)
2,640円
2,640円
2,640円
ドメイン特化言語 パターンで学ぶDSLのベストプラクティス46項目...
発売日 2012/05/02
マーチン ファウラー, Martin Fowler (ピアソン桐原)
総合評価
(3.8)
1,380円
6,270円
1,454円
 

関連:オブジェクト指向プログラミング・デザインパターンを学ぶ

コードの品質を上げるリファクタリング知識とともに重要なのが、プログラム設計に関する知識です。

安全・堅牢・再利用性の高い設計ができることで、プログラムの保守や拡張性高く運用していくことが可能。

以下では、設計の重要な要素となる「オブジェクト指向プログラミング(OOP)」「デザインパターン」に関する書籍を紹介しています、合わせてのぞいて見てください。

 

関連:最新おすすめのKindle端末

以下では最新のKindle端末について比較、おすすめ紹介しています、合わせてのぞいて見てください。

いじょうでっす。

コメント

タイトルとURLをコピーしました