設計するとは、何を諦めるかを決めること - 理念と共に、最も困難で狂気の選択を考え続けて諦めない

先日、Twitter(X)で、設計書に「ボタンを押下したときに処理する」と書かれていたため、実装者がボタンを押し込んだ瞬間に処理を実行する実装を行い、非常に大変な思いをした、という趣旨の話を見た。 ここでは個別の投稿の是非には触れず、この話をきっかけに、私が設計について考えていることを書く。 私は、実装方法によって守られる性質が変わるのであれば、その選択は単なる実装詳細ではなく、設計時点でレビューできる形にするべきだと考えている。 例えば、次のような実装がある。 button.addEventListener("mousedown", execute); 一方で、「ボタンを押したとき」という表現から、クリック操作が成立した時点での実行を想像する人もいるだろう。 button.addEventListener("click", execute); この二つは似ているが、振る舞いは異なる。 m

[bootJP]

書きました、私が設計について考えていることをまとめました

[simplememofast]

Design Docに『諦めたこと』を1行足したら、レビューの差し戻しが減った。守る性質より、捨てた選択肢を書く方が認識は揃うのでは？

[chaoschk]

これは「隠れた要求仕様」。でも発注側は、実装技術の網羅的な把握は難しく、開発側は「暗黙の非機能要求」を察して設計仕様化が必要。揉めた事あり。要求と要件定義で聞き出す必要あり。自社サービスでも。

[jassmaz]

「戦略とはしないことを決めること」と経営学者の楠健教授が指摘している。戦略と設計は似ている。

[kawasin73]

design doc というよりは仕様書なきがする

[bellonieta]

ソースコードのコメントにはWhy Notを書く、って話と似てる

[Rikerike]

線引きしないとコストやらが掛かるからね……

[yarumato]

“設計時点で「押し込んだ瞬間に処理を始める」と決めているのであれば、設計書にもそう書くべきだ。クリック操作の成立を待つならそう書く。どちらの振る舞いにすべきか考えていなかったなら設計の詰めが甘い。”

[chintaro3]

客が素人だともめがちな所

[nguyen-oi]

mousedownとclickの例が超分かりやすい。何を諦めるかのトレードオフがDesign Docに残ってるだけでレビューの質が激変する