ID | 大項目 中項目 |
小項目(課題要素) | 必要となる知識と行動 | できるという状態 | 技術補足(言語・FWなど) |
---|---|---|---|---|---|
201 | オブジェクト指向とアーキテクチャ クラスとインスタンスの概念 |
1. クラスとインスタンスの違いを明確に説明できる | クラスとインスタンスの違い、オブジェクト指向の基本概念(抽象設計と具象生成)を理解する。 | クラス定義とインスタンス生成を正しく使い分け、コードと図で説明できる。 | |
202 | オブジェクト指向とアーキテクチャ クラスとインスタンスの概念 |
2. オブジェクトの状態と振る舞いを設計できる | オブジェクトが持つ属性(状態)とメソッド(振る舞い)を整理し、設計に反映できる。 | データ構造と動作を意図的に設計し、変更にも耐えられるクラスを実装できる。 | |
203 | オブジェクト指向とアーキテクチャ クラスとインスタンスの概念 |
3. コンストラクタの役割と適切な使い方を理解できる | コンストラクタの役割・初期化タイミング・依存注入を理解する。 | クラス初期化時に必要な値や依存を的確に設定できる。 | |
204 | オブジェクト指向とアーキテクチャ クラスとインスタンスの概念 |
4. インスタンス化のタイミングと影響を把握している | オブジェクト生成コストやライフサイクルを意識し、タイミングを設計する。 | 必要な時にのみインスタンス化し、不要時に破棄またはスコープを制御できる。 | |
205 | オブジェクト指向とアーキテクチャ クラスとインスタンスの概念 |
5. オブジェクトの属性と責任を意識した設計ができる | オブジェクトの責務を整理し、プロパティとメソッドの関連を意識する。 | 役割に基づいた責任を持つオブジェクト設計を行える。 | |
206 | オブジェクト指向とアーキテクチャ クラスとインスタンスの概念 |
6. クラス間の関係(has-a/is-a)を使い分けられる | 「has-a」「is-a」などの関係性を理解し、継承・コンポジションを判断できる。 | 関係性に基づいて適切なオブジェクト間設計を行える。 | |
207 | オブジェクト指向とアーキテクチャ クラスとインスタンスの概念 |
7. new演算子や依存注入の使いどころを判断できる | 依存注入(DI)やnew演算子による生成の違いを理解する。 | 依存を注入して柔軟なオブジェクト生成を設計できる。 | |
208 | オブジェクト指向とアーキテクチャ クラスとインスタンスの概念 |
8. クラス設計に冗長さや重複がないようにできる | 重複コードを排除し、抽象化によって再利用性を高める。 | 重複や責務の混在を避けたスリムなクラス構成を実現できる。 | |
209 | オブジェクト指向とアーキテクチャ クラスとインスタンスの概念 |
9. オブジェクトの責任範囲を明確にできる | 各オブジェクトの責任を明確に分離して設計する。 | 依存や役割の境界が明確なオブジェクト設計を説明できる。 | |
210 | オブジェクト指向とアーキテクチャ クラスとインスタンスの概念 |
10. クラスと手続きの違いを実例で説明できる | 手続き的設計とオブジェクト指向設計の違いを理解する。 | 手続き型との比較を通じてクラス設計の利点を説明できる。 | |
211 | オブジェクト指向とアーキテクチャ 継承・ポリモーフィズム |
11. 継承を使ってコードの再利用ができる | 継承によるコード再利用と抽象化の仕組みを理解する。 | 基底クラスを継承して共通処理を実装できる。 | |
212 | オブジェクト指向とアーキテクチャ 継承・ポリモーフィズム |
12. 基底クラスと派生クラスの役割を明確に設計できる | 基底クラスと派生クラスの責任分担を設計できる。 | 継承階層の設計意図を他者に説明できる。 | |
213 | オブジェクト指向とアーキテクチャ 継承・ポリモーフィズム |
13. override/super/parent の動作を理解できる | override/super/parentキーワードの動作を理解する。 | 継承元のメソッドを適切に再利用・上書きできる。 | |
214 | オブジェクト指向とアーキテクチャ 継承・ポリモーフィズム |
14. 継承による依存関係のリスクを理解している | 継承による依存関係や変更影響範囲を理解する。 | 過度な継承を避け、依存を適切に管理できる。 | |
215 | オブジェクト指向とアーキテクチャ 継承・ポリモーフィズム |
15. インターフェース/抽象クラスの違いを説明できる | インターフェースと抽象クラスの違いを理解する。 | 共通仕様定義をインターフェースで、共通処理を抽象クラスで設計できる。 | |
216 | オブジェクト指向とアーキテクチャ 継承・ポリモーフィズム |
16. 共通処理を基底クラスにまとめられる | 共通処理を抽象化して基底クラスにまとめる方法を理解する。 | 重複を基底クラスに整理し、DRY原則を守れる。 | |
217 | オブジェクト指向とアーキテクチャ 継承・ポリモーフィズム |
17. 過剰な継承による複雑化を避けられる | 継承による階層の肥大化や密結合リスクを理解する。 | 継承より委譲を選択する判断ができる。 | |
218 | オブジェクト指向とアーキテクチャ 継承・ポリモーフィズム |
18. 多態性(ポリモーフィズム)を使い分けられる | 多態性(ポリモーフィズム)を理解し、条件分岐の削減に活かす。 | ポリモーフィズムで柔軟な拡張を行える。 | |
219 | オブジェクト指向とアーキテクチャ 継承・ポリモーフィズム |
19. 継承ではなく委譲を選択する判断ができる | 委譲(delegation)と継承の違いを理解する。 | 必要に応じて委譲で責務分散を実現できる。 | |
220 | オブジェクト指向とアーキテクチャ 継承・ポリモーフィズム |
20. is-a/can-do関係の設計ミスを避けられる | is-a/can-do 関係の設計誤り例を理解する。 | 関係性を正しく区別して設計できる。 | |
221 | オブジェクト指向とアーキテクチャ カプセル化と情報隠蔽 |
21. カプセル化とは何かを説明できる | カプセル化の目的と効果を理解する。 | 外部から内部構造を守る設計を説明できる。 | |
222 | オブジェクト指向とアーキテクチャ カプセル化と情報隠蔽 |
22. アクセス修飾子(private, protected, public)の意味を使い分けられる | アクセス修飾子の意味と適切な利用を理解する。 | private/protected/publicを正しく使い分けられる。 | |
223 | オブジェクト指向とアーキテクチャ カプセル化と情報隠蔽 |
23. 不要な外部公開を避けた安全なクラス設計ができる | 外部公開を最小化する設計思想を理解する。 | 安全で意図の明確なクラス設計を実現できる。 | |
224 | オブジェクト指向とアーキテクチャ カプセル化と情報隠蔽 |
24. データと処理を1つのまとまりとして封装できる | データと処理を1つのまとまりに封装する概念を理解する。 | オブジェクト内に状態と動作を統合できる。 | |
225 | オブジェクト指向とアーキテクチャ カプセル化と情報隠蔽 |
25. setter/getter の適切な使い方を理解している | getter/setterの役割と副作用の注意点を理解する。 | 必要な場合のみ安全にアクセサを設計できる。 | |
226 | オブジェクト指向とアーキテクチャ カプセル化と情報隠蔽 |
26. 内部状態を隠蔽する設計ができる | 内部状態を隠蔽し、外部公開を制限する設計原則を理解する。 | 内部変更が外部に影響しない構造を作れる。 | |
227 | オブジェクト指向とアーキテクチャ カプセル化と情報隠蔽 |
27. メンバ変数の変更範囲を制御できる | メンバ変数の変更を追跡・制御する仕組みを理解する。 | データの一貫性を保ちながら安全に更新できる。 | |
228 | オブジェクト指向とアーキテクチャ カプセル化と情報隠蔽 |
28. APIの公開インターフェースを最小に保てる | API公開設計の最小化原則を理解する。 | 不要な公開を避け、責務範囲を明確にしたAPI設計ができる。 | |
229 | オブジェクト指向とアーキテクチャ カプセル化と情報隠蔽 |
29. カプセル化によってテストしやすくできる | カプセル化がテスト容易性を高める理由を理解する。 | ユニットテストで外部依存を最小化できる設計ができる。 | |
230 | オブジェクト指向とアーキテクチャ カプセル化と情報隠蔽 |
30. 内部構造の変更が外部影響を与えない設計ができる | 内部構造変更と外部影響の関係を理解する。 | 変更に強い安定したクラス設計を実現できる。 | |
231 | オブジェクト指向とアーキテクチャ 責務分離と凝集度/結合度 |
31. 単一責任の原則(SRP)を意識したクラス設計ができる | 単一責任の原則(SRP)の意味と目的を理解する。 | 1クラス1責任を守った設計を説明し実装できる。 | |
232 | オブジェクト指向とアーキテクチャ 責務分離と凝集度/結合度 |
32. クラス同士の結合度を下げる工夫ができる | クラス間の結合度を下げる工夫(依存逆転など)を理解する。 | 疎結合なクラス設計を実践できる。 | |
233 | オブジェクト指向とアーキテクチャ 責務分離と凝集度/結合度 |
33. 再利用性と保守性を両立するための粒度を判断できる | 再利用性と保守性のバランスを取る粒度を理解する。 | 適切な抽象度で再利用性の高い構造を作れる。 | |
234 | オブジェクト指向とアーキテクチャ 責務分離と凝集度/結合度 |
34. 凝集度の高いクラスを設計できる | 凝集度(高い方が良い)とその判断基準を理解する。 | 高凝集なモジュールを設計し、意図を説明できる。 | |
235 | オブジェクト指向とアーキテクチャ 責務分離と凝集度/結合度 |
35. クラスの責任分離をパッケージ設計に反映できる | パッケージ設計に責務分離を反映する方法を理解する。 | 業務単位ごとに責任が整理されたパッケージ構造を作成できる。 | |
236 | オブジェクト指向とアーキテクチャ 責務分離と凝集度/結合度 |
36. クラスのサイズが肥大化していたら分割できる | クラス肥大化の兆候と分割手法を理解する。 | 肥大クラスを責務単位で分割し整理できる。 | |
237 | オブジェクト指向とアーキテクチャ 責務分離と凝集度/結合度 |
37. 役割の似ているメソッドはまとめられる | 類似メソッドや冗長コードをまとめる方法を理解する。 | 共通化でクリーンなクラスを保てる。 | |
238 | オブジェクト指向とアーキテクチャ 責務分離と凝集度/結合度 |
38. クラスの責務をチームで共有・レビューできる | クラス責務の共有・レビュー手法を理解する。 | チームレビューで設計意図を共有できる。 | |
239 | オブジェクト指向とアーキテクチャ 責務分離と凝集度/結合度 |
39. 結合度と凝集度のバランスを取った設計ができる | 結合度と凝集度のトレードオフを理解する。 | 両者のバランスを取った設計を選択できる。 | |
240 | オブジェクト指向とアーキテクチャ オブジェクト同士の協調と依存 |
40. ユーザーにとって直感的なクラス設計ができる | ユーザー視点の直感的なAPI設計を意識する。 | 理解しやすく誤用されにくいクラス設計ができる。 | |
241 | オブジェクト指向とアーキテクチャ オブジェクト同士の協調と依存 |
41. Factory/Strategyなど代表的なパターンを説明できる | Factory, Strategyなど主要なパターンを理解する。 | 目的に応じて適切なパターンを選択し実装できる。 | |
242 | オブジェクト指向とアーキテクチャ オブジェクト同士の協調と依存 |
42. 目的に応じて適切なデザインパターンを選択できる | 用途と目的に応じたデザインパターンの選択基準を理解する。 | 必要な場面で適切なパターンを使い分けられる。 | |
243 | オブジェクト指向とアーキテクチャ オブジェクト同士の協調と依存 |
43. シングルトン/デコレータ/オブザーバの特徴を理解できる | Singleton, Decorator, Observer等の仕組みを理解する。 | 代表的なパターンを実装・説明できる。 | |
244 | オブジェクト指向とアーキテクチャ オブジェクト同士の協調と依存 |
44. パターンの使いすぎ・過剰設計を回避できる | 過剰設計・パターン乱用の弊害を理解する。 | 簡潔で意図が明確なパターン適用を選択できる。 | |
245 | オブジェクト指向とアーキテクチャ オブジェクト同士の協調と依存 |
45. コードの可読性を保ったうえでパターンを導入できる | 可読性を重視したパターン実装の方法を理解する。 | チーム全員が理解できる形でパターンを適用できる。 | |
246 | オブジェクト指向とアーキテクチャ オブジェクト同士の協調と依存 |
46. GoFパターンの代表例を具体例で説明できる | GoFパターンの代表例を学び構造を理解する。 | 代表パターンを設計図として再現できる。 | |
247 | オブジェクト指向とアーキテクチャ オブジェクト同士の協調と依存 |
47. パターンが導入されたコードを読んで理解できる | パターン適用済みコードの読み解き方を理解する。 | 既存のパターン導入コードを読解できる。 | |
248 | オブジェクト指向とアーキテクチャ オブジェクト同士の協調と依存 |
48. 自作の設計にもパターンを応用できる | 自分の設計に既存パターンを応用する発想を持つ。 | 状況に応じてパターンを柔軟に再構成できる。 | |
249 | オブジェクト指向とアーキテクチャ オブジェクト同士の協調と依存 |
49. 状態管理や拡張性の課題にパターンで対処できる | 状態管理や拡張性問題をパターンで解決する手法を理解する。 | 課題に応じて適切な構造改善を行える。 | |
250 | オブジェクト指向とアーキテクチャ オブジェクト同士の協調と依存 |
50. パターンを使ったときのメリット・デメリットを説明できる | パターン導入の利点・欠点を分析できる。 | 適用判断を根拠付きで説明できる。 | |
251 | オブジェクト指向とアーキテクチャ デザインパターン基礎(Factory/Strategyなど) |
51. MVCの役割(Model/View/Controller)を正しく分離できる | MVCの構成要素(Model, View, Controller)の責任を理解する。 | 各層を明確に分離した設計を構築できる。 | |
252 | オブジェクト指向とアーキテクチャ デザインパターン基礎(Factory/Strategyなど) |
52. MVCの構造に適したコードを設計できる | MVCパターンに適した設計ルールを理解する。 | 責務ごとに整理されたコード構造を設計できる。 | |
253 | オブジェクト指向とアーキテクチャ デザインパターン基礎(Factory/Strategyなど) |
53. Controllerの責任を最小限に抑えることができる | Controller肥大化を防ぐ手法を理解する。 | Controllerを薄く保ち、ビジネスロジックを分離できる。 | |
254 | オブジェクト指向とアーキテクチャ デザインパターン基礎(Factory/Strategyなど) |
54. Viewにロジックを埋め込まない構成ができる | Viewにロジックを持たせない原則を理解する。 | テンプレートをロジックレスで維持できる。 | |
255 | オブジェクト指向とアーキテクチャ デザインパターン基礎(Factory/Strategyなど) |
55. Modelにビジネスロジックを集約できる | Model層の役割と責務集約の意義を理解する。 | 業務ロジックをModelに集約できる。 | |
256 | オブジェクト指向とアーキテクチャ デザインパターン基礎(Factory/Strategyなど) |
56. LaravelやRailsなどのMVCフレームワークに対応できる | LaravelやRailsのMVC構造を理解する。 | 主要フレームワークでMVC実践ができる。 | |
257 | オブジェクト指向とアーキテクチャ デザインパターン基礎(Factory/Strategyなど) |
57. フロントエンドとの分離を意識した設計ができる | フロントエンド分離の設計思想を理解する。 | API駆動でUI層を独立させられる。 | |
258 | オブジェクト指向とアーキテクチャ デザインパターン基礎(Factory/Strategyなど) |
58. MVCの構造が崩れたコードをリファクタできる | 崩れたMVC構造を再設計する方法を理解する。 | 役割分担を整理しリファクタリングできる。 | |
259 | オブジェクト指向とアーキテクチャ デザインパターン基礎(Factory/Strategyなど) |
59. SPAとの共存(API連携)を見越した設計ができる | SPA構成とAPI連携の仕組みを理解する。 | フロントとバックの分離設計を実現できる。 | |
260 | オブジェクト指向とアーキテクチャ デザインパターン基礎(Factory/Strategyなど) |
60. MVC以外の構造との違いを説明できる | MVC以外のアーキテクチャ(MVVM等)の違いを理解する。 | 状況に応じた構成選択を説明できる。 | |
261 | オブジェクト指向とアーキテクチャ MVCモデルの理解と実装 |
61. ドメイン駆動設計(DDD)の基本用語を説明できる | DDD(ドメイン駆動設計)の基本用語と考え方を理解する。 | DDDの主要構成要素を説明できる。 | |
262 | オブジェクト指向とアーキテクチャ MVCモデルの理解と実装 |
62. エンティティと値オブジェクトの違いを理解している | エンティティと値オブジェクトの違いを理解する。 | 識別子を持つ/持たないオブジェクトを適切に設計できる。 | |
263 | オブジェクト指向とアーキテクチャ MVCモデルの理解と実装 |
63. 集約/リポジトリ/サービスの構成を設計できる | 集約、リポジトリ、サービスの構造を理解する。 | DDD構成をコードへ落とし込める。 | |
264 | オブジェクト指向とアーキテクチャ MVCモデルの理解と実装 |
64. ドメインモデルにビジネスルールを集中させられる | ビジネスルールをドメイン層に集中させる意義を理解する。 | 業務知識をコード構造に反映できる。 | |
265 | オブジェクト指向とアーキテクチャ MVCモデルの理解と実装 |
65. アプリケーション層とドメイン層を分離できる | アプリケーション層とドメイン層の分離の意味を理解する。 | 責任境界を保ち設計を分離できる。 | |
266 | オブジェクト指向とアーキテクチャ MVCモデルの理解と実装 |
66. DDDの層構造をコードに落とし込める | DDDのレイヤー構造を理解し実装へ落とせる。 | DDDをプロジェクト構成として反映できる。 | |
267 | オブジェクト指向とアーキテクチャ MVCモデルの理解と実装 |
67. ドメインイベントやユビキタス言語の意味を説明できる | ドメインイベントとユビキタス言語を理解する。 | チーム共通言語でモデル化ができる。 | |
268 | オブジェクト指向とアーキテクチャ MVCモデルの理解と実装 |
68. データ構造よりも意味に基づく設計ができる | データ構造ではなく意味構造で設計する考え方を理解する。 | 実装を意味中心のモデルとして表現できる。 | |
269 | オブジェクト指向とアーキテクチャ MVCモデルの理解と実装 |
69. DDD導入が有効なケースとそうでないケースを区別できる | DDD導入が有効なケース・不要なケースを理解する。 | 状況に応じてDDD適用判断ができる。 | |
270 | オブジェクト指向とアーキテクチャ MVCモデルの理解と実装 |
70. 初学者向けにDDDの価値を説明できる | DDDの価値と意義を初学者に説明する力を持つ。 | DDDの考え方を伝えられる。 | |
271 | オブジェクト指向とアーキテクチャ DDD(ドメイン駆動設計)の入り口 |
71. プレゼンテーション/ドメイン/インフラの3層分離を説明できる | 三層構造(プレゼンテーション・ドメイン・インフラ)の責任を理解する。 | 各層の責任を整理した構成を設計できる。 | |
272 | オブジェクト指向とアーキテクチャ DDD(ドメイン駆動設計)の入り口 |
72. 各層の責任と依存関係を整理して設計できる | 層間依存と責務分離の考え方を理解する。 | 依存を明確に制御できる構造を作れる。 | |
273 | オブジェクト指向とアーキテクチャ DDD(ドメイン駆動設計)の入り口 |
73. コードの依存方向を一方通行に保てる | コード依存方向の一方向性の重要性を理解する。 | 依存逆転原則を守った構成を維持できる。 | |
274 | オブジェクト指向とアーキテクチャ DDD(ドメイン駆動設計)の入り口 |
74. インフラの実装を差し替え可能な構造にできる | インフラ層の差し替え設計を理解する。 | 実装交換可能なアーキテクチャを構築できる。 | |
275 | オブジェクト指向とアーキテクチャ DDD(ドメイン駆動設計)の入り口 |
75. ドメイン層から外部依存を排除できる | ドメイン層から外部依存を排除する理由を理解する。 | ビジネスロジックを純粋に保てる設計を行える。 | |
276 | オブジェクト指向とアーキテクチャ DDD(ドメイン駆動設計)の入り口 |
76. サービス層を使って処理の中核を明確に分離できる | サービス層の役割を理解し責務分割を行える。 | 複数ユースケースを共通サービス化できる。 | |
277 | オブジェクト指向とアーキテクチャ DDD(ドメイン駆動設計)の入り口 |
77. ポート/アダプタ構造を意識した設計ができる | ポート/アダプタ構造を理解する。 | ヘキサゴナルアーキテクチャを実践できる。 | |
278 | オブジェクト指向とアーキテクチャ DDD(ドメイン駆動設計)の入り口 |
78. ユースケースに沿った構造設計ができる | ユースケース駆動設計の手法を理解する。 | ユースケース単位で構造を整理できる。 | |
279 | オブジェクト指向とアーキテクチャ DDD(ドメイン駆動設計)の入り口 |
79. フレームワーク非依存の設計ができる | フレームワーク依存を減らす設計方針を理解する。 | 環境変更に強いコードを作れる。 | |
280 | オブジェクト指向とアーキテクチャ アーキテクチャ層の分離(Presentation/Domain/Infraなど) |
80. 層ごとの責任が明確なプロジェクト構成を作成できる | 層ごとの責任を明確にした構成設計を理解する。 | 構造の一貫性を保ったプロジェクトを構築できる。 | |
281 | オブジェクト指向とアーキテクチャ アーキテクチャ層の分離(Presentation/Domain/Infraなど) |
81. アンチパターン(God Object/Lava Flowなど)を識別できる | 代表的アンチパターンを学び、回避方法を理解する。 | コードの悪臭を識別し改善できる。 | |
282 | オブジェクト指向とアーキテクチャ アーキテクチャ層の分離(Presentation/Domain/Infraなど) |
82. スパゲッティコード化の兆候を見抜ける | スパゲッティ化の原因と兆候を理解する。 | 可読性低下の前に構造を改善できる。 | |
283 | オブジェクト指向とアーキテクチャ アーキテクチャ層の分離(Presentation/Domain/Infraなど) |
83. 無意味な抽象化・過剰な継承を避けられる | 無意味な抽象化や過剰継承の弊害を理解する。 | 不要な抽象を排除してシンプルに設計できる。 | |
284 | オブジェクト指向とアーキテクチャ アーキテクチャ層の分離(Presentation/Domain/Infraなど) |
84. 共通処理の乱用による複雑化を回避できる | 共通化乱用による複雑化を理解する。 | 再利用よりも明確さを優先できる。 | |
285 | オブジェクト指向とアーキテクチャ アーキテクチャ層の分離(Presentation/Domain/Infraなど) |
85. 業務ロジックがUIやデータアクセスに混在していたら分離できる | UIと業務ロジックの混在を避ける意義を理解する。 | 関心分離を徹底し整理できる。 | |
286 | オブジェクト指向とアーキテクチャ アーキテクチャ層の分離(Presentation/Domain/Infraなど) |
86. 名前や配置の曖昧さが生む設計ミスを回避できる | 命名や配置の重要性を理解する。 | 明確な命名と階層で構造を最適化できる。 | |
287 | オブジェクト指向とアーキテクチャ アーキテクチャ層の分離(Presentation/Domain/Infraなど) |
87. 複雑なif文やswitch文の整理方法を持っている | 条件分岐の整理・抽象化手法を理解する。 | 複雑なif/switchを簡潔に書き換えられる。 | |
288 | オブジェクト指向とアーキテクチャ アーキテクチャ層の分離(Presentation/Domain/Infraなど) |
88. ライブラリ依存・DB依存が強すぎる設計に警鐘を鳴らせる | 外部依存・ライブラリ依存のリスクを理解する。 | 依存を明確に分離し管理できる。 | |
289 | オブジェクト指向とアーキテクチャ アーキテクチャ層の分離(Presentation/Domain/Infraなど) |
89. 見通しの悪い構成をリファクタリングできる | 見通しの悪い構成のリファクタリング手法を理解する。 | 保守しやすい構造へ変換できる。 | |
290 | オブジェクト指向とアーキテクチャ アーキテクチャ層の分離(Presentation/Domain/Infraなど) |
90. チームにとって保守しやすいコードへ変換できる | 保守性を意識したコード改善方法を理解する。 | チーム全体が理解できる保守性の高いコードへ改善できる。 | |
291 | オブジェクト指向とアーキテクチャ アンチパターンとリファクタリング |
91. リファクタリングの目的とタイミングを理解している | リファクタリングの目的・タイミングを理解する。 | 品質を維持しながら安全に構造改善できる。 | |
292 | オブジェクト指向とアーキテクチャ アンチパターンとリファクタリング |
92. メソッド抽出・クラス分割の基本手法を使いこなせる | メソッド抽出・クラス分割の基本技法を理解する。 | 重複を削減し責務単位で整理できる。 | |
293 | オブジェクト指向とアーキテクチャ アンチパターンとリファクタリング |
93. リグレッションを起こさずに構造改善ができる | リグレッション防止策とテスト連携を理解する。 | 影響を最小限に抑えた変更を行える。 | |
294 | オブジェクト指向とアーキテクチャ アンチパターンとリファクタリング |
94. コードの可読性を重視した変更ができる | 可読性向上を意識した変更の重要性を理解する。 | 他者が読みやすいリファクタリングを実践できる。 | |
295 | オブジェクト指向とアーキテクチャ アンチパターンとリファクタリング |
95. 小さな単位で安全に変更を進める習慣がある | 小さな変更単位での改善サイクルを理解する。 | 安全に少しずつ構造を改善できる。 | |
296 | オブジェクト指向とアーキテクチャ アンチパターンとリファクタリング |
96. ユニットテストと連携したリファクタリングができる | テスト駆動リファクタリングの重要性を理解する。 | ユニットテストを活用した構造改善ができる。 | |
297 | オブジェクト指向とアーキテクチャ アンチパターンとリファクタリング |
97. 構造と責任を明確にするための整理力を持つ | 構造・責任整理のための分析手法を理解する。 | 整理と責務明確化を繰り返し行える。 | |
298 | オブジェクト指向とアーキテクチャ アンチパターンとリファクタリング |
98. 設計図との乖離を解消するための改善を行える | 設計図と実装の乖離を見つける方法を理解する。 | 乖離を検出し設計へ再統合できる。 | |
299 | オブジェクト指向とアーキテクチャ アンチパターンとリファクタリング |
99. 外部仕様に影響を与えずに内部構造を改良できる | 外部仕様を保ったまま内部改良を行う方法を理解する。 | 影響を与えずに内部品質を改善できる。 | |
300 | オブジェクト指向とアーキテクチャ アンチパターンとリファクタリング |
100. 設計改善を継続的に行うマインドを持っている | 継続的な設計改善文化の価値を理解する。 | 定期的にコードを整理し改善を習慣化できる。 |