良いコード/悪いコードで学ぶ設計入門―保守しやすい成長し続けるコードの書き方 改訂新版 [単行本]

良いコード/悪いコードで学ぶ設計入門―保守しやすい成長し続けるコードの書き方 改訂新版 の 商品概要

• 要旨（「BOOK」データベースより）

  本書は、より成長させやすいコードの書き方と設計を学ぶ入門書です。システム開発では、ソフトウェアの変更が難しくなる事態が頻発します。コードの可読性が低く調査に時間がかかる、コードの影響範囲が不明で変更すると動かなくなる、新機能を追加したいがどこに実装すればいいかわからない…。変更しづらいコードは、成長できないコードです。ビジネスの進化への追随や、機能の改善が難しくなります。成長できないコードの問題を、設計で解決します。

• 目次

  改訂新版　まえがき
  はじめに
  謝辞
  
  第1章 悪しき構造の弊害を知覚する
  1.1 意味不明な命名
  1.2 理解を困難にする条件分岐のネスト
  1.3 さまざまな悪魔を招きやすいデータクラス
  1.3.1 仕様変更時に牙をむく悪魔
  1.3.2 重複コード
  1.3.3 修正漏れ
  1.3.4 可読性低下
  1.3.5 未初期化状態（生焼けオブジェクト）
  1.3.6 不正値の混入
  1.4 悪魔退治の基本
  
  第2章 設計の初歩
  2.1 省略せずに意図が伝わる名前を設計する
  2.2 変数を使い回さない、目的ごとの変数を用意する
  2.3 ベタ書きせず、目的ごとのまとまりでメソッド化
  2.4 関係し合うデータとロジックをクラスにまとめる
  
  第3章 カプセル化の基礎―ひとつにまとめる―
  3.1 クラス単体で正常に動作するよう設計する
  3.1.1 データクラスは単体での正常動作が困難
  3.1.2 クラスが自分自身でドメインモデルの完全性を保証する
  3.1.3 悪魔に負けない、頑強なクラスの構成要素
  3.2 成熟したクラスへ成長させる設計術
  3.2.1 コンストラクタで確実に正常値を設定する
  3.2.2 計算ロジックをデータ保持側に寄せる
  3.2.3 不変で思わぬ動作を防ぐ
  3.2.4 変更したい場合は新しいインスタンスを作成する
  3.2.5 メソッド引数やローカル変数にもfinalを付け不変にする
  3.2.6 「値の渡し間違い」を型で防止する
  3.2.7 現実の営みにはないメソッドを追加しないこと
  3.3 悪魔退治の効果を検証する
  3.4 プログラム構造の問題解決に役立つ設計パターン
  3.4.1 完全コンストラクタ
  3.4.2 値オブジェクト
  Column 種類の異なる言語と本書のノウハウ
  
  第4章 不変の活用―安定動作を構築する―
  4.1 再代入
  4.1.1 不変にして再代入を防ぐ
  4.1.2 引数も不変にする
  4.2 可変がもたらす意図せぬ影響
  4.2.1 ケース1　可変インスタンスの使い回し
  4.2.2 ケース2　関数による可変インスタンスの操作
  4.2.3 副作用のデメリット
  4.2.4 関数の影響範囲を限定する
  4.2.5 不変にして予期せぬ動作を防ぐ
  4.3 不変と可変の取り扱い方針
  4.3.1 デフォルトは不変に
  4.3.2 どんなとき可変にしてよいか
  4.3.3 正しく状態変更するメソッドを設計する
  4.3.4 コード外とのやりとりは局所化する
  
  第5章 バラバラなデータとロジックをカプセル化する実践技法
  5.1 プリミティブ型執着
  5.2 staticメソッドの誤用
  5.2.1 staticメソッドはインスタンス変数を使えない
  5.2.2 インスタンス変数を使う構造につくり変える
  5.2.3 インスタンスメソッドのフリしたstaticメソッドに注意
  5.2.4 どうしてstaticメソッドが使われてしまうのか
  5.2.5 どういうときにstaticメソッドを使えばいいのか
  5.3 初期化ロジックの分散
  5.3.1 privateコンストラクタ+ファクトリメソッドで目的別初期化
  5.3.2 生成ロジックが増えすぎたらファクトリクラスを検討すること
  5.4 共通処理クラス（Common・Util）
  5.4.1 さまざまなロジックが雑多に置かれがち
  5.4.2 オブジェクト指向設計の基本に立ち返ろう
  5.4.3 横断的関心事
  5.5 結果を返すために引数を使わないこと
  Column C#のoutキーワード
  5.6 多すぎる引数
  5.6.1 意味のある単位ごとにクラス化する
  5.7 アクセス連鎖
  5.7.1 尋ねるな、命じろ
  
  第6章 関心の分離という考え方―分けて整理する―
  6.1 関心の分離の基本
  6.1.1 インスタンス変数ごとにクラスを分割する
  6.1.2 依存関係を図式化しよう
  6.2 目的の違いを見破り、分離しカプセル化する
  6.3 インターフェイスと実装の分離
  6.3.1 関心の分離がうまくいかない原因
  
  第7章 関心が混ざったコードを分けて整理する実践技法
  7.1 ロジックの流用
  7.1.1 単一責任の原則
  7.1.2 責任が単一になるようクラスを設計する
  7.1.3 DRY原則の誤用
  Column クソコード動画「共通化の罠」
  7.2 継承による関心の混在
  7.2.1 スーパークラス依存
  7.2.2 継承より委譲
  7.2.3 継承による悪しき共通化
  Column クソコード動画「継承」
  7.3 関心が混在する各種事例と対処方法
  7.3.1 なんでもpublic
  7.3.2 privateメソッドだらけ
  7.3.3 スマートUI
  7.3.4 巨大データクラス
  7.3.5 トランザクションスクリプトパターン
  7.3.6 神クラス
  7.3.7 巨大なクラスの対処法
  
  第8章 条件分岐―迷宮化した分岐処理を解きほぐす技法―
  8.1 条件分岐のネストによる可読性低下
  8.1.1 早期returnでネスト解消
  8.1.2 コードの見通しを悪くするelse句も早期returnで解決
  8.2 switch文の重複
  8.2.1 即座にswitch文を書いてしまう
  8.2.2 同じ条件式のswitch文が複数書かれていく
  8.2.3 仕様変更時の修正漏れ（case文追加漏れ）
  8.2.4 爆発的に増殖するswitch文の重複
  8.2.5 条件分岐を一箇所にまとめる
  8.2.6 よりスマートにswitch文重複を解消するinterface
  8.2.7 interfaceをswitch文重複に応用（ストラテジパターン）
  Column クソコード動画「switch文」
  8.3 interface設計の考え方を身につけよう
  8.3.1 機能を取り換える単位を見つける
  8.3.2 結果と入力が同じかどうかを確認する
  8.3.3 interfaceを定義する
  8.3.4 interfaceを実装したクラスをつくる
  8.3.5 機能を取り換えるしくみをつくる
  8.4 条件分岐の重複とネスト
  8.4.1 ポリシーパターンで条件を集約する
  8.5 型の判定で分岐しないこと
  8.6 フラグ引数
  8.6.1 メソッドを分離する
  8.6.2 ストラテジパターンで機能を取り換えられるようにする
  8.7 interfaceの使いこなしが中級者への第一歩
  
  第9章 コレクション―ネストを解消する構造化技法―
  9.1 自前でコレクション処理を実装してしまう
  Column 車輪の再発明
  9.2 ループ処理中の条件分岐ネスト
  9.2.1 continueで条件分岐のネストを解消する
  9.2.2 breakもネスト解消に役立つ
  9.3 バラバラなコレクション処理
  9.3.1 コレクション処理をカプセル化する
  9.3.2 外部へ渡す場合はコレクションを変更できなくする
  
  第10章 設計の健全性をそこなうさまざまな悪魔たち
  10.1 デッドコード
  10.2 YAGNI原則
  10.3 マジックナンバー
  10.4 文字列型執着
  10.5 グローバル変数
  10.5.1 カプセル化とパッケージ依存の設計で影響範囲を小さくする
  10.6 null問題
  10.6.1 nullを返さない、渡さない、代入しない
  10.6.2 null安全
  10.7 例外の握り潰し
  10.7.1 原因分析困難に陥り開発者を疲弊させる
  10.7.2 問題検出時にけたたましく叫ばせる
  10.8 設計秩序を破壊するメタプログラミング
  10.8.1 リフレクションによるクラス構造および値の変更
  10.8.2 型の強みを活かせなくなる、クラス名やメソッド名のハードコード
  10.8.3 デメリットを理解し用途を限定すること
  10.9 技術駆動パッケージング
  10.10 サンプルコードのコピペ
  10.11 銀の弾丸
  
  第11章 名前設計―あるべき構造を見破る名前―
  11.1 悪魔を呼び寄せる名前
  11.1.1 関心事ごとに分割する
  11.1.2 関心事にふさわしい命名
  11.1.3 大雑把で意味が不明瞭な名前
  11.2 名前を設計する―目的駆動名前設計
  11.2.1 可能な限り具体的で、意味が狭い、目的に特化した名前を選ぶ
  11.2.2 存在駆動ではなく目的駆動で名前を考える
  11.2.3 どんな業務目的があるか分析する
  11.2.4 声に出して話してみる
  11.2.5 利用規約を読んでみる
  11.2.6 違う名前に置き換えられないか検討する
  11.2.7 関心が分離されているか点検する
  11.3 設計時の注意すべきリスク
  11.3.1 名前無頓着になるな
  11.3.2 仕様変更時の「意味の変化」に警戒
  11.3.3 構造改善を妨げるアンカリング効果
  11.3.4 会話には登場するがコード上に登場しない名前に注意
  11.3.5 名前を知らないものは知覚できない
  11.3.6 形容詞で区別しているときはクラス化のチャンス
  11.4 意図がわからない名前
  11.4.1 技術駆動命名
  Column 技術駆動命名を用いる分野もある
  11.4.2 ロジック構造をなぞった名前
  11.4.3 驚き最小の原則
  11.5 構造を歪ませてしまう名前
  11.5.1 データクラスになりがちな名前
  11.5.2 DTO（Data Transfer Object）
  11.5.3 クラスが巨大化する名前
  Column クソコード動画「Managerクラス」
  11.5.4 文脈よって意味や扱いが異なる名前
  11.5.5 連番命名
  11.6 名前的に居場所が不自然なメソッド
  11.6.1 「動詞+目的語」のメソッド名に注意
  11.6.2 可能な限り動詞1語で済む名前にする
  11.6.3 不適切な居場所のbooleanメソッド
  11.7 名前の省略
  11.7.1 意図がわからなくなる省略
  11.7.2 基本的に名前は省略しないこと
  11.7.3 そのほか省略をどう判断するか
  
  第12章 コメント―保守と変更の正確性を高める書き方―
  12.1 退化コメント
  12.1.1 コメントは劣化コピーにすぎないことを理解すること
  12.1.2 ロジックの挙動をなぞるだけのコメントは退化しやすい
  12.2 コメントで命名をごまかす
  12.3 目的や仕様変更時の注意点を読み手に伝えること
  12.4 コメントのルール　まとめ
  12.5 ドキュメントコメント
  
  第13章 メソッド（関数） ―良きクラスには良きメソッドあり―
  13.1 必ず自身のクラスのインスタンス変数を使うこと
  13.2 不変をベースに予期せぬ動作を防ぐ関数にすること
  13.3 尋ねるな、命じろ
  Column クソコード動画「カプセル化」
  13.4 コマンド・クエリ分離
  13.5 引数
  13.5.1 引数は不変にすること
  13.5.2 フラグ引数は使わない
  13.5.3 nullを渡さない
  13.5.4 出力引数は使わない
  13.5.5 引数は可能な限り少なく
  13.6 戻り値
  13.6.1 「型」を使って戻り値の意図を表明すること
  13.6.2 nullを返さない
  13.6.3 エラーは戻り値で返さない、例外をスローすること
  Column メソッドの名前設計
  Column staticメソッドの扱いに注意
  
  第14章 モデリング―クラス設計の土台―
  14.1 邪悪な構造に陥りがちなUserクラス
  14.2 モデリングの考え方とあるべき構造
  14.2.1 システムとは何か
  14.2.2 システム構造とモデリング
  14.2.3 ソフトウェア設計におけるモデリング
  14.3 良くないモデルの問題点と解決方法
  14.3.1 Userとシステムの関係
  14.3.2 仮想世界を表現する情報システム
  14.3.3 目的別にモデリングする
  14.3.4 モデルはモノではなく目的達成手段
  14.3.5 単一責任とは単一目的
  14.3.6 モデルの見直し方
  14.3.7 モデルと実装は必ず相互にフィードバックする
  Column クソコード動画「Userクラス」
  14.4 機能性を左右するモデリング
  14.4.1 裏に隠れた真の目的を見破る
  14.4.2 機能性をイノベートする「深いモデル」
  
  第15章 リファクタリング―既存コードを成長に導く技―
  15.1 リファクタリングの流れ
  15.1.1 ネストを解消し、コードの見通しを良くする
  15.1.2 意味のある単位にロジックをまとめる
  15.1.3 条件を読みやすくする
  15.1.4 ベタ書きロジックを目的を表すメソッドに置き換える
  15.2 安全にリファクタリングする方法
  15.2.1 コードの課題を整理する
  15.2.2 テストコードを用いたリファクタリングの流れ
  15.3 あやふやな仕様を理解するための分析方法
  15.3.1 仕様分析方法1：仕様化テスト
  15.3.2 仕様分析方法2：試行リファクタリング
  15.4 IDE のリファクタリング機能
  15.4.1 リネーム（名前の変更）
  15.4.2 メソッド抽出
  15.5 リファクタリングで注意すべきこと
  15.5.1 機能追加とリファクタリングを同時にやらない
  15.5.2 スモールステップで実施す

