ソフトウェア設計のための抽象的・構造的思考
(present.do)ソフトウェアは、何らかの問題を解決するために存在します。だからこそ開発者は問題を理解し、それに合わせて設計し、実装します。このとき、問題を理解して設計するうえで、開発者にとって抽象的思考と構造的思考は大きな武器になります。
通常、抽象的思考や構造的思考は、難解であったり曖昧であったりする形で説明されることが少なくありません。しかし、そのような思考を行うための具体的な方法論は確かに存在します。この発表では、開発者が抽象的かつ構造的に考えるための具体的な方法と、その思考を通じてドメインモデリング、リファクタリング、アーキテクチャなどソフトウェアを設計する方法を紹介します。
- 開発者の仕事はプログラムを作ること
- プログラムを作る理由は特定の問題を解決するためであり、問題を解決する理由はビジネスのためであること
- プログラムを作るときは4つの段階で構成される
- 理解 / 分析 -> 設計 -> 実装 -> フィードバック
- 開発者はシニアになるほど、コードを書くことだけでなくこれらすべての段階に関わるようになる
- シニアは経験に基づく直感を通じて問題を素早く解決する
- しかし直感は危険になりうる。したがって方法論を身につけることが重要
- 抽象的思考と構造的思考は、そのような方法論の基礎
- 抽象とは、要素から共通するもの、あるいは関心のあるものを抽出すること
- そのため抽象とは、物事を単純化したうえで再解釈することだと見なせる
- 要素還元主義的な思考によって単純化し、再解釈できる
- 要素だけでなく、振る舞いも抽象化できる
- 抽象化には階層が存在する
- 適切な抽象化レベルを決めなければならない
- 過度な抽象化は実体が見えなくなるため好ましくない
- 構造的思考とは、内容が重ならず漏れなく整理すること
- MECEフレームワークに類似
- 重要なのは、必ずしも無条件に重複なく漏れなく整理されていなければならないという点ではない
- 構造化にも抽象化のように段階がある。もう一歩離れた視点で見ることができる
- 抽象的かつ構造的な思考法には具体的な方法が存在する
- トップダウンとボトムアップ
- モデル
- Classification
- Abstraction
- Generalization
- フレームワーク思考
- ソフトウェア設計に抽象的思考と構造的思考を適用できる
- ソフトウェアの実装段階は大きく3つに分けると、ドメインモデリング、アーキテクチャ、コード作成に分けられる
- ドメインモデリングでは、要件を抽象的に抽出し、段階的に拡張していくことができる
- アーキテクチャは仕事の進め方を表す
- どう進めるか、どう分けるか
- アーキテクチャは、要件 -> コンセプト -> 実装 -> フィードバックのプロセスに従う
- 抽象的なアーキテクチャのコンセプトを段階的に具体化していくことができる
- プログラミングパラダイムは、ソフトウェアの構成要素を見る視点
- ロジックは3つの側面から見ることができる。Function、Usecase、Aspect
- シンタックスシュガーは抽象化されたプログラミング構文
- 毒になることもある
- リファクタリングは、パラダイム、コードサイズ、所有権、重複の有無、修正可能性、依存という6つの観点で見られる
- リファクタリングには3つの方法がある。抽象化、構造化、一般化
- 抽象的で構造的な思考力を育てるには、さまざまな経験をするのがよい
- 図式化することは大いに役立つ
- 直感は経験主義的な思考。時間を節約できるが危険なこともある
- パターンは抽象的思考を身につける助けになる
- 抽象的・構造的であることが必ずしも万能ではない
10件のコメント
発表資料と内容の要約をありがとうございます。
IDを見ると、発表者ご本人なんですね！ Infoconの抽選に外れて参加できなかったのですが、発表資料を共有してくださってありがとうございます :)
ありがとうございます。 :D 私の資料がお役に立てたならうれしいです！
詳細な要約をありがとうございます。
要約は思ったより時間がかかりました ^^;; 読んでくださってありがとうございます！
良い文章と要約をありがとうございます〜
好意的に見ていただきありがとうございます :D
よく読みました！
適切な抽象化レベルを決めるべきです。
-> ここに誤字があります :)
ご確認ありがとうございます。:) ところで、一度投稿すると修正できないようですね（泣）
ああ、私が知らなかったんですね。確認ありがとうございます！