分かる範囲で分節していく
一見方向は違いそうだけど「抽象化」もほとんど同じ能力だと思うmrsekut.icon
分かる範囲で概念モデルを考えて、そこで一旦物理的にぶった斬る 確定的に分かる範囲から切って分けていく
その中でまた分節していく
事故らないように
いや、「事故らないように」は制限強すぎかも
どういう事故が起きるのか、どうすればカバーできるのか?を考えて「事故ってもこういう対応ができる」としておいたほうが良い
「事故らないように」を意識しすぎて行動に繋がらなかったら意味ない
分節の正しさのフィードバックはできるだけ速く欲しい
その観点でもFigmaを使うことの意義はありそう
さっさと分断し、間違いをさっさと直せる
ER図やFigmaや型がそのへんの役割を買っているメジャーな仕組みと言えそう
やっぱ詳細なプログラミング実装は具体的すぎて遅い
ただ、Ui上の分節とプログラム内の分節は必ずしも一致しないことには注意が必要そう
でもコンセプトという観点では同一視できるかもしれない これ、「小さく作りすぎない」と言ってるようにも見えるmrsekut.icon
ちょっと違う
早期の理解の浅い状態で分節するぐらいならしない方が良い、ということか(?)
プログラマはあらゆるコーナーケースを把握してすべてカバーする、という使命がある
普通に考えたらトップダウンにやるべき
だが、それはそもそも難しい
その列挙がそもそも漏れている(仕様漏れ)
論理の詰めの甘さ、コーナーケースの見落とし
時間が無限にあっても気付け無い場合がある
列挙したけど統一的な解決法がなかった(?)
A,B,Cは統一的に解決できそうだが、Dは特化実装が必要、みたいな
どの抽象度で確度の高い分節の判断ができるかという話な気がする
結局、トップダウンでも良いし、ボトムアップでも良い
とにかくある程度の革新を持てる範囲でぶった斬る
あとはその閉じた世界の中だけのことを考える
UIの実装をしてる時にEntityがどうなってるかどうでも良いし、Entityの実装をしてる時にDBスキーマがどうなってるかとかどうでもいい
大事なのは境界ぐらい
interfaceとも言う
直観に沿うものもあれば沿わないものもある
Monadというたった2つのmethodからなる単純な構造が「理解が難しい」と言われる
命名する作業と、分節する作業、エンジニアのもっともだいじなしごとmrsekut.icon
でもプログラミングの文脈での「命名」はちょっと意味が違いそう
良い名前を付けるというか、最も適切な語彙を検索する作業っぽいので
UIを考えるときも同じ
最初から確定できるものから分節していく
曖昧なもの可能性のあるものは放置しておく
ピンときた時に実装する
top-downに考えたくなるのは、「眼の前に存在するこれらの問題を統一的に解決する策を考えよう」となるから
それで小さく作ることに失敗し、責務の大きいものが出来上がってしまう bottom-upでやっていく場合は、
問題A,B,Cを順に狭いスコープで解いていくことになる
その時に、AでできたアプローチがBには適用できないという状況になる
(もちろん前者のアプローチの筋が良ければ自然に適用できる)
別々のものとして作ることもできるし、そこから統一的な方法を編み出すこともできる
後者の場合は、(悪く言えば)作り直す手間が生じる
だが、これも前進か
というか、最初からtop-downにやろうとしてるのは自信過剰な気もしてきたmrsekut.icon
お前の頭ではいったん問題を切り分けて、狭いスコープで解決するものを作らねえとダメなんだよ、みたいな
そんなこと無いか
問題1,2,3,4,..を順にやってれば流石に気付けるか
概念モデルにもまだまだレイヤーがありそう
名詞単位の切り出しもあるし、
動詞としての切り出しもある
add操作と、remove操作は明らかに別の概念。分節されている
これのことを「概念モデル」と呼んで良いのかはちょっと怪しいmrsekut.icon