Upgrade to Pro — share decks privately, control downloads, hide ads and more …

社内勉強会でOOPとCleanArchitectureとDDDを勉強し始めたというお話

Sponsored · SiteGround - Reliable hosting with speed, security, and support you can count on.

 社内勉強会でOOPとCleanArchitectureとDDDを勉強し始めたというお話

BASE, Inc. で社内勉強会を開くときに考えた、僕らの学習アプローチと勉強会設計について話しました。

Avatar for Satoshi Kawashima

Satoshi Kawashima

October 12, 2019
Tweet

More Decks by Satoshi Kawashima

Other Decks in Technology

Transcript

  1. © - BASE, Inc. これは何? • 社内で勉強会とか始めた話 • 何持ち帰れるの? •

    弊社のOOP/CleanArchitecture/DDDに対する学習アプローチ と勉強会を設計について考えたことを共有 • OOP/CleanArchitecture/DDDそのものについては話しません • 開催して間もないため結果などはほとんど話せません
  2. © - BASE, Inc. オブジェクト指向設計実践ガイド • 単⼀責任のクラスを設計する • 依存関係を管理する •

    柔軟なインターフェースを作る • ダックタイピングでコストを削減する • 継承によって振る舞いを獲得する • その他
  3. © - BASE, Inc. たくさんのものに繋がっている CleanArchitecture XP TDD パタン‧ランゲージ DDD

    デザインパターン OOP リファクタリング マイクロサービス
  4. © - BASE, Inc. ⼈がたくさん集まると、知識も集まる • ⼀⼈ひとりが部分領域をカバーしあえば、全体としてある程 度の網羅率が獲得できる • 完璧でなくて良い

    • OOPだけでは語れない現実の開発を、語れるだけの知識を ⽤いて具体的な開発を1回やってみるという内容なので、広く て薄い感じで良い • 輪読会してから実践だといつ終わるか分からない
  5. © - BASE, Inc. • 給与システムのケーススタディ • システム開発の例題として、給与システムの要件と ユースケースが書かれている章 •

    本当はその後の章でデザインパターンを使って実装 するための題材 • 要件定義やらユースケース分析などをスキップして いきなり開発をスタートできそうだった
  6. © - BASE, Inc. 要件(というかユーザストーリー) • 従業員の⼀部は時給である。彼らの給与は、従業員レコードが持つフィールド項⽬の ⼀つに登録されている時給をベースに⽀払われる。給与は毎週⾦曜⽇に⽀払われる。 • 従業員の⼀部は固定給である。彼らの給与は⽉末に⽀払われる。⽉給の額は、従業員

    レコードのフィールド項⽬の⼀つである。 • 固定給の従業員の⼀部は、営業成績に応じて成功報酬を受ける。彼らは、売上⽇と 売上⾦額を記録したレシートを提出しなければならない。成功報酬額は、彼らの従業 員レコードのフィールド項⽬の⼀つに登録されている。彼らの給与は隔週⾦曜⽇に⽀ 払われる。 • ………(続く)
  7. © - BASE, Inc. ユースケース • 新しい従業員を追加する • 従業員を削除する •

    タイムカードの処理を要請する • 売上レシートの処理を要請する • 組合サービス料の処理を要請する • 従業員レコードの詳細を変更する(例:時給や組合費) • 当⽇の給与⽀払い処理を⾛らせる
  8. © - BASE, Inc. 参加者のロール • タイピストの役割 • モブがしてくれと頼んだことを理解すること •

    モブを信頼し、⾃分では試さないことも試す • モブの役割 • 問題解決につながる論理的ステップを⾒つける⼒になること • モブ全体の理解の⽔準を上げるため貢献すること
  9. © - BASE, Inc. 曖昧で点と点でしか無い理解 Specificationύλʔϯ υϝΠϯϞσϧ Entity ValueObject ڥք͚ͮΒΕͨ

    ίϯςΩετ ⾔語化出来ない ⾔語化出来る Repositoryύλʔϯ ϢϏΩλεݴޠ
  10. © - BASE, Inc. ⾔語化し、⼈に教える • ⼈に教えることで⾔語化が強制される • ⾔語化によって以下の効果が期待できる •

    ⾃分の知識を体系的に整理 • ⾜りなかった知識の発⾒ • 他の⼈からフィードバックがもらえる =>より深い理解へ
  11. © - BASE, Inc. 教えられた⼈は • おそらく⾔語化されてもそんなに理解できない • 書籍だけでも難しい概念なので •

    しかし⽬の前には具象となるコードもあるので、コードと のセットによってある程度の理解が出来る • @nrslibさんのボトムアップDDDに近いアプローチ • 本を読んでなくてもこれまでの⾃分の経験と整合性のある 知識に出会えると感動する(かも)
  12. © - BASE, Inc. 参加者の感想 メンバーと共通の⾔語や知識ができたのでよかったです。 ずっとひとりでやっていたので、学ぶ過程で得られる知識の多さや、 気付きの多さに感動しています。 ⾃分の知識を伝えたり、伝えることで、知識が深まったりしてよいです。 参加者各⼈の⾔語化をフックに、⾃分の中で違う概念とつながり、「あっということはあれはこ

    う考えられるのでは」という思考の深みを掘り下げる機会になりました。 ⾔語化した結果を踏まえて、実際のコードベース内でOOPを実践しました。CakePHP の中でや るのはそれなりにフレームワークといかに付き合う必要があるかという考えを深めるきっかけに もなりよかったです ひとの操作を⾒るのはおもろい 仕事でアプリケーション開発したことがほとんどないので、ドメインモデリングみたいなことを 考えたことがそもそもないな みんなの⾔語化能⼒が⾼い ※SRE
  13. © - BASE, Inc. モブプロ駆動学習(造語) • みんなで同じコードに向き合う • コードが問題に衝突するたび書籍の知識を使⽤し、 参加者の学習のサイクルが回る

    • 先⾏者は⾔語化とコーディングによるモデル検証 • それ以外の⼈はコードとセットになった情報収集と モデル化が促進される
  14. © - BASE, Inc. 課題 • 参加者が互いに信頼してないと成⽴しない(重要) • 曖昧な知識のまま実践している、という前提でやって いるのでお互い技術的な弱みを⾒せあっている状態

    • ⼈の気持ちや状況を汲み取らない⼈が仮に1⼈いるとし たら、それだけ全てが根本から崩壊してしまう • 今はいません