Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

設計してますか?

2,454 views

Published on

社内LT的なのの資料

  • Be the first to comment

設計してますか?

  1. 1. 設計してますか? 僕が普段頭の整理の指針にしていることの話
  2. 2. 思い通りにいかないことばかりの世の中 みなさま いかがお過ごしでしょうか?
  3. 3. 丹念に積み上げたロジック
  4. 4. 丁寧に時間をかけたデバッグ
  5. 5. からの
  6. 6. _人人人人人人_ > 仕様変更 <  ̄Y^Y^Y^Y^Y ̄
  7. 7. そんな現実に少しでも抗うため 僕が普段していることの内 コードの設計に関することを ざっくりしゃべるだけのプレゼンです
  8. 8. frame of mind 心がまえ編
  9. 9. 心がまえ編  とりあえず実装は忘れよう  概念としての名前  「出来るか」よりも「すべきか」どうか
  10. 10. 心がまえ編 – 実装はあとまわし  仕様変更は概ね人間の感覚の先にしか無い  カート機能に動画共有機能は多分追加されない  哲学、概念、ポリシーの把握、洞察が大事  仕様の実装法より先に行間を洞察する  仕様の背景、既存機能との関連の仕方とか  サービスの在り方とか  洞察したら確認して共通認識に落とし込みま しょう
  11. 11. 心がまえ編 – 名前大事  実装ではなく概念から名前を切り出す  機能を日本語でそらんじる  “カートに商品を入れて、カートの中の商品を購入する機能”  “送料無料なら送料は¥0にする”  日本語の中から出てきた言葉、関係性を拾う  “カート”, ”商品”, “購入”, “送料”  コードには概念の名前を使う  ×if( !(isValidItemCountAndAmount()) ) { amount += 525; }  ○ if( ! isFreeShipping() ) { amount += shipping; }
  12. 12. 心がまえ編 – サボらない  既存システムに機能を追加する  このクラスに追加すれば出来る  そのクラスに追加すべきかどうなのか?  クラスが表している概念に沿う  クラスの表す概念外の機能追加は早晩破綻する  「だって適切なクラスがないから」  概念の切り出しに失敗しているかも?  モデリングを見直すチャンスかも?  サボらない!
  13. 13. practice 実践編
  14. 14. 実践編  MVC2とか言われているやつ  Controller  入力を受け取ってmodelとかviewを操作する  View  UIとか  Model  テーブルごとにひとつあるやつ。Daoとか ActiveRecordみたいな  Modelで取ってきたデータをContorollerで ごにょごにょしてViewに渡す
  15. 15. 実践編  MVC2とか言われているやつ  Controller  入力を受け取ってmodelとかviewを操作する  View  UIとか  Model  テーブルごとにひとつあるやつ。Daoとか ActiveRecordみたいな  Modelで取ってきたデータをContorollerで ごにょごにょしてViewに渡す
  16. 16. 実践編  Controller  入力を受け取ってModelを呼び出す  ModelとViewとの橋渡し  View  UIとか  Model  それ以外全部
  17. 17. 実践編  Controller  入力を受け取ってmodelを呼び出す  ModelとViewとの橋渡し  View  UIとか  Model  それ以外全部
  18. 18. 実践編  Controllerが太るといろいろ辛い  テストしづらい  ロジックの再利用性が死ぬ  Modelだって太ると辛くね?  Modelを一枚岩だと考えるからそうなる  層と概念に分けて関心事を小さく保つ
  19. 19. 実践編  概念で分ける 顧客 購入 在庫 商品
  20. 20. 実践編  層で分ける 顧客 購入 在庫 商品サービス層 ロジック層 インフラ層 サービス層 ロジック層 インフラ層 サービス層 ロジック層 インフラ層 サービス層 ロジック層 インフラ層
  21. 21. 実践編  概念で分ける  同じような概念で分ける  似たような概念を取り扱うモデルが集まる  関心ごとの凝縮率が高くなる  層で分ける  ロジックの本質だけに注目したい  本質以外は分離したい  呼び出しとか  DBアクセスとか
  22. 22. 実践編  ありがちなの  User user = User.findById(1); user.setAge(100); user.save();  Userクラスは顧客という概念を表す  Userの検索方法(findById)とかUserの永続化方 法(save)とかは顧客という概念の範疇じゃない  Userクラスは顧客という概念のみに着目したい
  23. 23. 実践編  こっちのが好き  User user = userRepository.findById(1); user.modifyAge(100); userRepository.save(user);  顧客の保存場所から該当顧客を検索し  年齢を変更した後  保存場所へ再度保存する
  24. 24. 実践編  顧客クラスは自分の事だけに集中できる  検索方法や  保存方法  あるいはデータストアが何であるかさえ  関心を持たなくていい  (Repositoryクラスがうまいことやってくれる)
  25. 25. 実践編  更にこれをサービスでラップする  class UserModificationService { void modifyAge(final int age) { (略) } }  いわゆるファサード  Controllerはサービスを呼び出すだけ
  26. 26. 実践編  まとめると  顧客カテゴリ  サービス層  UserModificationServiceクラス  ロジック層  Userクラス  インフラ層  UserRepositoryクラス  こんな感じの世界観をModel層の中にたく さん作っていく
  27. 27. エンティティクラスとか 値クラスとかは 長くなるので割愛 (性質で分ける、とかになるのかな)
  28. 28. Conclusion まとめ
  29. 29. まとめ  設計、やってますか?  現実と戦うための  現実世界を整理するための考え方  仕様の背景にある世界を洞察しよう  システムは現実の延長線上にある  概念の名前をコードに取り入れ、表現する  早い段階で実装の詳細に着目しすぎない  関心事を小さく保つ  着目したいものだけに着目するため
  30. 30. まとめ とか偉そうに言いながら 設計ミスって アバーッ! ってなるパターンがほとんどですけどね (大体洞察が足りないかサボったか)
  31. 31. おわり

×