プロダクションコードの設計とテスト駆動開発入門

Slide 1

Slide 1 text

プロダクションコードの設計とテスト駆動開発入門関西情報系学生団体交流会2022 ワンダープラネット株式会社吉谷幹人

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

© WonderPlanet Inc. 会社名ワンダープラネット株式会社所在地名古屋本社／愛知県名古屋市中区錦3-23-18 ニューサカエビル5F 東京オフィス／東京都品川区東五反田5-23-7 五反田不二越ビル事業内容エンターテインメントサービス事業設立 2012年9月3日（ 10月1日創業）代表者代表取締役社長CEO　常川友樹従業員 204名（2022年2月末時点） HP https://wonderpla.net/ 上場市場東京証券取引所グロース（証券コード：4199）私たちは名古屋グランパスを応援しています会社概要 4

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

チーム開発と設計プロセス

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

© WonderPlanet Inc. クラス図(基本的な読み方) Book + name : string # number : int - List : pages Page + title : string + body : string + getPages(int index) : Page 可視性 +: public # : protected - : private 関連（矢印なし/あり） BookはPageを知っている（利用してる） BookService 依存 BookからBookServiceを呼び出す状態や変更がBookに影響する

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

© WonderPlanet Inc. UMLの実際の利用方法 • 最近では簡単にかける（GithubやVSCodeのプラグインなど） • PlantUML / Mermaid ```mermaid classDiagram class Book { + string name # int number - List pages + Page getPages(int index) } class Page { + string title + string body } Book --> Page Book ..> BookService ```

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

ソフトウェアアーキテクチャの重要性

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

© WonderPlanet Inc. アーキテクチャ・設計パターン • いくつかのパターンが存在 • MVC（Model/View/Controller） • MVVM（Model/View/View Model） • MVP（Model/View/Presenter） • etc… • これらパターンを取り込んだフレームワークもある • ex • MVC: Rails, Laravel… • MVVM: Vue.js… • 一から大方針を考えず、素早く機能を作ることができる

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

設計におけるポイント

Slide 38

Slide 38 text

Slide 39

Slide 39 text

© WonderPlanet Inc. SOLID原則 Single Responsibility Principle（単一責務の原則） • クラスを変更する理由は１つでなければならない Open/closed principle（開放閉鎖の原則） • クラスは拡張に対して開き、修正に対して閉じていなければならない Liskov substitution principle（リスコフの置換原則） • 派生型はその基本型と置換可能でなければならない Interface segregation principle（インターフェース分離の原則） • クライアントが利用しないメソッドへの依存を強制してはならない Dependency inversion principle（依存性逆転の原則） • 上位のモジュールは下位のモジュールに依存してはならない。 • どちらのモジュールも「抽象」に依存すべきである。

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

© WonderPlanet Inc. 1.ロジックやクラスは分割しよう • 責務の範囲を定義してグループ（レイヤー）を分ける • 多くのこと全部やるクラスやメソッドをつくらない • 特に見た目部分とCoreロジック CUI Presenter Model GUI Presenter main Coreロジック Algorithm data Viewロジック Web Presenter run output コーディング時に純粋なロジック部分に集中できる最初は簡単な実装で表示にして、後からいくらでもリッチ化できる

Slide 43

Slide 43 text

© WonderPlanet Inc. 2.インターフェースを定義・もしくは意識しよう • インターフェースを実装前に考える • 複数人で問題なく作業できる • いらないメソッドやプロパティは定義しないこと • 拡張ができるようになる • 言語仕様になくても意識する CUIPresenter: IPresenter + Render(Data data) GUIPresenter : IPresenter + Render(Data data) data IPresenter<> + Render(Data data) 最初にインターフェースを設計したおかげて、後から誰でもPresenterを作れるようになった！＊必要なところに定義。無意味に全クラス定義する必要はない

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

異常系、運用、リファクタリングそしてテスト

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Slide 57

Slide 57 text

© WonderPlanet Inc. UnitTest • テストしたい対象と対になるようにコードを作成 • 対象を呼び出して戻り値や振る舞いをチェックする • テストコードもプロジェクトの資産としてメンテする • リポジトリで管理する（デプロイはしない） + bool isPrime(int num) （素数の判定機） num = 3 true num = 6 false OK! OK! PrimeServiceTest PrimeService

Slide 58

Slide 58 text

Slide 59

Slide 59 text

Slide 60

Slide 60 text

Slide 61

Slide 61 text

テストファーストとテスト駆動開発

Slide 62

Slide 62 text

Slide 63

Slide 63 text

Slide 64

Slide 64 text

Slide 65

Slide 65 text

Slide 66

Slide 66 text

Slide 67

Slide 67 text

Slide 68

Slide 68 text

Slide 69

Slide 69 text

© WonderPlanet Inc. ビヘイビア駆動開発 (Behavior Driven Development: BDD) • TDDから、よりテストの目的を達成するためのアプローチ盛り込んで発展させたもの • システム全体のコンポーネントがどのように「振舞うべき」かというところに着目しつつテストを構成していく • より自然言語に近いような記述方法でテストを仕様書のように扱う GIVEN：前提・初期コンテキスト WHEN：シナリオをトリガーする条件 THEN：期待される結果

Slide 70

Slide 70 text

© WonderPlanet Inc. TDD/BDD実践 : FizzBuzz 以下のようなFizzBuzzクラスを実装せよ。 • 要件1: 引数が3の倍数の時は"fizz"を返却する。 • 要件2: 引数が5の倍数の時は"buzz"を返却する。 • 要件3: 引数が3と5の公倍数の時には"fizzbuzz"を返却する。 • 要件4: それ以外のときは、引数の数字をそのまま文字列にしたものを返却する

Slide 71

Slide 71 text

Slide 72

Slide 72 text

Slide 73

Slide 73 text

テストと設計とアーキテクチャの関係性

Slide 74

Slide 74 text

Slide 75

Slide 75 text

© WonderPlanet Inc. テスト前提でアーキテクチャや設計を考える必要がある • 疎結合になっている • 必要なクラスが少なく、テストの下準備が圧倒的に楽 • 逆に密結合だとUnitTestは不可能に近い • 重要なロジックが切り出されている • フレームワークに依存しない • 純粋関数になっている • 複雑なビューはテストしないという方針もありうる • インターフェースが考慮されている • テストのために仮のデータを渡したり、モックできる

Slide 76

Slide 76 text

Slide 77

Slide 77 text

まとめ

Slide 78

Slide 78 text

© WonderPlanet Inc. まとめ • プロダクション開発で気にするべきとろを解説 • 設計をしてチームで認識を揃える • よいアーキテクチャ・設計は劇的に開発効率をあげる • 設計で気を付ける最初のポイント3つ • UnitTest・テストファースト・TDDの紹介 • 小さいコードでも有効、実装が確実にすすむ • 大きいプロジェクトでは、テストをするためにまずアーキテクチャやテスト戦略を練るべし