『良いコード/悪いコードで学ぶ設計入門』著者トーク
概要
2022/04/26に開催された下記勉強会のメモです
こちらにも記事があります
セッション
書籍『良いコード/悪いコードで学ぶ設計入門』でエンジニアリングの当たり前を変える
本書で向上が期待できるスキル
- 悪きコードが見えるようになる→理想形を知る、正しく対処できるように
- 変更に強い構造を設計するスキル
本書の特徴
- 初級〜中級者向け
- 膨大なサンプルコードと事例で解説
- 実践で使えるオブジェクト指向設計
- Javaで書かれている
- ドツボにはまりそうなパターンを網羅
プログラミングの入門書を学習し終わった後、まだ初級レベルの段階で設計スキルを向上させようとなった時に読める本は少ない（いきなり中級以上のレベルになる）
- どういうのが悪きコードなのか、設計でどう解決すればいいのか
- チーム全体の設計力向上、底上げ
- 設計の論理武装
- 技術的負債の返済のためになぜその技術選択・設計をするのか、どういう効果があるのか
- 再現性のある罠に対する対処方法
- 悪きコードが書かれるタイミングは、仕様変更時
第1章：悪きコードの弊害から痛みを知る
- そもそも「設計しなければ」という危機意識が必要
- 悪しきコードによる弊害をダイジェスト的に紹介
第2章：設計の初歩
- 簡単な命名やメソッドの設計をベースにどういうことをするのが設計なのかを学ぶ
第3章：Value Objectを中心に学ぶ
- ここから本番
- 低凝集で貧弱なデータクラスを高凝集なValueObjectへ成長させる例を用いてクラス設計の基本を解説
第4章：不変の活用 安定動作を構築する
- 変数の値を変更できること、状態変更可能なこと→可変
- 変更不能なこと→不変
- 可変が前提だと意図しない間に値にすり変わるなど挙動の予測が難しくなる
- 不変を活用して予測しやすい安定した挙動の設計方法を解説
第5章：低凝集 バラバラになったモノたち
- 強く関連し合うデータとロジックがバラバラに斬罪している構造→低凝集
- 低凝集は重複コードや修正漏れを生じさせ、何かと厄介
第6章：条件分岐 迷宮化した分岐処理を解きほぐす技法
- 条件分岐は杜撰に扱うとロジックが複雑になり混乱する
- 条件分岐の複雑さを低減し、コントロールできるようになるための設計方法を解説
- インタフェースの使いこなし方
第7章：コレクション ネストを解消する構造化技法
- 配列やリストなどのコレクションはループ処理などでロジックが混乱しがち
- コレクション周りのロジックを明確にする設計を解説
第8章：密結合 絡まって解きほぐせない構造
- 責務の異なる様々なロジックが複雑に絡み合い、依存関係が強い構造→密結合
- 密結合はわずかなロジック変更でも多くの場所に影響が伝播しやすく、バグ化しやすい→変更に弱い
- 「単一責任の原則」をベースに密結合な構造を疎結合な構造へ改善する設計手法を解説
第9章：設計の健全性をそこなうさまざまな悪魔たち
- null問題、例外の握り潰しなど
第10章：名前設計 あるべき構造を見破る名前
- メソッドやクラスに付与する名前は可読性に影響するだけでなく、ロジック構造を大きく左右する
- 最適なロジック構造を導き出すための名前の設計法補を解説→著者が提唱の「目的駆動名前設計」
第11章：コメント 保守と変更の正確性を高める書き方
- いい加減なコメントを書くと読み手に正しく意図が伝わらなかったり、ウソを伝えてしまう可能性がある
第12章：メソッド（関数） 良きクラスには良きメソッドあり
- メソッド設計が良くないとクラス設計が悪化する
第13章：モデリング クラス設計の土台
- 物事の特徴や関係性を簡単に図に表したもの→モデル
- モデルを作る活動→モデリング
- モデルがいい加減でったり、モデリング自体をしないとクラス構造が粗悪になり変更が難しくなる
第14章：リファクタリング 既存コードを成長に導く技
- リファクタリングis何？
- テストがないコードのリファクタ方法、リファクタリング時に陥りやすい罠など
第15章：設計の意義と設計への向き合い方
- なんのために設計するのか、その意義
- どう向き合い、設計品質を高めていけば良いのか
- 品質の指標、指標をコントロールする各種ツール
- 会社の事業成長とエンジニア自身のスキル成長について解説
第16章：設計を妨げる開発プロセスとの戦い
- 設計が上手く働かないのは、チームの設計スキルが未熟であること以外に、開発プロセスに問題があるケースが多い
- コミュニケーション
- 心理的要因
- 組織上の課題
- etc...
第17章：設計技術の理解の深め方
- 中上級者へのステップアップに有用な技術書の紹介
- 設計技術の効率的な学習方法
副教材
「staticおじさん」「巨大なデータクラス」「長大な関数」などのバグとか悪きコードが敵となって襲いかかってきて、それに対していろいろな設計スキルで倒していくゲームです
こちらのゲームがあって、本書が誕生したという裏話もあるようです→詳細は最初の資料参照
※2023/06/28でサービスが終了→上のリンクでは遊べなくなるかも？
エンジニアリングの当たり前を変える
技術的負債による損失は国家規模
我々は対処していかなければならない
- 2025年以降 技術的負債による経済損失 毎年12兆円以上
- 2021年度 国家予算 142.5兆円
2022年現在 必須スキル
- Linux
- GitHub
- Docker
- AWS ←近年はこの辺も推奨スキルになりつつある
- 変更用意性を考慮した設計スキル ←むしろこれを当たり前にすべきでは？
高みを目指す人はアーキテクトを目指してほしい
本書はアーキテクトの中でも「アプリケーションアーキテクト」の道に通じている
設計が当たり前の世界になるには？
変更容易性すら認知されているか疑問
マーケットシェア理論：市場にとって影響を無視できないシェア率→10.9%
国内のプログラマーの人口は約92万人
約10万人に変更容易性が認知されれば良い→みんなで広めよう！
ここからは感想的な何かです
なんというか、このへんのキーワードで検索すると出てくる話を思い出した
こんなやつ
こちらのコメント欄とか見てると現場の雰囲気が想像できる
著者もこんな記事を書いている
ちなみに自分が今まで出会った中で一番酷かったのはこれ
#define ZERO 1
昔でいう「Cプログラミング診断室」（初版が1993年!）とか思い出してしまった
↓現在は改訂新版が売られていますが、初版の内容が全文読めます
Discussion