hirapi's blog

ちゃんとしたふりをする

builderscon tokyo 2018 聴講メモ #2「開発現場で役立たせるための設計原則とパターン」by @shinpei0213さん

勉強会

（スライドもし公開されたら貼らせていただきます）

※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドか、もしくはYouTubeで公開される（？）公式動画をご覧ください。

開発現場で役立たせるための設計原則とパターン

by Shinpeim

『WEB+DB vol.91』データ構造特集がおすすめ

テーマ

  • このケースで何が最適か、どうやって判断するの？
    「適材適所」「ケースバイケース」は何ら回答になっていない

テイクホームメッセージ

  • 複数の選択肢を用意する → 問題の「変わりやすいところ」を考慮して設計原則からレビュー を繰り返す
  • 設計原則

内容めも

  • 設計・パターンは抽象的な話が多く、空中戦になりがち

    • 「抽象化」って人による
    • 「責務」って考え方による
      「システム全体に責務を持つからSystemManagerクラス作ろう」← 反論できるか？

  • そもそも設計って？
    複数の分割構造の選択肢から 選び出す こと。設計原則・デザインパターンはその武器

    • デザインパターン：カタログ
    • 設計原則：良い構造かを判断する指針
      パターンを使って分割する ⇔ 目の前に立ち上がってきた構造に対して、原則を使ってレビューする

  • 例題：掲示板ウォッチスレ 投稿通知機能

    • 「なんであかんのか」を言語化できないのであれば、それは暗黙知
      → 「センスのある人」しかできないことになる
      エンジニア足りてないって言われてるなかセンスのある人でチームを組めるのは金と知名度があるとこだけ

  • 単一責任原則
    でも「責務」ってふわっとしてる……
    あるモジュールを変更する理由が2つ以上あってはいけない
    「なんとなく駄目」だったのが「コメント通知の仕様変更でもスター通知の仕様変更でもこのクラスに変更が必要になるから、駄目」になる

  • 開放閉鎖原則
    例題：引き落としできなかったらsuspend、3回引き落としできなかったら永久追放
    新しい機能を足す時に、既存のクラスを書き換える必要がある ← 拡張に開かれていない

  • 凝集度と結合度
    凝集度は高く、結合度は低く

    • Customerに関する操作をCustomerSuspenderにやらせてしまっている
    • Customerにとって他人であるCustomerSuspenderの処理をCustomerが何度も呼ぶ必要がある

  • 「なんかオブザーバーパターンっぽくね？」ってにおいを感じる

    • CommentObseverを作ると、そいつはスターというイベントは完全スルーできる
    • パターンに従ってCommentとCommentObsercerを分けてみたけど、分ける必要はあるのか？
      そもそもオブザーバーパターンて何だっけ、から「開放閉鎖の原則」を評価軸にする
      • 今回のケース、拡張される？（コメント発生時に通知以外のイベントが足されることある？ オブザーバー足される？）
        → 結合度はOKだが、現実的な未来予測について見るとそもそも分ける必要があるのか不明
      • 今回のケース、修正に対して閉じなければならないの？（コメントの仕様が変わったとき、通知の仕様はそのままなの？）
        → むしろ凝集度がNG
    • パターンを使って構造化したとき、設計原則を使ってレビューすると「実は不適切では」ということもある

  • Commentクラスにひとまとまりにしてしまう
    単一責任原則はどうなる？ まざっているのでは？

    • コメントの仕様が変わる（→ 通知の仕様もきっと変わる）ときに、Commentクラスだけの改修で足りる
      → 単一責任原則を満たしている

  • まずは問題を見極める = どこが変わりやすいポイントか
    コメント発生時に通知以外のイベントが足されるのであれば、オブザーバーパターンでよかった。
    どこが変わりやすいポイントかがわからないと、単一責任原則で設計のレビューができない

  • 未知の問題に対する解決
    どこが変わりやすい（やわらかい）部分で、どこが変わりにくい（固い）部分なのか、まずは問題と向き合う。
    KISS原則、YAGNI原則

質疑

  • 設計原則について適用フェーズによって分けられるかも？（← あまり聞こえなかった）
    SOLIDの原則のうちSとOが今日の話だった。KISSやYAGNIもやや抽象的なもの。
    LとかDは抽象度が低く、自分で構造を考えるときに使えるかも。
  • チーム開発で、設計レビュー時には一通りコードを書いてしまっている
    前職は採用時に絞っていて、暗黙知で通っていた。
    現職では設計レビューうまくできていない。

感想

「なんかあかん」設計にデザパタ適用して、それをさらに設計原則からレビューする、ていうサイクルを実演してみせてた。
オーディエンスが例題見た時に持った「なんかあかん」をきれいに議論に落とし込んでてとてもスマート、聞いててテンションあがった。
自分のためにもチームのためにも、パターンと原則を武器として身につけねば……！
アニメと構成そろえてて、合間合間に息子さんのショットが入るの和んだw