Code Complete 第2版 第1部 第3章 / Code Complete Second Edition Part 1 Chapter 3

Transcript

1. code complete 第2版 20181024読んだ内容まとめてLT会#demo2
2. この発表には発表者個人の経験・見解が多分に含まれています． 用量・用法を守って正しくお使いください．
3. 誰お前？ 名前 大杉 太郎 (おおすぎ たろう) 仕事 G's ACADEMY FUKUOKA 講師 年齢 30 (既婚) 出身 茨城県 好きなお酒 Ardbeg 好きなこと 外でコード書くこと
4. 曖昧なことを明文化すると幸せになれる code complete 第2版 20181024読んだ内容まとめてLT会#demo2
5. code complete第2版 ・読み始めたきっかけ：コードを書くときの考え方を研究したかった． ・上下巻で計1173ページ． →上巻628ページ，下巻545ページ．進まないorz ・上巻だけで4部19章から成る． ・今回は1部の3章 を紹介 ・漸く第1部終わると思ったら終わらなかったよ．．．(´・ω・｀)
6. 第3章：2回測って1度で切る 上流工程の必要性 第4章：コンストラクションの重要な決断(次回)
7. 第3章：2回測って1度で切る 上流工程の必要性 第4章：コンストラクションの重要な決断(次回)
8. 第3章 ・1章は設計前の準備の重要性についてを解説． ・ソフトウェアの実現には多くの要素がある．
9. 前回の第2章は．．．
10. キーワードは．．． メタファ = 比喩，たとえ
11. ソフトウェア設計のメタファ
12. 規模が大きいほど取り返しがつかない
13. 大工氏の言い分
14. 2回測って1度で切る！！ ・設計が全体の67%を占める．．！ ・複数回の繰り返しは良くない！ →1回で済ませられたら良くね??
15. 準備が最も大切 ・高品質な計画，要求，設計 ・高床式倉庫の設計で始めた建物は原発にならない ・最大の目標はリスクの低減
16. 各段階のリスク(建物の場合) ・計画段階で失敗の予感 →計画の練り直し ・設計段階で失敗の予感 →図面の書き直し ・実装段階で(ry →／(^o^)＼
17. 準備不足の原因 ①スキル不足の開発者 →大抵は計画，要求開発などの訓練を受けていない． ②コーディングが我慢できない開発者 →計画ができてもコーディングを重視しがち． ③準備を快く思わない上司 →まだコード書いてないの？？
18. 上司に準備の重要性をわからせる ①論理的に述べる →ユーザーが求めているものは? コストや時間は? ②メタファを用いる →設計図を明確にしてから基礎工事を実施する． ③データで訴える →過去のデータで最初が肝心であることが示されている！
20. どれがいいか上司へ訊いてみよう！ ①デバッグが多くなりそうだからすぐ始める ②欠陥は少なそうなのでテストの時間は少なくて良さそう ③要求と設計を入念に実施したので問題は少なそう
21. 準備って何するの??
22. 準備①課題定義 システムが解決する課題を明記すること！
23. 準備①課題定義 システムが解決する課題を明記すること
24. 準備②要求 要求は絶対に明文化すること！！ ・開発者とユーザーで共有し，議論を減らす． ・機能の実装で意見が食い違った場合に要求仕様書を見る． ・要求が明確でないと全部やり直しも．．．
25. 要求は水のようなものだ (えらい人) とは言っても．．．
26. とは言っても．．． 初期段階で要求を明確に説明できる顧客は存在しない．． ・要求の約25%が変更される． (Boehm 1981; Jones 2000) →要求の変更による影響を最小限に抑える手段が必要
27. 準備③要求変更への対処 ・新しい機能を思いついて興奮する顧客 |*･ω･)ﾉ ｼｭｯ≡≡≡≡≡[ｺｽﾄ][ｽｹｼﾞｭｰﾙ] ・変更管理手順を策定する． ・変更に対応しやすい開発手法を用いる．
28. 準備③要求変更への対処 「機能」≠「ビジネス上の価値」
29. 要求がいい感じになったら．．． ・ソフトウェアアーキテクチャ(解決手段の設計) ・アーキテクチャのエラー ≒ 要求のエラー →表面上わかりにくいが影響が大きい．
30. 要求がいい感じになったら．．． ・ソフトウェアアーキテクチャ(解決手段の設計) ・アーキテクチャのエラー ≒ 要求のエラー →表面上わかりにくいが影響が大きい．
31. アーキテクチャ設計 ・クラスの設計，データ設計，UIの設計，リソース管理 ・セキュリティ，パフォーマンス，スケーラビリティ ・国際化&地域化，エラー処理，フォールトトレランス ・実現可能性，オーバーエンジニアリング
32. 優れたアーキテクチャ設計 ・上記の条項が考慮されていること． ・採用不採用の理由が明記されていること． ・必要のない機能が含まれていないこと．
33. 今日のまとめ&私見
34. 設計の準備は．．． ・要求を明文化すると無駄な議論をなくせる ・機能 ≠ 価値 ・アーキテクチャも明文化すべし
35. ご静聴ありがとうございました！