Code Complete 第2版 第2部 第5章 / Code Complete Second Edition Part 02 Chapter 05

Transcript

1. 1 / 38 code complete 第2 版 5 章 2019/02/19 @ 読んだ内容まとめてLT 会#05 @taro_osg
2. 2 / 38 自己紹介 基本情報 氏名：大杉太郎 仕事：G's ACADEMY FUKUOKA 講師 年齢：31 出身：茨城 => 北海道 => 東京 => 福岡 好きな技術 javascript （vue.js, firebase, ajax ） PHP （laravel ） その他好きなもの 旅行 写真
3. 3 / 38 自己紹介
4. 4 / 38 code complete について 読み始めたきっかけ：コードを書くときの考え方を研究したかった． 上下巻で計1173 ページ(´ ・ω ・｀;) 上巻628 ページ 下巻545 ページ 今日は第2 部の5 章．
5. 5 / 38 これまでの雑なまとめ 第 1 章：導入 第 2 章：ソフトウェア設計の実感がわかない場合はメタファを使え！ わかりにくい概念はみんな知っているもので例えると良い． 雑学大事！ 第 3 章：アーキテクチャ設計は準備がとっっっても大事 書きたい気持ちはわかるが準備．上司はメタファやデータで殴れ． 変更しやすい計画と明文化を意識！ 第 4 章：書くときの考え方 表現したい事を決めて，どう書けばよいかを考える！
6. 6 / 38 第5 章 コンストラクションにおける設計 5.1 設計の難題 5.2 重要な設計概念 5.3 構成要素の設計：ヒューリスティクス 5.4 設計のプラクティス 5.5 一般的な設計手法へのコメント 5.6 参考資料 5.7 まとめ
7. 7 / 38 コンストラクションにおける設計とは 規模によってコンストラクションの範囲は様々． 大規模な例ではアーキテクチャではシステムレベルの問題のみ． 小規模な例ではより多くの作業がコンストラクションに含まれる． 小規模な場合の例： 必要なクラスを考えて関係を図に表す． デザインパターンの良し悪しを考えて議論する． 必要な画面からDB の設計を考える．
8. 8 / 38 5.1 設計の難題 「ソフトウェア設計」とは仕様を実物に変化させるための概念， 発想，工夫 偉い人の意見 要求仕様からエラーのない合理的な方法で設計を行うのは無理． その昔，タコマ橋の設計したけどあれはやばかった．．． 重量を支えられる構造にしたけど風吹くとか聞いてないし．．． 科学者はそれまで空気力学を考慮する必要があるとは考えていなかった． 課題を出して，完成直前に課題を変更するようなもの．
9. 9 / 38 5.1 設計の難題 設計はルーズなプロセス 設計が完成したら明確なものであってほしい． しかし大体ルーズなものになる． 設計がルーズになる理由 いろいろなことを間違えるため． 良い解決策と悪い解決策の違いが僅かであるため． ただし，設計でいろいろ間違えたほうがコードが完成して修正するよ りまし． => どこまでやれば十分な設計なのか？？
10. 10 / 38 5.1 設計の難題 「設計」は妥協と優先順位の産物 理想のソフトウェアは．．． 全てのシステムが瞬時に動作． 記憶領域や帯域幅の消費がゼロ． エラーも0 ． 現実は．．． 無理っす．．． 設計上の要素を重み付けしてバランスを取る． 時間と要求事項の優先度で設計を選択する．
11. 11 / 38 5.1 のまとめ 設計はけっこう行き当たりばったり 知らなかった問題を発見した． 良い悪いの差が紙一重． ゴールが毎回変わる． => やってみないとわからないことが多いので，レビューや経験が大事！
12. 12 / 38 5.2 重要な設計概念 良い設計は一握りの重要な概念を理解しているかどうかにかかっている！！
13. 13 / 38 5.2 重要な設計概念 本質は複雑性への対処 偶発的な問題：物事が物事であるかどうかに影響しない 車のエンジンをどれにするか．ドアの数をいくつにするか． 現在では解決されている． 本質的な問題：複雑性への対処 現実世界は複雑． ソフトウェアが対処する現実問題は大きい． 現実が複雑になるのでソフトウェアも複雑になる． => 開発者はプログラム全体を頭に詰め込まず，一度に検討する量を減らせ！
14. 14 / 38 5.2 重要な設計概念 一度に検討する量を減らす 簡単な問題 * 10 < 難しい問題 * 1 複雑な問題は簡単な問題に分割し，単純に解決する． 自分が考えているほど人間は優秀ではない．限界を知ろう．
15. 15 / 38 5.2 重要な設計概念 目指すべき設計 できる限り単純． 保守しやすい． 疎結合． 拡張性． 再利用性． 高いファンイン．（そのクラスを多くのクラスが使用する） 低いファンアウト．（1 つのクラスが使用する他のクラス数を減らす） 無駄の無さ．（減らせるものがなくなったら完成） 階層化．
16. 16 / 38 5.2 重要な設計概念 ソフトウェア設計のレベル ソフトウェアシステム サブシステム1 クラス1 ルーチン1 内部設計 ルーチン2 内部設計 クラス2 ... サブシステム2 ...
17. 17 / 38 5.2 重要な設計概念 サブシステムのやり取りは水を通すホース ソフトウェア全体に対して，複数のサブシステムが存在する． 業務ルール UI DB アクセス ... 何も考えずに設計すると，「多対多」のやり取りが必要になる． ホースのコネクタが多いほど水漏れのリスクが高まる． => 本当にやり取りが必要なのか吟味する． => 循環関係は NG ！
18. 18 / 38 5.2 のまとめ 人間は賢くない 設計の本質は複雑性への対応． 現実世界の複雑さが増すごとにソフトウェア設計も複雑になる． 何も考えずに設計するとまずい．．． => 難しい問題は簡単な問題に分ける． => つながりや依存関係をできるだけなくす．
19. 19 / 38 5.3 構成要素の設計：ヒューリスティクス 設計はひらめき 開発者は決まった答えを好む． しかし，設計はそうではない． ヒューリスティクスは「試行錯誤」の「試行」部分．
20. 20 / 38 5.3 構成要素の設計：ヒューリスティクス 現実世界のオブジェクト システムが「何をするか」ではなく，「何のために何をするか」を問おう． by 偉い人 現実で実現すべきことについてオブジェクトを意識して考える． オブジェクトと属性の特定． 各オブジェクトの目的の特定． 各オブジェクトが他のオブジェクトにできることの特定． パブリック部分とプライベート部分の決定． インターフェイスの定義．
21. 21 / 38 5.3 構成要素の設計：ヒューリスティクス 抽象化 適切に抽象化することで，関連性のない詳細を無視できる． 具体的な例： 「ガラス，木，釘の組み合わせ」 抽象的な例： 「家」 現実世界のオブジェクトの殆どは何らかの抽象化． => 抽象化は複雑性に対応するための方法．
22. 22 / 38 5.3 構成要素の設計：ヒューリスティクス 情報の隠蔽 ソフトウェア設計において影響力が大きい！ 情報の隠蔽は作業のやり直しを減らす． 変更の多い環境で特に効果的である． => 「情報の隠蔽」 = 「複雑さの隠蔽」
23. 23 / 38 5.3 構成要素の設計：ヒューリスティクス 見えない情報の取扱 見えない情報の例 ファイルフォーマット データ型 インクリメンタルなパラメータの処理 エラー対応のコード => 必要な部分を最小限見えるようにした設計を意識する！ => 常に「何が隠蔽できるか」を問おう！
24. 24 / 38 5.3 構成要素の設計：ヒューリスティクス 情報隠蔽の壁 過度な情報伝達 情報の散らばり． ユーザーとやりとりをするコード． グローバルなデータ要素． 循環依存 クラスA がクラスB を参照． クラスB がクラスA を参照． 上記が同時に発生．
25. 25 / 38 5.3 構成要素の設計：ヒューリスティクス 疎結合の維持 複雑さを避けるため，他のクラスやルーチンとの結合を小さくする． モジュールが他のモジュールから簡単に使用できるくらい． 複雑になればなるほど作業量や故障のリスクが高まる． 例： 鉄道模型における車両の連結． カバンの開閉． => できるだけ他のモジュールに依存しないモジュールを作成しよう！ ※ モジュール = クラス + ルーチン
26. 26 / 38 5.3 構成要素の設計：ヒューリスティクス デザインパターン メリット 毎回イチから考えるのは大変なので過去の経験に学ぼう． すでに問題が検討され，解決されている． 「選択肢を検討して提案する」ことの価値． より上位レベルで設計についての議論ができる． デメリット 手段の目的化．
27. 27 / 38 5.3 構成要素の設計：ヒューリスティクス その他のヒューリスティクス 責任の割当． 図の作成． 設計のモジュール化． -> ルーチンやクラスをブラックボックス化する．
28. 28 / 38 5.3 のまとめ できるだけ複雑さを避けよう 現実世界のオブジェクトを意識． 抽象的なものをつくっておいて利用しよう． 見せる必要がないものは隠せ． モジュールはできる限り独立． => 一つの方法にこだわらない！ => 全部一度に解決はできないので，行き詰まったら散歩に出かけよう！
29. 29 / 38 5.4 設計のプラクティス 反復 良さそうな設計を思いついた！ もう一度考えると大抵最初より良くなる． => 考える回数を増やす！ => 失敗はダメパターンの発見！
30. 30 / 38 5.4 設計のプラクティス 分割攻略 人間は賢くない． 問題を分ける -> それぞれ反復． 計画 -> 実行 -> レビュー の繰り返し． どこまで分割すれば良い？？ => 分解よりコーディングが楽になるまで！
31. 31 / 38 5.4 設計のプラクティス トップダウン方式とボトムアップ方式 トップダウン 抽象度の高いクラスをつくる． 作業が進んだら必要に応じてサブクラスを定義． 最初は簡単で後に難しくなる． ボトムアップ 具体的な要素を考え，まとめて汎用化する． 最初は難しいが，後から楽できる． => 両者は競合しない．毎回試行錯誤しよう！
32. 32 / 38 5.4 設計のプラクティス プロトタイプ 知見がなく，やってみなければわからないタイプの問題． 必要最小限のコードを実装して実験する． 問題の大枠を把握して実装する能力が必要． => 問題の本質を把握することが重要！ => コードは使い捨てであることを理解！
33. 33 / 38 5.4 設計のプラクティス どこまで設計するか 設計が個人レベルになる． 過去に経験のあるタスクのレベルになる． 経験のあるタスクの修正や拡張でなんとかなる． くらいまで実施するとコーディングの準備が整う． 設計の問題は「十分だと思ったが後から問題が見つかること」
34. 34 / 38 5.4 設計のプラクティス 設計作業の文書化 設計書の作成以外にも設計を記録する方法は存在する． 設計書をコードの一部にぶち込む． プロジェクトのwiki を活用する． デジタルカメラの使用． ... => 上記を組み合わせて活用しよう！
35. 35 / 38 5.4 のまとめ 知らないことは多いが知っていることも多い 考える頻度と回数を増やす！ 問題を分割する． 問題の本質は何か？？ たくさんの解決策がある． => できるだけコーディングを楽にする！ => 正解はないので組み合わせよう！
36. 36 / 38 5.5 一般的な手法へのコメント 1990 年代初め：設計過激派（Big Design Up Front ） 2000 年代初め：設計不要論 その後：Little Design Up Front, Enough Design Up Front => 設計に正解はない！ => 両極端だけは NG ！
37. 37 / 38 今日のまとめ ・設計の本質は「難しいことを簡単にすること」 ・人間は賢くないので問題を分割しよう！ ・正解はないので経験を積んで試行錯誤！
38. 38 / 38 ご清聴ありがとうございました！！