Split a huge class

Transcript

1. Nobukatsu Furuhashi 巨大クラスをどう分解するか
2. 自己紹介 • @furuhashin • 趣味 • 顕微鏡 • 乾麺の十割そばで蕎麦湯を抽出
3. なぜ分解するのか？
4. なるべく変更を局所化したいから
5. 高凝集、疎結合
6. システムを変更しやすく、シンプ ルに保つ
7. ではどのように分解するのがいい のか？
8. • 上から100行ずつ分解する • 名前順で10個の関数ずつ分解する • CRUDで分解する • 画面ごとに分解する • テーブルごとに分解する • 関心事で分解する • 役割で分解する • etc
9. 分解方法は無数にある
10. とりあえず既存関数を分類してみ た
11. バリエーションが少しずつ見えて くる
12. 同時に歴史(時間軸)というものも 見えてくる
13. 同時期に作られた関数達は関連が あるっぽいってやつ
14. 話は変わるが・・・
15. そもそも変更はなぜ起こるのか？
16. ビジネスを加速させるため
17. ではどのような軸で変更が発生す るのか？
18. • 物件の画像を複数登録したい • 不動産会社の情報を詳細に登録したい • 不動産会社の担当者が退職した際に引 き継げるようにしたい • 自動配信の文言を修正したい • 物件の重複チェックをしたい • 物件の公開期限を変更したい • 不動産会社の月間レポートを表示した い • 不動産会社の担当者で代理ログインし たい • 希望条件で物件を検索したい • 自動配信が重複しないようにしたい • 物件のマイソクのデザインを変更した い
19. 変更が起こりやすいビジネス上の 概念に気づく
20. ただ全部が全部変更されやすいわ けではないので・・
21. 分解して変更の局所化をする
22. また、変更が起こりやすい概念の バリエーションが存在する
23. 物件という概念を１つ取って も・・
24. 公開物件、非公開物件、公開期限切れ 物件、削除物件、おすすめ物件、重複 物件、掲載保留物件、配信対象物件
25. 何をどうまとめるか、粒度の選択 が発生する
26. ビジネスサイドと会話する機会を 作ること
27. どんな単語を使っているか？何を 気にしているのか？
28. 変更の予兆をキャッチすること
29. ユビキタス言語を作成する
30. 開発者、ビジネスサイドの概念の 意味を揃える
31. 開発者「非公開物件、公開期限切れ物件も結局公開しないか ら同じものなのでしょうか？」 ビジネスサイド「いいえ、両者は別概念です」 開発者「なるほど」
32. 現在使用している関数群、 変更が起きやすいビジネス上の重要概念、 変更の予兆 これらを総合的に見て分解の基準を考える
33. 大切なのはイテレーション
34. 失敗したらすぐ戻せるように すこしづつ変化に対応
35. いきなり完成はしないし、完成す ることもない
36. 永遠にバランスを取り続けるだけ
37. おわり