概念モデリング
まずこの2パターンで方針を変えられそう
満たすべき仕様が網羅されている
例えば、ビジネス上に存在している複雑な価格表をコードに落とすとか
ただ、この中にも、今後も絶対に変わらないものだったり、仕様追加がある場合とあるだろう
その際に、仕様の意図のようなものを汲み取り、それを表現することで変更に強いものになる
まあこれは↓でも同様に大事か
満たすべき仕様が網羅されていない
演繹的に探す
同じ題材に対しても色々トレードオフはあるだろう
静的に最も厳密に定義することだったり、
厳格になっていても、コード上では扱いづらい、というのもありうる
その要件に最適(具体的)な表現をすればコード量が最小になるだろうし、
根本的に変えないといけない構造と、あとから表層の修正だけでどうにかなりそうな構造もあるし
「分岐によってpropertyの有無が変わる」 > 「string配列の選択肢の規定」とか
数学的に、論理学的に、汎用的な行動を組み合わして表現することは寄与するだろう
プログラミングにおける概念モデリングの場合は特に
いくつかのフェーズがありそう
まず、概念を、適切に(頭の中で)概念モデリングし、
ここが本当に大事
ここを言語化して再現可能にしたいmrsekut.icon
良い感じのツールを使って、構造化し、
e.g. 論理式、数学的ななにか、なにか
良い感じのツールを使って、表現(具体化)する
e.g. 表、型、コード、自然言語、なにか
そしてこの表現自体がまた別の目的に対する「ツール」となる
以前、ストリング図とか何がそんなすごいん、とを思ってたが、まさにこの辺の観点での良さの話だろうmrsekut.icon 数学の分野でもっと基本的なものでなにかあったよな、なんだっけmrsekut.icon
「分数の表記法」ぐらい基本的なものでなんかあった気がする
分数という概念を、横線の上下に数字を置く表現をすることで使いやすくなっている、みたいな