スポンサードリンク

ギルドワークスの市谷さんが立ち上げた、TAG（アジャイルギルド）に参加しています

といいつつ、幽霊部員と化していますが・・・

システム設計の原則の勉強会の案内がありました

1月23日(水) 夜@六本木で、設計技法の勉強会やります。
内容は Refactoring 2ndと私の「現場で役立つシステム設計の原則」から。
この勉強会はThe Agile Guildという技術者の集まりの内輪のイベントです。
The Agile Guildに興味のある方は、こちらから参加できます。https://t.co/GCBvB5YWaS

— 増田 亨 (@masuda220) January 5, 2019

書物に基づく話ということですが、それは読んでないのですが
モノづくりでの疎結合・密結合のバランスや設計の意思などを
知りたくて参加です

コンセプト
good design enhances agility

変更を楽で安全にする実践技法

リファクタリング2.0
既存のコードを安全に変更できる

プログラミングが中核
設計＝プログラミング
設計＝ソースコードで行こう

変更が楽で安全であることが良い設計
成長させられるように

たくさんの要因に対してプラスに働く

ドメイン駆動設計
時間とともに硬直化していくものに対して進化するチャンス
柔軟性のある設計に近づける

４つの本の紹介
オブジェクト指向のコミュニティの設計思想がベースになっている

ビジネスルール
型指向のプログラミング
読みやすいソフトウェア
全体像 型のネットワークができる

15年の歳月
変わらない本質が明らかに
学ぶメリットがわかってきた

カプセル化、ポリモーフィズム
実装とインターフェイスは別

４０年前から言われていること
本質が実証されている これからの方向性

計算と入出力は分けよ
ソースファイルを分割せよ
名前にこだわれ
同じような分岐を重複させない
長いメソッドを書かない
グローバル変数を使うな
mutableを避けよ
カプセル化せよ
実装継承は使うな

intellij IDAとgit
リファクタリングに画期的なツール

現状への危機感
設計の常識レベルの劣化

モジュール化、カプセル化、インターフェイス

危険な理由
硬直化したモジュール
うごけばok症候群

機能分割→データモデル→ワークフロー→API駆動

動いたことがゴールではない
わかりやすく書き直すことがどれだけ効果があるかを実感

力ずくのプログラミングが横行
長ったらしいソースコード

ビジネスルールの分離
ビジネスルールを題材にしているかに注意

ソフトウェアが複雑になる理由は適用する条件による分岐のため
ピジネスルールの記述を独立させる

ビジネスルールを記述できるようになれば良い

型指向のプログラミング
型は値の種類
金額や数量などの値を独自のクラスを作る
有効な値の範囲を定義する
値の種類ごとに必要な計算、判定のロジックを特定する

ビジネスルールを記述する３要素
ファクト、ルール、ゴール
値オブジェクト
数値、時間、空間
単一型、範囲型、範囲のコレクション

メソッド
四則演算と分岐
文字列表現がマイクロサービスで必要になってくる

型を使うと安定する

契約による設計
事前条件と事後条件
暗黙のビジネスルールの明文化

区分ごとのロジックを扱う
enumに寄せて区分をリファクタリングすると効果が大きい
条件分岐を整理する

コレクションのカプセル化
ぐちゃぐちゃ感が消える

型指向のプログラミングを体得すると
ビジネスルールの単位に見えるようになる

名前をちゃんとつけることに味を占めるとやるようになる

レビュー時には型のネットワーク図と自分の感覚と比較する

質疑応答と考察

switch文に絞って重複を減らすことから始めるのがよい

チームでやるには、バグを目の前でリファクタリングで対応してしまえばいいのだが、難しい言語もある

やって見せて実感してもらうのをどうやって仕掛けていくか

整理整頓
ビジネスルールの型指向

機能化するときにビジネスルールか否かを判断した上で
ビジネスルールを型やカプセル化すれば、非常にスッキリする
分岐つついてもれなくダブりなくの状況を作る
（要件の引き出し方は、また別の話）