Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Modeling×tdd×ddd

Devlove甲子園2014 二回裏
2014.8.23 発表資料

  • Als Erste(r) kommentieren

Modeling×tdd×ddd

  1. 1. Modeling × TDD × DDD Devlove甲子園2014 二階裏 ~モデアジャ第2段~
  2. 2. これは前に発表された続きものです DevLove現場甲子園2013 2013年11月9日(土) 11:00~20:00 • 4つのテーマ 「創、考、守、団」 • 発表時間は 20分で4テーマ同時進行 参考:DevLOVE現場甲子園2013 http://devlove.doorkeeper.jp/events/5464
  3. 3. モデリングもしないで アジャイルとは何事だ?
  4. 4. 皆様に愛されて2万View 発表後、upから1日で1万View達成! 現在も少しずつViewとlike, Download が伸びてます http://www.slideshare.net/iwaoRd/ss-28075252 2014年8月15日現在 21,000 View突破!
  5. 5. 色々な人の支えがあってのView数 Facebookにて羽生田さん からリンクシェア はてなでブックマークが 310ユーザー達成 Twitterにて平鍋さんから リンクTweet 感謝
  6. 6. モデリングしないで 開発するとどんな感じ? 宣伝はさておき!
  7. 7. イメージは こんな感じ? *「おお アジャイラーよ! しんでしまうとは なにごとだ!
  8. 8. 自己紹介 原田 巌 @iwaoRd 「人生、全速力で回り道」 モデモデ言ってるSIer勤務
  9. 9. はじめに • はっきり言って前回発表時から状況が好 転していない • 何かをしては何かの問題が発生するモグ ラたたき状態 納品する受託開発がダメと言われたらそう かもしれないけど、まだ成功に向けての足 掻きが足らないと思うのです・・・
  10. 10. Context • いつもながら愛情溢れるSIerの話です • いわゆる大規模請負案件です • 複数チームいます • 複数社います
  11. 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
  12. 12. 複雑な関係・・・ 現場にはForceが 沢山蠢いていて、 何かをするにも 何かのForceの影響をうける
  13. 13. 単純な解決策なんて無い!
  14. 14. 私の根底にある想い Agileは自己組織化とフィードバック • 壁(組織だったりチームだったり会社 だったり)を作りだすことで歪みが出来 てしまう • 思想を理解するだけではダメ。実行して 気が付く事もある • 要は「行動と学び」を繰り返していかな いといけない
  15. 15. さて本題
  16. 16. 今日話すこと 1. 開発現場の問題 (モデリングもしないでアジャイルとは何事だ!?の復習) 2. DDDから学んだ事 – 動くコードでモデルを検証! 3. それでも解決できない問題 – DDDとTDDでより良いモデリング! 4. 明日から実践する事
  17. 17. 1. 開発現場の問題 客「○○というのを作りたい」 私「はい」 客「・・・」 私「・・・」 客「作って」 私「えっ!?・・・」
  18. 18. 現場ではDDDを実践してます • DDD流行ってますよね?(多分) • 有名人が絶賛してますよね?(多分) • かっこいいですよね?(多分)
  19. 19. なぜ、DDDを採用したのか? 実はキッカケは • お客様のOrderだから • やらされDDD です(笑 それが DDD? え?いや、その 多分www
  20. 20. でもやるからには 完璧に実行したい • 積ん読されているEric EvansのDDDを読ま ないと・・・ • オブジェクト指向の基礎を確認しておかない と・・・ でも、その前に「考えないといけない」ことは
  21. 21. わ け なぜ、DDDが必要だったのか?
  22. 22. DDD上手くやろうとして 見えた問題 • 前回の「モデリングもしないでアジャイ ルとは何事だ!?」 http://www.slideshare.net/iwaoRd/ss-28075252
  23. 23. 現場での問題点 • モデリングの必要性 • デザインの理由の欠如 • アジャイルの文脈でのモデリング – そこで作り出したかったもの • 共通認識 • 目的を明らかにする • 不確実性に対応する そして、
  24. 24. コードとモデリング 【バードビュー】 欲しいモノを叶える力を 私達は持っている!
  25. 25. 1. 開発現場の問題 まとめ • 開発現場の問題への対応 – モデリングは重要である • 共通認識を築くために地図としてモデル • 誰もが学べる共通言語としてのモデル • 一緒に作り上げて認識を合わせる場の形成 – モデリングと実装を合わせて成長させていく • モデリングの目的を明確にしてコードに繋げる
  26. 26. 2. DDDから学んだ事 http://www.amazon.co.jp/dp/B00794TAUG/
  27. 27. さて、まず何をしますか?
  28. 28. そうモデリング!
  29. 29. 閑話休題 モデルはどこから生まれるか? ?
  30. 30. システムとは何で出来ているか? • 平鍋さんとの飲みでの話 平鍋さん 「システムは物語で出来ている」 この時に思ったこと – モデル(やポンチ絵などの図)はお客様と交わされ る物語を表している – コードはコンピュータと交わされる物語を表してい る
  31. 31. つまり • シナリオも無しにモデリングとは何事だ! – その“言葉”はどこで拾ってきたの? – その“モデル”は何の問題を解決しているの? → やりたいのは“コア”を見つけだす事 ※シナリオと書きましたがユースケースでもユーザストーリーでもその 他どんな書式でも。要はお客様の語る物語ベースでないとそもそも何 作っているのか訳が分からないよね?
  32. 32. ゆびきたす
  33. 33. でも最近のシステム開発って
  34. 34. 現場にいるのは・・・ • 「これドーン!とやっちゃってよ!」 – 画面にボタンの追加(無意味) – 裏の仕組みなんてどうでもいいじゃん! – リリースは明日ね! – 仕組み?動かすのはお前の仕事だろ!
  35. 35. 一方で、仕様はエンジニアの妄想 で生まれる • 「そんなの仕様にない!仕様変更だ!」 (from 原田騎郎さんのDDD&Scrumワークショップより) – とか言ってもその仕様はどこから? – ○○って事は✕✕って 変更は“多分”あるよね? – それデザインパターンだ!
  36. 36. モデルの問題点 • 学びとしてモデル(もしくは図解)は良 い方向であるのは確か • しかし、モデルには限界もある – 図としての限界 – 伝えられる事の限界
  37. 37. とは言え • 熱意がある人(当事者)は食らいついて くる印象 モデルが伝わらないのって、誰!?
  38. 38. 現場の一場面 私 「ということで、○○に着目するとA案、 B案のような設計が考えられますが、 ✕✕からA案を取り、△△があっても C案移行しやすくしま・・ 人 「説明は分かった気がする。で、 ER図はいつ貰えるの??」
  39. 39. そもそもモデルに興味ない!? 興味ない人達が やっている事 モデル距離感 モデルだけでは解決に繋がらない!!! モデルわかんない! 無くても大丈夫!
  40. 40. モデルを書けば (すべて)上手くいく訳じゃない
  41. 41. 「正しいモデル」を書けばOK? 分析中毒に陥る悪魔の証明問題です。
  42. 42. 必要なもの • ビジネスやユーザに立ち向かう 勇者の剣や盾 http://www.mpsnet.co.jp/hobbynet/products/doll/44501.html
  43. 43. 上手くモデリングしていくには
  44. 44. DDD with Scrum DDDをScrumで廻す あるいは ScrumをDDDで廻す http://www.slideshare.net/kiroh/dddscrum-scrumddd
  45. 45. DDDを通して気付く学びのループ
  46. 46. 小さく、そして速く 1. シナリオを探索する 2. モデルを小さく作る 3. モデルをコードにする 4. 動くコードからフィードバックを得て、 少しずつモデルを成長させていく 5. 回転を小さくイテレーティブに提供する ことで少しずつ学んでいける
  47. 47. みんなで賢く学んでいくこと
  48. 48. 2. DDDから学んだこと まとめ • 道具を理解して正しく使う – UML&ポンチ絵 – オブジェクト指向&DDD – Scrum • 動くコードでモデルを検証する • 実装で分かったことをモデルにフィードバッ クする • 小さく、そして速く! 動くコードでモデルを検証!
  49. 49. 3. それでも解決できない問題
  50. 50. 現場での話 私「シナリオが○○だからこのモデルの 認識です。次にあのケースですが、 客「あの・・・」 私「はい?」 客「そのモデルの確からしさってどのよう に検証されるのですか?」
  51. 51. 質問! あなたの設計や実装が正しいと何で判断し ますか?
  52. 52. モデルも書いた、ソースコードも書いたけど • 依然残る問題 – モデルをソースで補完 – ソースは仕様通り動いている – ユーザレビューもOK でも、それって本当に「正しいの」?
  53. 53. さぁ!テストをしようか!?
  54. 54. TDDの私の持っている印象 • 実はTDDが嫌いです – TDDはテスト手法? – TDDは単体テスト?
  55. 55. TDDは意味をなくしている とある現場の会話。 * 「単体テスト完了!C0/C1 100%!」 私「了解です。で、なんでこのシグニチャ なんですか?」 * 「・・・」 TDD界隈の人はそんな事ないだろう でも、悲しいかな現場はそんなもんだ
  56. 56. とあるTDDの会話 私 「どうしてこの設計にしたの?」 人 「テストしにくかったから変更しました」 多分、合ってる。 でも、間違っている。
  57. 57. TDD is Dead Cope says “Most UT is Waste” • UT tests methods, not the module/class → TDDは設計技法である
  58. 58. テスト戦略 • C0/C1は政治問題 • どんなテストを何の目的で行うのかを先に決 めておかないといけない → “単体試験”とTDDを混同してはいけない! でも、テスト戦略については今回のスライド範 囲外なのでまたの機会に・・・
  59. 59. DDD × TDDで見えること • テストでモデル(設計)の「確からし さ」を検証する • TDDの結果見えたものをモデルにフィー ドバックする
  60. 60. もう一度。 「システムは何で出来ているのか?」 ≒「モデルはどこから生まれるのか?」
  61. 61. 実践テスト駆動開発(GOOS)読んだ by 平鍋さん http://qiita.com/kenjihiranabe/items/b951b6d98672167347fd 受け入れテスト
  62. 62. 重要なのは? 1)全体感、目的、知識の共有 シナリオをベースにユーザ価値に着目したテス トを実施すること。このテストは自動的に繰り 返して価値提供を保証すること。 2)実装のための設計をすること モデリングとTDDで設計をスパイラルアップ させていくこと。設計の確からしさを発見した 後はテストコードは捨てる覚悟であたる。
  63. 63. モデリングとTDD • モデリングとTDDは同時進行 – モデリングは重要であるが実装やテストと合わせて 設計を行う – 検証したいのは「設計の確からしさ」である – リファクタリングされれば単体レベルのテストコー ドはゴミである – モデルが検証されれば単体レベルのテストコードは 無用である つまりTDDは設計で使用し、作成したテストコード は捨ててしまった方がいい(ことが多い)。 1. UT is not automated test 2. heavy mocking hurts architecture (from DHH says “TDD is Dead”)
  64. 64. いつ実装を開始するか • モデリングするのは「事前設計」レベル – 「直前設計」と言う方が感覚に合う – 大き過ぎるモデルは実装・テストサイクルが 遅くなる結果、学びが遅く間違える – 小さくモデリングして実装(TDD)して、 コードや実行結果からフィードバックを得る ※勿論、全体性の認識は最初にとっておかないといけない • 増田さん:パッケージ図 • かとじゅんさん:コンテキストマップ
  65. 65. Kent Beck “「学習-測定-ビルド」と呼ぶべきだと思 います。「ビルド-測定-学習」ではあり ません” from Startupプログラマの為の新アジャイルマニュフェスト qiita.com/TsuyoshiUshio@github/items/28f4c127c911170cad49 モデリング 検証 実装とテスト(TDD)
  66. 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. 67. いつ終えるのか? • やろうと思えばいくらでもこだわること ができる • 斧を研ぎすぎて、木を切る仕事を忘れ ちゃいけない(目的重要) – 三人のレンガ職人 「あなたは何をしていますか?」 モデルもコードも引き際大事
  68. 68. 最後にもう一つ質問 ユーザと話すときに“何”を伝えますか?
  69. 69. とある会話 • 引出しを作る大工の話 From デザインパターンとともに学ぶオブジェクト指向のこころ http://www.amazon.co.jp/dp/4894716844
  70. 70. 実装の話をするんじゃない! • その話は伝わらない • 伝えるのは「質」の話である
  71. 71. パタンを見出すこと http://blog-imgs-47-origin.fc2.com/i/t/o/itokaya/IMG_5160-horz.jpg
  72. 72. [入口での転換(112)]より <より大きなパタンとの結合> …どんな建物や複合建物の場合でも、すでにそ の主入口の大まかな位置は分かっている-[大 きな門口(53)]から敷地への門、[見分けやすい 入口の集まり(102)]から各建物への玄関、そし て玄関。いずれにしろ、入口は「外部」-公的世 界-からさほど公的でない内部世界への転換を つくり出す。 モデルは捨像 • この世の森羅万象は表せない • でも、「パタン」を見出すことで「木を 見ながら森を見ることができる」 – Ex) 門 http://fashionjp.net/creatorsblog/fujita/2010/08/post-89.html
  73. 73. パタン・ランゲージ重要 • パタン・ランゲージ 「あるコンテキストにおける問題の解決方法」 – パターンの名前 – パターンの目的、 すなわり解決する問題 – その達成方法 – 達成する上で考慮する必要 がある制約とフォース
  74. 74. 3. それでも解決できない問題 まとめ • 設計技法としてTDDとDDDは親和性がよ い • モデリングと実装・テストは同時に進め るべき • そこから本質を発見していく DDDとTDDで より良いモデリング!
  75. 75. 持って帰って実践してみて! より良い設計/コードの為に 明日から出来るモデリング
  76. 76. コードから学ぶ/考える • モデルだけでは見えない世界がコードか ら見えることがある • 時には実装パターンを使うことで、考え られていない事が見えてくる
  77. 77. 増田さんのスライド ドメインモデルの育て方 http://www.slideshare.net/masuda220/ss-36548248
  78. 78. オブジェクト指向エクササイズのススメ オブジェクト指向エクササイズのススメ http://www.slideshare.net/yojik/ss-1033616
  79. 79. オブジェクト指向とは • 定義は本にお任せ – そんなの手法の一つ • でも、今までやってきた10年超の経験か ら「正しいこと」にリーチできると思っ ている • 『必ずしもオブジェクト思考は銀の弾丸 じゃないが、武器は多いほうが絶対にい い』(オブジェクト指向エクササイズのススメ http://www.slideshare.net/yojik/ss-1033616 より)
  80. 80. 小さくモデリング 小さく実装&テスト
  81. 81. 最後に
  82. 82. 忘れてはいけない Context重要 モデルもモデリングも銀の弾丸ではない 戦術の一つとして用意しておいて欲しい
  83. 83. 何より大切なもの
  84. 84. 考え抜く事! Think!!深く!深く! 深く!深く!
  85. 85. 以上、ご静聴ありがとうございました
  86. 86. 次回、予告
  87. 87. アナリシスパターンが鍵となる!? (現在、現場検証中!!!) オブジェクトの広場 突撃インタビュー より https://www.ogis-ri.co.jp/otc/hiroba/specials/MartinFowler/interview.html
  88. 88. ●おわり●

×