分かる範囲で分節していく

確定的に分かる範囲から切って分けていく

その中でまた分節していく

事故らないように

いや、「事故らないように」は制限強すぎかも

どういう事故が起きるのか、どうすればカバーできるのか？を考えて「事故ってもこういう対応ができる」としておいたほうが良い

「事故らないように」を意識しすぎて行動に繋がらなかったら意味ない

分節の正しさのフィードバックはできるだけ速く欲しい

その観点でもFigmaを使うことの意義はありそう

さっさと分断し、間違いをさっさと直せる

ER図やFigmaや型がそのへんの役割を買っているメジャーな仕組みと言えそう

やっぱ詳細なプログラミング実装は具体的すぎて遅い

ただ、Ui上の分節とプログラム内の分節は必ずしも一致しないことには注意が必要そう

ちょっと違う

早期の理解の浅い状態で分節するぐらいならしない方が良い、ということか(?)

プログラマはあらゆるコーナーケースを把握してすべてカバーする、という使命がある

普通に考えたらトップダウンにやるべき

だが、それはそもそも難しい

その列挙がそもそも漏れている(仕様漏れ)

論理の詰めの甘さ、コーナーケースの見落とし

時間が無限にあっても気付け無い場合がある

列挙したけど統一的な解決法がなかった(?)

A,B,Cは統一的に解決できそうだが、Dは特化実装が必要、みたいな

どの抽象度で確度の高い分節の判断ができるかという話な気がする

結局、トップダウンでも良いし、ボトムアップでも良い

とにかくある程度の革新を持てる範囲でぶった斬る

あとはその閉じた世界の中だけのことを考える

UIの実装をしてる時にEntityがどうなってるかどうでも良いし、Entityの実装をしてる時にDBスキーマがどうなってるかとかどうでもいい

大事なのは境界ぐらい

interfaceとも言う

直観に沿うものもあれば沿わないものもある

Monadというたった2つのmethodからなる単純な構造が「理解が難しい」と言われる

でもプログラミングの文脈での「命名」はちょっと意味が違いそう

良い名前を付けるというか、最も適切な語彙を検索する作業っぽいので

UIを考えるときも同じ

最初から確定できるものから分節していく

曖昧なもの可能性のあるものは放置しておく

ピンときた時に実装する

top-downに考えたくなるのは、「眼の前に存在するこれらの問題を統一的に解決する策を考えよう」となるから

bottom-upでやっていく場合は、

問題A,B,Cを順に狭いスコープで解いていくことになる

その時に、AでできたアプローチがBには適用できないという状況になる

(もちろん前者のアプローチの筋が良ければ自然に適用できる)

別々のものとして作ることもできるし、そこから統一的な方法を編み出すこともできる

後者の場合は、(悪く言えば)作り直す手間が生じる

だが、これも前進か

お前の頭ではいったん問題を切り分けて、狭いスコープで解決するものを作らねえとダメなんだよ、みたいな

そんなこと無いか

問題1,2,3,4,..を順にやってれば流石に気付けるか

概念モデルにもまだまだレイヤーがありそう

名詞単位の切り出しもあるし、

動詞としての切り出しもある

add操作と、remove操作は明らかに別の概念。分節されている