乱雑なコードの整理から学ぶ設計の初歩

JJUG CCC 2025 Fall 発表資料

1. 良い設計とはなにか
2. 設計スキルを身に付けるコツ
3. 乱雑なコードを整理する実践技法
- 小さな設計改善
- 大きな設計改善
- 戦略的な設計改善

Transcript

1. 乱雑なコードの整理から学ぶ 設計の初歩 2025年11月15日 有限会社システム設計 増田 亨 #jjug_ccc 2025 Fall
2. 自己紹介 専門領域 • 業務系アプリケーションの開発 最近の仕事 • 大きな泥団子退治のお手伝い • エンジニアの設計スキル向上のお手伝い 2 増田 亨（masuda220） 著書(2017) 訳書(2024) ＊１ ＊2 *1 増田 亨(2017) 『現場で役立つシステム設計の原則』技術評論社 *2 Vlad Khononov(著) 増田 亨、綿引 琢磨(訳) 2024 『ドメイン駆動設計をはじめよう』オライリージャパン
3. お話する内容 ① 良い設計とはなにか ② 設計スキルを身に付けるコツ ③ 乱雑なコードを整理する実践技法 ✓ 小さな設計改善 ✓ 大きな設計改善 ✓ 戦略的な設計改善 3
4. ①良い設計とはなにか 4
5. 設計とは何か？ ある目的のために、 何もないところに形を与え、 その形を変え続ける活動 5
6. ソフトウェア設計の本質 良い設計は悪い設計よりも変更しやすい 6 『達人プログラマー ―熟達に向けたあなたの旅』第２版 Andrew Hunt(著)David Thomas(著)村上雅章(訳) 2020年 発行：オーム社 セクション８ Tips14
7. より実践的なソフトウェア設計の本質 整理整頓されたコードは 乱雑なコードよりも 変更が楽で安全になる 7
8. 良い設計と悪い設計の違い 8 良い設計 変更が楽で安全 整理整頓されたコード 悪い設計 変更が厄介で危険 乱雑なコード
9. 良い設計（整理整頓されたコード）の効果 • 変更する時、どこに何が書いてあるか見つけやすい • 何かを確認するために読む範囲が狭い • 意図が理解しやすい／誤解や見落としが少ない • 変更箇所が少ない（重複が少ない） • 変更が影響する範囲を推測しやすい • 変更が影響する範囲が狭い • 変更結果を確認するテスト量が少ない 9
10. 良い設計（整理整頓されたコード）の効果 • 変更する時、どこに何が書いてあるか見つけやすい • 何かを確認するために読む範囲が狭い • 意図が理解しやすい／誤解や見落としが少ない • 変更箇所が少ない（重複が少ない） • 変更が影響する範囲を推測しやすい • 変更が影響する範囲が狭い • 変更結果を確認するテスト量が少ない 10 乱雑なコードは この裏返しになる
11. ②設計スキルを身に付けるコツ 11
12. 設計スキルの向上 三原則 1. 整理整頓のやり方を、目・手・鼻を使って体で覚える いやな臭いを嗅ぎつけ、IDEのリファクタリング機能ショートカット が無意識に発動できるまで使い込む 2. 機能の修正や機能の追加の対象となっている、 現実の乱雑なコードで、小さな整理整頓を積み重ねる 3. 乱雑なコードのパターン、整理整頓されたコードのパ ターン、変更が楽で安全になるパターンを体で覚える 12
13. 実践的な設計改善アプローチ ✓ 変更が必要になった時、必要な範囲の乱雑なコードを 整理整頓する ✓ コードを整理整頓してから、機能の修正追加を行う ✓ 乱雑なコードを整理整頓した効果を体験する 13
14. 注意！ これから紹介する技法や参考図書に書いてあることを知 識として覚えても、設計スキルは向上しません サンプルコードや他人が書いたコードを見ても、それだ けで設計スキルは向上しません それらを参考に、実際のコードで、自分の手を動かして、 整理整頓の実験を続けることで設計スキルが向上します 14
15. 注意！ソフトウェア設計アンチパターン ⚫ 初期の設計（情報不足の設計）に時間をかける ⚫ 乱雑なコードの整理整頓と機能の変更を混同する ⚫ 乱雑なコードの整理整頓をしないで機能を変更する ⚫ 機能の変更をしない個所を整理整頓する ⚫ 変更を楽で安全にという目的を忘れた整理整頓をする 15
16. ③乱雑なコードを整理整頓する実践技法 16
17. 乱雑なコードを見つける ⚫ 乱雑なメソッドを見つける ⚫ 乱雑なクラスを見つける ⚫ 乱雑なパッケージを見つける 17
18. 乱雑なメソッドの特徴 • メソッドが長い • 式や文の演算子が多い • ネストが深い（forの中のswitchの中のif文） • nullを [ 受け取る｜返す｜渡す ] • メソッド名、引数名、変数名が怪しい 18
19. 乱雑なクラス • クラスが大きい • フィールド変数が多い • import文が多い • メソッドが多い • コメントが多い • クラス名が怪しい 19
20. 乱雑なパッケージ • クラスが多い • publicなクラスが複数ある • サブパッケージが多い • パッケージ階層が深い • パッケージ名が怪しい 20
21. 設計改善（コードの整理整頓）三つのレベル ➢ 小さな設計改善 ➢ 大きな設計改善 ➢ 戦略的な設計改善 • 三つの整理整頓を並行して進める（段階論ではない） • 下に行くほど、効果がはっきりするのに時間がかかる • 下に行くほど、良い設計か悪い設計か判断が難しい 21
22. 小さな設計改善 初級レベル ① 不要なコードを削除する（ノイズを減らす） • コメントアウトされたコード • 使われていない（であろう）コード • 余計なコメント、間違っている（であろう）コメント ② チャンキング（異なる関心事の境界を見つける） • 改行を使って、式や文を複数行に分ける • 改行を使って、多数のフィールド変数や多数の文をグループ分けする ③ グループ分けした単位に名前を付ける • 説明用変数を使う（ 例：boolean isValid = 数量 > 0 ) • メソッドに抽出する ( 例 boolean isValid() {return 数量 > 0;} 22
23. 小さな設計改善 中級レベル 強く関連するロジックとデータを一つのクラスに集め、クラス名と メソッド名で意図を説明する ① 算術演算/比較演算/論理演算のカプセル化 プリミティブなデータ型とそれを使った演算を一つのクラスに集める ② コレクション操作のカプセル化 コレクション型のデータとそのループ処理を一つのクラスに集める ③ 条件分岐のカプセル化 条件ごとの定数やロジックをenumクラスに集めて整理する 23 →値オブジェクト →コレクションオブジェクト →区分オブジェクト
24. 小さな設計改善の参考図書 24 第１部 整頓 第Ⅱ部 管理術 第3章 コードの不吉な臭い ４章～１０章 第1章 ちいさくまとめてわかりやすく 第2章 場合分けのロジックを整理する
25. 大きな設計改善（小さな改善を積み重ねる方向） ① 入力・計算判断・出力の三つの関心事を クラスとパッケージを使って切り離す a. 入力のデータ構造に影響された計算判断クラスを作らない b. 出力のデータ構造に影響された計算判断クラスを作らない c. 入力クラス、出力クラスに計算判断ロジックを持ち込まない ② アプリケーション特化のデータ型（値オブジェクト、 コレクションオブジェクト、区分オブジェクト）を 使って業務ロジックを記述する 業務ロジックを記述するクラスでは、プリミティブなデータ型(int, String, LocalDate, … )を使わわない 25
26. 大きな設計改善の参考図書 26 第3章 業務ロジックをわかりやすく整理 第4章 ドメインモデルの考え方で設計する 第12章 大きなリファクタリング
27. 戦略的な設計改善（戦略的なコード整理） ✓ 事業戦略とソフトウェアの実装を結びつける ✓ 差別化戦略に適合するように、ソフトウェアの設計方 針と開発の優先順位を決定する ✓ 差別化への影響が少ない個所はできるだけ簡略に済ま せる 27
28. 事業を理解して設計判断する 設計（コードの整理整頓）に使える時間は限られている ソフトウェアシステム全体の、どこを、いつ、どのよう に整理整頓するか？ 事業を理解して、費用対効果の高い個所を特定し、整理 整頓の優先順位と実施タイミングを判断する 28
29. 戦略的な設計改善の参考図書 29 【エッセンシャル版】
30. 差別化戦略と設計判断を整合させる 30 競合他社との差別化 中核の 業務領域 業務ロジック の複雑さ 優先的に 取り組む 簡略に済ませる 模倣、流用、購入 他社と同じ 自社独自 一般 一般または 補完 補完
31. まとめ ✓ 良い設計は悪い設計より変更しやすい ✓ 乱雑なコードを整理整頓して変更を楽で安全にする ✓ 機能を変えようとしているコードを対象に、手を動かし て整理整頓のやり方と効果を体で覚える ✓ 小さな設計改善、大きな設計改善、戦略的な設計改善を 並行して進める 31
32. コミュニティに能動的に参加しよう！ ✓ 参加した感想を アンケートで フードバックしよう ✓ 参加体験記を書いてみよう ✓ 次回はCfPを出してみよう ✓ 次回はスタッフに応募してみよう 32 セッション 全体