Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Modeling×tdd×ddd
More from Iwao Harada
Modeling×tdd×ddd
- 1. Modeling × TDD × DDD Devlove甲子園2014 二階裏 ～モデアジャ第2段～
- 2. これは前に発表された続きものです DevLove現場甲子園2013 2013年11月9日(土) 11:00～20:00 • 4つのテーマ 「創、考、守、団」 • 発表時間は 20分で4テーマ同時進行 参考：DevLOVE現場甲子園2013 http://devlove.doorkeeper.jp/events/5464
- 10. Context • いつもながら愛情溢れるSIerの話です • いわゆる大規模請負案件です • 複数チームいます • 複数社います
- 11. Problem • Why can’t we all play nice? Linda Rising http://www.computer.org/csdl/mags/so/2012/05/mso2012050007.pdf People naturally sort others into in-groups and out-groups, just by their appearances and actions
- 13. 単純な解決策なんて無い！
- 14. 私の根底にある想い Agileは自己組織化とフィードバック • 壁（組織だったりチームだったり会社 だったり）を作りだすことで歪みが出来 てしまう • 思想を理解するだけではダメ。実行して 気が付く事もある • 要は「行動と学び」を繰り返していかな いといけない
- 15. さて本題
- 16. 今日話すこと 1. 開発現場の問題 （モデリングもしないでアジャイルとは何事だ!?の復習） 2. DDDから学んだ事 – 動くコードでモデルを検証！ 3. それでも解決できない問題 – DDDとTDDでより良いモデリング！ 4. 明日から実践する事
- 18. 現場ではDDDを実践してます • DDD流行ってますよね？（多分） • 有名人が絶賛してますよね？（多分） • かっこいいですよね？（多分）
- 20. でもやるからには 完璧に実行したい • 積ん読されているEric EvansのDDDを読ま ないと・・・ • オブジェクト指向の基礎を確認しておかない と・・・ でも、その前に「考えないといけない」ことは
- 23. 現場での問題点 • モデリングの必要性 • デザインの理由の欠如 • アジャイルの文脈でのモデリング – そこで作り出したかったもの • 共通認識 • 目的を明らかにする • 不確実性に対応する そして、
- 25. 1. 開発現場の問題 まとめ • 開発現場の問題への対応 – モデリングは重要である • 共通認識を築くために地図としてモデル • 誰もが学べる共通言語としてのモデル • 一緒に作り上げて認識を合わせる場の形成 – モデリングと実装を合わせて成長させていく • モデリングの目的を明確にしてコードに繋げる
- 27. さて、まず何をしますか？
- 28. そうモデリング！
- 30. システムとは何で出来ているか？ • 平鍋さんとの飲みでの話 平鍋さん 「システムは物語で出来ている」 この時に思ったこと – モデル（やポンチ絵などの図）はお客様と交わされ る物語を表している – コードはコンピュータと交わされる物語を表してい る
- 31. つまり • シナリオも無しにモデリングとは何事だ！ – その“言葉”はどこで拾ってきたの？ – その“モデル”は何の問題を解決しているの？ → やりたいのは“コア”を見つけだす事 ※シナリオと書きましたがユースケースでもユーザストーリーでもその 他どんな書式でも。要はお客様の語る物語ベースでないとそもそも何 作っているのか訳が分からないよね？
- 32. ゆびきたす
- 33. でも最近のシステム開発って
- 34. 現場にいるのは・・・ • 「これドーン！とやっちゃってよ！」 – 画面にボタンの追加（無意味） – 裏の仕組みなんてどうでもいいじゃん！ – リリースは明日ね！ – 仕組み？動かすのはお前の仕事だろ！
- 35. 一方で、仕様はエンジニアの妄想 で生まれる • 「そんなの仕様にない！仕様変更だ！」 （from 原田騎郎さんのDDD&Scrumワークショップより） – とか言ってもその仕様はどこから？ – ○○って事は✕✕って 変更は“多分”あるよね？ – それデザインパターンだ！
- 36. モデルの問題点 • 学びとしてモデル（もしくは図解）は良 い方向であるのは確か • しかし、モデルには限界もある – 図としての限界 – 伝えられる事の限界
- 43. 上手くモデリングしていくには
- 44. DDD with Scrum DDDをScrumで廻す あるいは ScrumをDDDで廻す http://www.slideshare.net/kiroh/dddscrum-scrumddd
- 45. DDDを通して気付く学びのループ
- 46. 小さく、そして速く 1. シナリオを探索する 2. モデルを小さく作る 3. モデルをコードにする 4. 動くコードからフィードバックを得て、 少しずつモデルを成長させていく 5. 回転を小さくイテレーティブに提供する ことで少しずつ学んでいける
- 47. みんなで賢く学んでいくこと
- 48. 2. DDDから学んだこと まとめ • 道具を理解して正しく使う – UML＆ポンチ絵 – オブジェクト指向＆DDD – Scrum • 動くコードでモデルを検証する • 実装で分かったことをモデルにフィードバッ クする • 小さく、そして速く！ 動くコードでモデルを検証！
- 49. 3. それでも解決できない問題
- 52. モデルも書いた、ソースコードも書いたけど • 依然残る問題 – モデルをソースで補完 – ソースは仕様通り動いている – ユーザレビューもOK でも、それって本当に「正しいの」？
- 53. さぁ！テストをしようか！？
- 54. TDDの私の持っている印象 • 実はTDDが嫌いです – TDDはテスト手法？ – TDDは単体テスト？
- 55. TDDは意味をなくしている とある現場の会話。 * 「単体テスト完了！C0/C1 100%！」 私「了解です。で、なんでこのシグニチャ なんですか？」 * 「・・・」 TDD界隈の人はそんな事ないだろう でも、悲しいかな現場はそんなもんだ
- 57. TDD is Dead Cope says “Most UT is Waste” • UT tests methods, not the module/class → TDDは設計技法である
- 58. テスト戦略 • C0/C1は政治問題 • どんなテストを何の目的で行うのかを先に決 めておかないといけない → “単体試験”とTDDを混同してはいけない！ でも、テスト戦略については今回のスライド範 囲外なのでまたの機会に・・・
- 59. DDD × TDDで見えること • テストでモデル（設計）の「確からし さ」を検証する • TDDの結果見えたものをモデルにフィー ドバックする
- 63. モデリングとTDD • モデリングとTDDは同時進行 – モデリングは重要であるが実装やテストと合わせて 設計を行う – 検証したいのは「設計の確からしさ」である – リファクタリングされれば単体レベルのテストコー ドはゴミである – モデルが検証されれば単体レベルのテストコードは 無用である つまりTDDは設計で使用し、作成したテストコード は捨ててしまった方がいい（ことが多い）。 1. UT is not automated test 2. heavy mocking hurts architecture （from DHH says “TDD is Dead”）
- 64. いつ実装を開始するか • モデリングするのは「事前設計」レベル – 「直前設計」と言う方が感覚に合う – 大き過ぎるモデルは実装・テストサイクルが 遅くなる結果、学びが遅く間違える – 小さくモデリングして実装（TDD）して、 コードや実行結果からフィードバックを得る ※勿論、全体性の認識は最初にとっておかないといけない • 増田さん：パッケージ図 • かとじゅんさん：コンテキストマップ
- 66. 忘れちゃいけない！！！ How Do We Know When We Are Done? Doneの定義 How Do We Know When We Are Done? https://www.scrumalliance.org/community/articles/2008/september/how-do-we-know-when-we-are-done
- 67. いつ終えるのか？ • やろうと思えばいくらでもこだわること ができる • 斧を研ぎすぎて、木を切る仕事を忘れ ちゃいけない（目的重要） – 三人のレンガ職人 「あなたは何をしていますか？」 モデルもコードも引き際大事
- 72. ［入口での転換（112）］より <より大きなパタンとの結合> …どんな建物や複合建物の場合でも、すでにそ の主入口の大まかな位置は分かっている－［大 きな門口（53）］から敷地への門、［見分けやすい 入口の集まり（102）］から各建物への玄関、そし て玄関。いずれにしろ、入口は「外部」－公的世 界－からさほど公的でない内部世界への転換を つくり出す。 モデルは捨像 • この世の森羅万象は表せない • でも、「パタン」を見出すことで「木を 見ながら森を見ることができる」 – Ex) 門 http://fashionjp.net/creatorsblog/fujita/2010/08/post-89.html
- 73. パタン・ランゲージ重要 • パタン・ランゲージ 「あるコンテキストにおける問題の解決方法」 – パターンの名前 – パターンの目的、 すなわり解決する問題 – その達成方法 – 達成する上で考慮する必要 がある制約とフォース
- 74. 3. それでも解決できない問題 まとめ • 設計技法としてTDDとDDDは親和性がよ い • モデリングと実装・テストは同時に進め るべき • そこから本質を発見していく DDDとTDDで より良いモデリング！
- 79. オブジェクト指向とは • 定義は本にお任せ – そんなの手法の一つ • でも、今までやってきた10年超の経験か ら「正しいこと」にリーチできると思っ ている • 『必ずしもオブジェクト思考は銀の弾丸 じゃないが、武器は多いほうが絶対にい い』（オブジェクト指向エクササイズのススメ http://www.slideshare.net/yojik/ss-1033616 より）
- 81. 最後に
- 83. 何より大切なもの
- 86. 次回、予告
- 88. ●おわり●