• 内容紹介

  本書は、より成長させやすいコードの書き方と設計を学ぶ入門書です。筆者の経験をふまえ構成や解説内容を見直し、より実践的な一冊になりました。
  システム開発では、ソフトウェアの変更が難しくなる事態が頻発します。 コードの可読性が低く調査に時間がかかる、 コードの影響範囲が不明で変更すると動かなくなる、 新機能を追加したいがどこに実装すればいいかわからない......。
  変更しづらいコードは、成長できないコードです。 ビジネスの進化への追随や、機能の改善が難しくなります。
  成長できないコードの問題を、設計で解決します。

• 著者紹介（「BOOK著者紹介情報」より）（本データはこの書籍が刊行された当時に掲載されていたものです）

  仙塲 大也(センバ ダイヤ)
  青森県出身。大手電機メーカーからＷｅｂ業界へ転身。アプリケーションアーキテクトとして、リファクタリングやアーキテクチャ改善、若手の設計スキル育成といった、設計全般を推進する業務に従事。Ｘ（旧Ｔｗｉｔｔｅｒ）ではプログラミングの風刺動画を不定期で投稿。登壇実績多数。Ｄｅｖｅｌｏｐｅｒｓ　Ｓｕｍｍｉｔではベストスピーカー賞など受賞多数

• 著者について

  仙塲 大也 (センバ ダイヤ)
  X（旧Twitter） : ミノ駆動（@MinoDriven）青森県出身。大手電機メーカーからWeb業界へ転身。アプリケーションアーキテクトとして、リファクタリングやアーキテクチャ改善、若手の設計スキル育成といった、設計全般を推進する業務に従事。悪しきコードとの戦いの中で設計の魅力に気付く。暇さえあれば脳内でリファクタリングしている。X（旧Twitter）ではプログラミングの風刺動画を不定期で投稿。登壇実績多数。Developers Summitではベストスピーカー賞など受賞多数。

良いコード/悪いコードで学ぶ設計入門―保守しやすい成長し続けるコードの書き方 改訂新版 の商品スペック