ソフトウェア設計のすすめ

1. ソフトウェア設計のすゝめ株式会社ドワンゴ吉村総一郎 (@sifue)

2. ソフトウェア設計をなぜするのか？

3. そもそも設計って必要なの？

4. プロトタイピングしながら作っていくなら必要ないんじゃないの？

5. そうじゃない場合もある

6. 例えばどんな時か複雑な要件を扱わなくてはならない時考慮の抜け漏れのしやい複雑な業務用件無停止メンテナンスなどの運用耐障害性拡張性多くのシステムと連携

7. 複雑な要件を持つシステムは、建築物で言えば高層ビルのようなもの膨大な建築法電気ガス空調間取りの使い勝手 (トイレの数？)

8. 複雑な要件の考慮が抜けている場合には大きなコストを払うことになることもある

9. 犬小屋をプロトタイピングで作ってそれを拡張、改修し続ければ高層ビルになるか？

10. ならない当初犬小屋で良かったものが要求の変更で高層ビルが求められる悲劇がそこにはあるが...

11. できるのはハウルの動く城

12. 致命的な問題にぶち当たれば作り直しが必要ある日突然考慮漏れの要件にぶち当たってシステム停止に陥ることも

13. 　ただ逆に要件の衝突が起こらないようなシンプルな要件のプロダクトならプロトタイピングを利用したインクリメントな開発はかなり有効

14. とはいえ複雑そうなものは設計を考えよう

15. でも突然ソフトウェア設計しろと言われても何をするかよくわからない…

16. そんな方におすすめの第一歩

17. 図を書いてみよう

18. 図といっても書き方がわからない…

19. そんなあなたにおすすめの記法

20. UML

21. UMLとは統一モデリング言語 (Unified Modeling Language)という、1997年に選定された世界的に利用できるソフトウェアのための設計図の書き方現在は、UML 2.4.1が最新であり、13種類の図の書き方を利用することができる

22. UMLがない場合の図はどんな感じか？

23. 家計簿アプリの設計の例変動費月次集計サービス支出固定費実は同じものを表しているのに、記法が違うために四角がどういう意味で、丸がどういう意味でとか、緑の線があれで、青い線があれとかを毎回説明しなくてはいけない

24. つらい設計レビューをする前に全員が図の記法を理解するところから始まる。設計レビューに途中からやってきた人が図の記法がわからない...。新たにjoinしたメンバーも資料を見て意味がわからない。

25. UMLはそういう問題を解決してくれます！

26. どんな図があるのか？よく使うだろう5つを紹介ユースケース図: 要件の構造を表現コンポーネント図: システム構成を表現パッケージ図: パッケージの構成を表現クラス図: クラスの関連を表現アクティビティ図: フローチャートのようなもの

27. 家計簿アプリの設計ユースケース図

28. 家計簿アプリの設計コンポーネント図

29. 家計簿アプリの設計パッケージ図

30. 家計簿アプリの設計クラス図

31. 家計簿アプリの設計アクティビティ図

32. こんなふうに記述できます

33. 図はわかってけど何で書けば良いの？

34. おすすめのUMLモデリングツール Gliffy Astah Community PlantUML

35. Gliffy Confluenceのプラグイン結構きれい図が大きくなると重い制約が緩めでUML以外の記法もできるクラス図の例

36. Astah Community MacとWinで動くJava製のデスクトップアプリページに添付すると Confluenceで図を表示もできる UMLに違反してる図は書きにくいクラス図の例

37. PlantUML テキストベースでUML書ける(<|-- が継承とか) 最近流行ってる Confluenceでも記述可能 GUIのサポートないので UMLの仕様を知っている必要があるクラス図の例

38. 以上紹介したツールを使ってソフトウェアの設計や設計レビューをやっていきましょう！

39. おすすめ本 UMLの本というより総合的なソフトウェア開発の本

40. 設計のやり方はわかったけど、具体的に何するの？

41. 設計の目的って何？

42. 設計とは、要求に対して、狙った要件を設定できるようにすること。正解はない。

43. よく出てくる設計ノウハウシステム構成をレイヤー化する/しないモジュール化する/しないモジュールをレイヤー化する/しない SOLID原則を守る/守らない

44. システム構成をレイヤー化する/しない多層アーキテクチャレイヤごとは疎結合にする右は3層+LBの例レイヤ毎に再起動更新できるレイヤごとで台数を増やし負荷をコントロールできるレイヤが増えると管理コストは増える

45. モジュール化する/しない汎用サブモジュールをくくり出せ、重複が減って保守コストが下がるモジュールごとで人を割り当てるので更新衝突が少なくなるモジュール化することで開発コストは増える

46. モジュールをレイヤー化する/しない DDDのレイヤー化アーキテクチャの例ビジネスロジック(domain層) がapplication層やui層のフレームワークのVerUP等の変更をうけない依存関係の強制を守るために依存関係の逆転則とかを使わなくてはいけないなど高コスト

47. SOLID原則を守る/守らない以下は、コストと再利用性のトレードオフとなる単一責務の原則: いろいろやるクラスを作らないオープンクローズドの原則: 状態の変更からは守り、クラスの自体の拡張を提供するリスコフの置換原則: 継承は意味として親と子の交換可能であるようなクラス設計にする依存関係逆転の原則: インターフェースを使ってレイヤ間の依存関係を一方向にするインターフェースの分離の原則: 内部実装を隠ぺいする

48. 依存関係逆転の原則の例インターフェースを作ってそれを依存先で実装する

49. 適切な設計の目的を果たすための色々なパターンがあるのでぜひ探してみてくださいマーチン・ファウラーのリファクタリング GoFのデザインパターン PoEAA エリック・エヴァンスのドメイン駆動設計 Lean architecture Microservices

50. 要件漏れ/衝突が起こらないよう、開発者の狙い通りに開発していけるようしっかりレビューしながら考えていきましょう！

51. 以上ご清聴ありがとうございました

SlideShare for iOS

ソフトウェア設計のすすめ

by Yoshimura Soichiro , Software Engineer at 株式会社ドワンゴ

on Oct 27, 2014

Statistics

Views

Actions

1 Embed 21

Accessibility

Categories

Upload Details

Usage Rights

Report content

ソフトウェア設計のすすめ Presentation Transcript