ID | 大項目 中項目 |
小項目(課題要素) | 必要となる知識と行動 | できるという状態 | 技術補足(言語・FWなど) |
---|---|---|---|---|---|
101 | 構造と設計 処理の分割と関数化 |
1. 複数の処理を関数に切り出して整理できる | 関数の役割と構造を理解し、処理を分割して整理するスキルを身につけている。 | 複雑な処理を関数に分けて見通しの良いコードにできる。 | |
102 | 構造と設計 処理の分割と関数化 |
2. 関数名に処理の意図を反映させて命名できる | 命名規則と可読性の関係を理解し、関数名に意図を込める訓練をしている。 | 関数名を見ただけで処理内容が理解できるコードを書ける。 | |
103 | 構造と設計 処理の分割と関数化 |
3. 1関数=1目的を意識して設計できる | 1つの関数は1つの目的を果たすという設計原則を理解している。 | 責務が明確で保守しやすい関数を設計できる。 | |
104 | 構造と設計 処理の分割と関数化 |
4. 関数の引数を必要最小限に設計できる | 引数の設計における依存関係と汎用性の考慮を理解している。 | 必要最小限の引数で柔軟に使える関数を作成できる。 | |
105 | 構造と設計 処理の分割と関数化 |
5. 関数の戻り値が明確であるように設計できる | 戻り値の意味と活用を理解し、関数の出力設計を意識している。 | 戻り値が予測可能で再利用しやすい関数を設計できる。 | |
106 | 構造と設計 処理の分割と関数化 |
6. 同じ処理を複数回書かず、関数で共通化できる | 重複コードを減らし、関数による共通化の考え方を理解している。 | 共通処理を関数にまとめてコードの保守性を高められる。 | |
107 | 構造と設計 処理の分割と関数化 |
7. UIロジックと処理ロジックを分離できる | UI層とビジネスロジック層を分けて設計する考えを理解している。 | UI処理とロジックを分離した責務明確なコードを書ける。 | |
108 | 構造と設計 処理の分割と関数化 |
8. コードを読みやすく保つための関数化ができる | コード可読性を保つための関数分割の基準を理解している。 | 冗長な処理を整理し、読みやすい構造で維持できる。 | |
109 | 構造と設計 処理の分割と関数化 |
9. 他の関数からの再利用を前提に設計できる | 再利用を考慮した関数設計の原則を理解している。 | 他の関数やモジュールからも安全に呼び出せる関数を設計できる。 | |
110 | 構造と設計 処理の分割と関数化 |
10. 複数人開発でも理解されやすい関数構造を意識できる | チーム開発での関数共有やレビューの重要性を理解している。 | 他メンバーが理解しやすい構造と命名で関数を設計できる。 | |
111 | 構造と設計 単一責任原則(SRP) |
11. 関数やクラスの責任を1つに絞って設計できる | 単一責任原則(SRP)を理解し、関数やクラスを責務単位で設計する。 | 1つの関数やクラスが1つの責任だけを持つよう設計できる。 | |
112 | 構造と設計 単一責任原則(SRP) |
12. 「責任の定義」が曖昧な設計を見抜ける | 責任の定義が曖昧な構造がなぜ問題かを理解している。 | 曖昧な設計を見抜き、修正案を提示できる。 | |
113 | 構造と設計 単一責任原則(SRP) |
13. クラスや関数が肥大化していたら分割できる | 肥大化クラスや関数の兆候を理解し、分割基準を判断できる。 | 過剰な責務を持つ関数を適切に分割して整理できる。 | |
114 | 構造と設計 単一責任原則(SRP) |
14. データ処理と表示処理を分けて考えられる | ロジック層と表示層の責任を分ける概念を理解している。 | 表示ロジックと処理ロジックを別モジュールに分離できる。 | |
115 | 構造と設計 単一責任原則(SRP) |
15. ファイル操作とロジック処理を別関数に分けられる | 入出力処理とビジネスロジックの切り分けの重要性を理解する。 | ファイル操作と業務ロジックを分けた関数を設計できる。 | |
116 | 構造と設計 単一責任原則(SRP) |
16. 単一責任を保つことでバグ発生箇所が追いやすくなることを理解する | 責任を明確化することでバグ原因を局所化できる設計思想を理解する。 | 障害箇所を容易に特定できる構造を作れる。 | |
117 | 構造と設計 単一責任原則(SRP) |
17. 一部の変更が他の箇所に影響しないように設計できる | 依存関係を意識した設計変更の影響範囲の考え方を学ぶ。 | 他の機能に影響を与えないよう設計変更できる。 | |
118 | 構造と設計 単一責任原則(SRP) |
18. 「もし~の変更が入ったら」という想定で責任分離できる | 責任変更に強い構造設計の考え方を理解する。 | 要件変更に応じて柔軟にモジュール分離ができる。 | |
119 | 構造と設計 単一責任原則(SRP) |
19. 責任の異なるロジックを適切にディレクトリやファイルで分けられる | プロジェクト構造における責務分離の実践(MVC等)を理解する。 | 異なる責任を明確にディレクトリ構成に反映できる。 | |
120 | 構造と設計 単一責任原則(SRP) |
20. 他人の設計を見てSRPの観点で問題を指摘できる | SRP観点で他人の設計をレビューする練習を積んでいる。 | 他人のコードを見て責任過多な設計を指摘できる。 | |
121 | 構造と設計 データと処理の分離 |
21. データ構造と処理ロジックを別に設計できる | データ構造と処理ロジックを分離する設計原則を理解している。 | 構造体やDTOを使ってデータと処理を分けられる。 | |
122 | 構造と設計 データと処理の分離 |
22. 表示に使う変数を整形して渡すロジックを用意できる | 表示用データを整形して渡す役割分担を理解している。 | ViewModel的な考えでデータを整形してUIへ渡せる。 | |
123 | 構造と設計 データと処理の分離 |
23. 入力のバリデーションと実処理を明確に分離できる | 入力値検証(バリデーション)と実処理の分離を理解している。 | 入力検証を専用関数に分けて保守性を高められる。 | |
124 | 構造と設計 データと処理の分離 |
24. クラス設計でプロパティとメソッドの責任を整理できる | クラス内のプロパティとメソッドの責任分離を理解している。 | データ保持と動作実装を適切に設計できる。 | |
125 | 構造と設計 データと処理の分離 |
25. DBからの取得処理と画面出力処理を分離できる | データベースアクセス層と出力処理層の違いを理解している。 | DB処理と画面出力処理を別メソッド・別層に分けられる。 | |
126 | 構造と設計 データと処理の分離 |
26. データの受け渡し方法を意識した設計ができる(DTOなど) | DTO・VOなどデータ伝達の設計パターンを理解している。 | データ受け渡しを安全に管理できる設計を実装できる。 | |
127 | 構造と設計 データと処理の分離 |
27. JSONなどの中間形式でデータをやり取りできる構造にできる | JSONなどのデータ交換形式を理解し、適切に変換できる。 | APIやフロント連携で適切にデータを受け渡せる。 | |
128 | 構造と設計 データと処理の分離 |
28. 計算ロジックをテンプレートから分離できる | テンプレート内の計算ロジックを分離する設計を理解している。 | テンプレートをシンプルに保つための分離実装ができる。 | |
129 | 構造と設計 データと処理の分離 |
29. フォーム処理の前処理/後処理を構造的に分けられる | フォーム処理の前後処理の責務を明確に分ける概念を理解している。 | バリデーション・保存・通知などを構造的に分離できる。 | |
130 | 構造と設計 データと処理の分離 |
30. データ変換処理をユーティリティ関数として再利用できる | データ変換・整形のための共通関数を作る意義を理解している。 | 複数箇所で使えるデータ変換関数を実装できる。 | |
131 | 構造と設計 モジュール設計と粒度 |
31. モジュール(部品)の最小粒度を適切に設計できる | モジュール分割の原則(単一責任・関心の分離)を理解し、1つの部品が1つの責務を持つように設計できる。 | 機能のまとまりを見極め、過剰・過少な分割を避けた最適な粒度のモジュールを設計できている。 | |
132 | 構造と設計 モジュール設計と粒度 |
32. 大規模化する前に処理単位でファイル分割できる | 大規模開発におけるソース管理とコンパイル単位を理解し、ファイル分割の目的と影響を把握している。 | 処理単位でファイルを分割し、保守性や可読性が高い構造に整理できている。 | |
133 | 構造と設計 モジュール設計と粒度 |
33. 機能単位での再利用を見越した設計ができる | 再利用性・疎結合・依存方向の原則を理解し、機能単位の分割設計を意識している。 | モジュールを他プロジェクトや他画面で再利用できる形で設計・実装できている。 | |
134 | 構造と設計 モジュール設計と粒度 |
34. ディレクトリ構成に意味を持たせられる | フォルダ構造・命名規則と責務の関係を理解している。 | ディレクトリ構成を見ただけで役割や依存関係が把握できるように設計できている。 | |
135 | 構造と設計 モジュール設計と粒度 |
35. 外部からの呼び出しを前提としたインターフェース設計ができる | インターフェースの設計原則(引数・戻り値・公開範囲)を理解している。 | 他モジュールからの利用を想定した明確で安全なインターフェースを設計できている。 | |
136 | 構造と設計 モジュール設計と粒度 |
36. 大規模モジュールを小さく再分割できる判断力がある | モジュールの凝集度と結合度を理解し、リファクタリングの基本手法を習得している。 | 肥大化したモジュールを機能単位に再分割し、保守性の高い構造へ改善できている。 | |
137 | 構造と設計 モジュール設計と粒度 |
37. 小さすぎる粒度が逆に可読性を下げることを理解している | 可読性・関心分離・関数呼び出しオーバーヘッドのバランスを理解している。 | 粒度が細かすぎて読みにくいモジュール構成を避け、最適な分割単位を判断できている。 | |
138 | 構造と設計 モジュール設計と粒度 |
38. UIパーツなど再利用性の高い部品をモジュール化できる | UIパーツやコンポーネントの再利用設計(Atomic Design等)を理解している。 | 複数画面で共通利用可能なUI部品をモジュール化し、メンテナンス効率を向上できている。 | |
139 | 構造と設計 モジュール設計と粒度 |
39. モジュール間の依存を明確に管理できる(import順など) | 依存関係管理とビルド順序(import / export / モジュールバンドラ)を理解している。 | モジュール間の依存関係を整理し、変更影響範囲を明確に管理できている。 | |
140 | 構造と設計 コードの再利用とDRY原則 |
40. モジュール粒度のばらつきを見直すことができる | コードレビューや静的解析を通じてモジュール粒度の偏りを検出・調整する方法を知っている。 | 全体構成を俯瞰して、モジュール粒度をそろえ、開発チーム全体で統一性を保てている。 | |
141 | 構造と設計 コードの再利用とDRY原則 |
41. 同じコードの重複に気づいて再利用にまとめられる | 同様の処理の重複がバグの温床となることを理解し、共通化の利点と手法(関数化、抽出、モジュール化)を知っている。 | 重複コードを発見した際に共通関数やライブラリとしてまとめ、保守効率を向上できている。 | |
142 | 構造と設計 コードの再利用とDRY原則 |
42. ユーティリティ関数としてまとめる癖がついている | 汎用性を考慮したユーティリティ関数の作り方を理解し、適切なスコープで再利用できるように設計できる。 | 同様の処理を複数箇所で再利用するためのユーティリティ関数を自発的に設計・活用できている。 | |
143 | 構造と設計 コードの再利用とDRY原則 |
43. 関数・クラスの粒度を再利用前提で設計できる | 関数・クラスの再利用性と単一責任の原則を理解し、過剰設計を避ける方法を知っている。 | 再利用を前提とした関数・クラス設計ができ、依存度の低いコードを書けている。 | |
144 | 構造と設計 コードの再利用とDRY原則 |
44. 条件分岐を汎用関数に切り出せる | 条件分岐の冗長化を避けるための関数抽出や戦略パターンなどの設計原則を理解している。 | 複雑な条件分岐を整理し、汎用的な関数や処理に抽出できている。 | |
145 | 構造と設計 コードの再利用とDRY原則 |
45. テンプレートやコンポーネントを使って見た目も再利用できる | テンプレートやコンポーネント構造(例:Blade, React, Vueなど)を理解し、再利用可能なUI部品化手法を習得している。 | 見た目や構造を共通化し、保守しやすい再利用テンプレート・コンポーネントを作成できている。 | |
146 | 構造と設計 コードの再利用とDRY原則 |
46. 外部ライブラリを再利用の手段として適切に選べる | 外部ライブラリやフレームワーク選定の基準(保守性・依存関係・ライセンス)を理解している。 | 要件に応じて適切な外部ライブラリを選定し、再利用基盤として安全に活用できている。 | |
147 | 構造と設計 コードの再利用とDRY原則 |
47. コードの再利用性と保守性のバランスを考慮できる | 保守性と再利用性のトレードオフを理解し、設計判断の基準を持っている。 | 再利用性を高めつつ、変更容易性やパフォーマンスを両立した構造を実現できている。 | |
148 | 構造と設計 コードの再利用とDRY原則 |
48. 他ファイルへの共通化を積極的に行える | 共通処理を別ファイルに切り出してモジュール化するプロジェクト構造を理解している。 | 他ファイルへの共通化を積極的に実施し、同一処理の重複を最小限に抑えられている。 | |
149 | 構造と設計 コードの再利用とDRY原則 |
49. DRYに反する例(似て非なる処理)を避けられる | DRY原則(Don’t Repeat Yourself)とKISS原則を理解している。 | 似て非なる処理の違いを見抜き、適切に共通化または分離して設計できている。 | |
150 | 構造と設計 コードの再利用とDRY原則 |
50. 変更点を最小限に留めるよう意識した構造にできる | ソフトウェア設計変更の影響範囲を分析するスキルを持ち、変更容易性の重要性を理解している。 | 変更時の影響を最小限に抑えるための構造設計を意識してコードを書けている。 | |
151 | 構造と設計 名前付けと意図の明確化 |
51. 変数名・関数名に処理や内容の意味を込めて命名できる | 命名の原則(意味の明確化、一貫性、スコープの意図)を理解している。 | 関数名・変数名に処理の目的や意味を持たせ、読み手が理解しやすい命名ができている。 | |
152 | 構造と設計 名前付けと意図の明確化 |
52. 意味のない略語(tmp, fooなど)を避けられる | 意味のない変数名・略語の弊害を理解し、チーム開発における命名基準を把握している。 | tmp, foo, test などの曖昧な命名を避け、内容が分かる名称を使用できている。 | |
153 | 構造と設計 名前付けと意図の明確化 |
53. 一貫性ある命名ルール(キャメル/スネーク等)を使える | 命名スタイル(キャメルケース/スネークケース等)とプロジェクト規約を理解している。 | チーム内で統一された命名規則を守り、可読性の高いコードを書けている。 | |
154 | 構造と設計 名前付けと意図の明確化 |
54. 状態を表す名前と動作を表す名前を区別して使える | 状態・動作を表す命名の違い(is_〜/do_〜など)を理解している。 | 変数や関数の命名で、状態と動作を区別し、誤解を生まない表現ができている。 | |
155 | 構造と設計 名前付けと意図の明確化 |
55. フォルダ名・ファイル名にも意味と責務を持たせられる | ファイル・ディレクトリ命名の責務分離を理解している。 | フォルダ名・ファイル名に機能や役割の意味を込め、構造を見ただけで目的がわかるようにできている。 | |
156 | 構造と設計 名前付けと意図の明確化 |
56. 複数人が理解しやすい命名にする配慮ができる | 他者視点での命名理解度を重視する姿勢を持ち、レビューや命名ルール策定に関与できる。 | チーム全体で理解しやすい命名を意識し、共同開発の生産性を高めている。 | |
157 | 構造と設計 名前付けと意図の明確化 |
57. 命名から処理の目的が自然に読み取れるように意識できる | リーダブルコードや命名原則書(Clean Code等)を理解している。 | 命名だけで処理の意図が伝わるコードを記述できる。 | |
158 | 構造と設計 名前付けと意図の明確化 |
58. 抽象度に合わせて命名粒度を変えられる | 抽象度と命名粒度の関係(汎用/個別)を理解している。 | 関数・クラス・変数の抽象度に応じて、過不足ない命名ができている。 | |
159 | 構造と設計 名前付けと意図の明確化 |
59. 名前付けに迷った時、チームやユーザーの視点で再考できる | ユーザー視点やビジネス文脈を命名に反映する方法を理解している。 | 命名に迷ったとき、利用者・チームの視点から再検討し、意図が伝わる名称を選べている。 | |
160 | 構造と設計 名前付けと意図の明確化 |
60. 命名を通して設計の曖昧さに気づくことができる | 命名と設計の関係を理解し、曖昧な名前が設計の曖昧さを示すことを把握している。 | 命名の不明確さを手がかりに設計改善点を発見し、構造の見直しにつなげられている。 | |
161 | 構造と設計 コードの階層構造設計 |
61. ファイルや関数の中にロジックを階層化して整理できる | コードの構造を論理的に整理するための階層設計やインデント・スコープの概念を理解している。 | 関数やファイル内のロジックを階層構造で整理し、流れが視覚的にも理解しやすい状態にできている。 | |
162 | 構造と設計 コードの階層構造設計 |
62. 処理の順序や優先順位が分かりやすくなるように設計できる | 処理の優先順位や依存関係を考慮してコードを構成するスキルを持つ。 | 処理の順序が直感的に追えるコードを書け、上から下へ自然に読める構造にできている。 | |
163 | 構造と設計 コードの階層構造設計 |
63. 階層が深くなりすぎるコードをリファクタリングできる | ネストや条件分岐が深くなる問題を理解し、リファクタリングの手法(関数抽出、早期returnなど)を知っている。 | 複雑化したコードを整理・分割し、可読性を保った状態に改善できている。 | |
164 | 構造と設計 コードの階層構造設計 |
64. 上位レイヤーと下位レイヤーの責任範囲を分けられる | アーキテクチャにおける上位・下位レイヤーの役割を理解している(例:MVC、クリーンアーキテクチャ)。 | 上位レイヤーが下位レイヤーに依存しないよう責任範囲を整理できている。 | |
165 | 構造と設計 コードの階層構造設計 |
65. ネストを減らすための早期リターンやガード節を使える | ガード節や早期returnの意図と可読性への影響を理解している。 | 深いネストを避けるために早期returnや例外処理を適切に使い、見通しのよいコードを書けている。 | |
166 | 構造と設計 コードの階層構造設計 |
66. 設計時点で構造の複雑さを可視化して調整できる | 設計段階で複雑性を定量的に評価(サイクロマティック複雑度など)し、調整する考え方を理解している。 | 構造の複雑さを事前に可視化し、必要に応じて整理・分割を行えている。 | |
167 | 構造と設計 コードの階層構造設計 |
67. 抽象から具体へ、段階的に処理を構成できる | 抽象化と具体化のバランスを理解し、階層的に思考を構成する方法を知っている。 | 抽象から具体へと段階的に構成された処理を実装できている。 | |
168 | 構造と設計 コードの階層構造設計 |
68. UI層・業務層・データ層などの階層分離を理解している | ソフトウェア分離の原則(UI層、ビジネス層、データ層など)の概念を理解している。 | レイヤーごとの責務を明確にし、UIやデータアクセスを分離した構造を実装できている。 | |
169 | 構造と設計 コードの階層構造設計 |
69. チーム全体の構造統一に貢献できる命名・配置ができる | チーム全体のコード構造を統一する意義を理解し、命名・配置ルール策定の経験を持つ。 | チームで共通化した階層構造・命名規則に沿った設計を実践し、可読性を高めている。 | |
170 | 構造と設計 コードの階層構造設計 |
70. 一貫した階層構造を保つことで、可読性と拡張性を担保できる | 一貫した階層構造を保つことが保守性・拡張性に直結することを理解している。 | 階層の統一を維持しながら機能追加・修正をスムーズに行える構造を実現できている。 | |
171 | 構造と設計 設計図(ワイヤー/ER図/クラス図)の描き方 |
71. 手書きでもいいので、構造を図で説明できる | 構造設計を他人に説明するための図解表現(ボックス図・レイヤー図など)を扱える。 | 設計内容を手書きや簡易図で説明でき、チーム共有に活用している。 | |
172 | 構造と設計 設計図(ワイヤー/ER図/クラス図)の描き方 |
72. ワイヤーフレームで画面遷移や構成を描ける | UI/UX設計の初期段階で画面構成をワイヤーフレームとして描くスキルを持っている。 | ワイヤーフレームを通して画面遷移・構成をチームに共有できている。 | |
173 | 構造と設計 設計図(ワイヤー/ER図/クラス図)の描き方 |
73. ER図でデータの関連と整合性を設計できる | ER図を用いたデータモデリングの基礎(正規化、リレーション、外部キー)を理解している。 | ER図でデータの整合性・関係性を設計し、DB構造に反映できている。 | |
174 | 構造と設計 設計図(ワイヤー/ER図/クラス図)の描き方 |
74. クラス図でオブジェクトの関係性を整理できる | クラス図の要素(クラス、属性、メソッド、関連)を理解し、オブジェクト設計を図示できる。 | クラス図を用いてオブジェクトの関係を整理し、実装と整合を取れる。 | |
175 | 構造と設計 設計図(ワイヤー/ER図/クラス図)の描き方 |
75. 処理フローをフローチャートやシーケンス図で表現できる | 処理の流れを表現するフローチャートやシーケンス図の記法を理解している。 | 複雑な処理フローを図で表し、レビューや設計検討で共有できている。 | |
176 | 構造と設計 設計図(ワイヤー/ER図/クラス図)の描き方 |
76. 誰にでも伝わる図にするためのラベル・説明の工夫ができる | 伝わる図解のためのラベル付け・注釈・構図設計の基本を理解している。 | 誰にでも理解できるような設計図・説明図を作成できている。 | |
177 | 構造と設計 設計図(ワイヤー/ER図/クラス図)の描き方 |
77. 図を見ながらコードを書いたり見直したりできる | 図とコードを行き来しながら整合を取る重要性を理解している。 | 図を見ながらコードを見直し、設計意図と実装を一致させることができている。 | |
178 | 構造と設計 設計図(ワイヤー/ER図/クラス図)の描き方 |
78. 設計図と実装の乖離を見つけて修正できる | 設計図と実装の乖離が発生する原因を理解し、修正プロセスを持っている。 | 乖離を発見した際に、設計またはコードのどちらかを適切に修正し整合を取れる。 | |
179 | 構造と設計 設計図(ワイヤー/ER図/クラス図)の描き方 |
79. 図で考えることで設計の抜け漏れに気づける | 図での思考(ビジュアルシンキング)が設計精度を高めることを理解している。 | 図で構造を整理し、抜け漏れや矛盾を事前に発見できている。 | |
180 | 構造と設計 スパゲッティコードの回避 |
80. チーム内で共有・説明可能な図解力を持っている | 図を用いた説明力・共有力を高めるコミュニケーションスキルを持っている。 | 設計意図を図でわかりやすく伝え、チーム全体で共通理解を得られている。 | |
181 | 構造と設計 スパゲッティコードの回避 |
81. コードの複雑化を自覚できる | コードの複雑性が増す原因(ネスト、依存、命名、ロジック密結合)を理解している。 | 自分や他人のコードの複雑化を早期に察知し、リファクタリング検討ができる。 | |
182 | 構造と設計 スパゲッティコードの回避 |
82. 関数が肥大化したときに整理しようとする姿勢がある | 関数の肥大化が保守性を下げることを理解し、関数分割の手法を知っている。 | 肥大化した関数を見直し、適切な粒度に整理し直せる。 | |
183 | 構造と設計 スパゲッティコードの回避 |
83. グローバル変数を避け、スコープを適切に設計できる | スコープと変数の生存範囲に関する言語仕様を理解している。 | グローバル変数を避け、関数・クラス単位でスコープを設計できる。 | |
184 | 構造と設計 スパゲッティコードの回避 |
84. 条件分岐が深くなったらリファクタリングを検討できる | 条件分岐の増加が可読性に与える影響を理解し、分岐整理のテクニックを知っている。 | 条件分岐が複雑な箇所を整理・単純化し、分岐を減らす工夫ができる。 | |
185 | 構造と設計 スパゲッティコードの回避 |
85. 「似た処理の繰り返し」をDRYの観点で共通化できる | DRY(Don’t Repeat Yourself)の原則とその意図を理解している。 | 重複する処理を共通化し、コードの一貫性を保てる。 | |
186 | 構造と設計 スパゲッティコードの回避 |
86. コピペしたコードの危険性に敏感である | コピペによる冗長コードやメンテナンスリスクを理解している。 | コピペに頼らず、共通ロジック化や再利用設計で対処できる。 | |
187 | 構造と設計 スパゲッティコードの回避 |
87. コードの意図が読めなくなる兆候を見抜ける | 意図が不明瞭なコードの兆候(命名・コメント不足など)を識別できる。 | コードの意図を読み取り、曖昧な箇所を改善または明確化できる。 | |
188 | 構造と設計 スパゲッティコードの回避 |
88. 可読性と保守性のバランスを常に意識している | 可読性と保守性をトレードオフとして考える観点を持っている。 | 短期のスピードと長期の保守性を両立させたバランス設計ができる。 | |
189 | 構造と設計 スパゲッティコードの回避 |
89. 処理のかたまりを再編成する習慣がある | 既存コードの構造を再整理するリファクタリング技法(抽出・統合・命名変更など)を知っている。 | 処理単位を再構成し、理解しやすく保守しやすい構造に変えられる。 | |
190 | 構造と設計 スパゲッティコードの回避 |
90. 他人のスパゲッティコードを見て「こう直したい」と考えられる | スパゲッティコードの特徴(循環依存・無秩序な分岐)を理解している。 | 他人の複雑なコードを見て、より整理された構造に再設計できる。 | |
191 | 構造と設計 拡張しやすい構造の考え方 |
91. 将来の変更を見越した構造設計ができる | ソフトウェアの拡張性設計(OCP原則など)の概念を理解している。 | 将来の変更や追加を見越して、拡張しやすい構造を設計できる。 | |
192 | 構造と設計 拡張しやすい構造の考え方 |
92. if文を増やさず処理分岐を構造で吸収できる(Strategyパターンなど) | if文などの条件分岐をパターン(Strategy, State等)で吸収する手法を理解している。 | 処理分岐を構造化し、コード修正を最小限に抑えられる。 | |
193 | 構造と設計 拡張しやすい構造の考え方 |
93. 新しい要素を追加しても既存コードに影響が出にくいよう設計できる | 既存コードへの影響を最小限にする設計(疎結合・依存注入など)を理解している。 | 新しい機能追加時に既存部分へ副作用を与えず実装できる。 | |
194 | 構造と設計 拡張しやすい構造の考え方 |
94. 設定ファイルや定数で制御する設計を取り入れられる | 設定ファイル・定数管理による柔軟なシステム設計を理解している。 | 変更箇所をコードではなく設定で制御できる構成を設計できる。 | |
195 | 構造と設計 拡張しやすい構造の考え方 |
95. 処理をイベント/フックの形で後から追加できるように設計できる | イベント駆動・フック・Observerなどの拡張手法を理解している。 | イベントやフックを設計に取り入れ、後から処理を追加できる構造を作れる。 | |
196 | 構造と設計 拡張しやすい構造の考え方 |
96. 「このままいくと破綻する」という設計の危険信号を察知できる | 設計崩壊の兆候(依存増大、循環参照、命名崩壊)を識別する力を持つ。 | 設計の危険信号を察知し、リファクタや分離を提案できる。 | |
197 | 構造と設計 拡張しやすい構造の考え方 |
97. 機能追加や再利用時の影響範囲を小さくする努力ができる | 影響範囲分析とテスト設計の基本を理解している。 | 再利用・改修時に影響範囲を限定し、安定したコード変更ができる。 | |
198 | 構造と設計 拡張しやすい構造の考え方 |
98. 外部API・仕様変更への柔軟性を持たせられる構造にできる | 外部APIや仕様変更に強い構造(Adapterパターン等)を理解している。 | 外部要素の変更に柔軟に対応できるモジュール構成を設計できる。 | |
199 | 構造と設計 拡張しやすい構造の考え方 |
99. 機能と構造を切り分けて、拡張・改修時のストレスを軽減できる | 機能面と構造面を切り分ける重要性を理解している。 | 機能追加・修正時に構造を崩さず、設計意図を保てるコードを書ける。 | |
200 | 構造と設計 拡張しやすい構造の考え方 |
100. 拡張性とシンプルさのバランスをとった設計ができる | シンプルさと拡張性のトレードオフを理解している。 | 過剰設計を避けつつ、将来の拡張に耐えうる設計バランスを取れている。 |