設計の境界線と、その手前にあるもの

エンジニアどうしのすれ違いを、認知特性の違いとして整理する議論があります。チームでの摩擦を「性格」や「やる気」に帰属させるのと比べると、整理として参考になる視点だと思いました。ただ、ちょっと気になることはあり、その正体が何なのかを少し整理してみます。 扱われている題材を検討していくと、結局はソフトウェアコンポーネントのモジュール化の話なのではないか、というところに行き着くように思います。何を一つの塊として扱うか、どこに境界線を引くか、何を内側に隠して何を外に出すか。文脈や意図をコード本体に置くか外部ドキュメントに展開するか、未確定な情報をどこに逃がすか、責務をどう分けるか。これらはすべてモジュール性、情報隠蔽、抽象化、変動点の分離といった、半世紀以上前から積み上げられてきた設計の語彙で語ることができます。未確定なものを切り出すパターンに限っても、ストラテジーパターンやプラグイン機構による設

[mak_in]

ITソフトウェアの設計は、最適化と柔軟性のトレードオフをどうとるか、想定する未来をどう対応してくか、時系列的に複数ある未来のどの未来に向かっていくか、という思想に最終的には帰着していく。そこを合わせる

[ledsun]

“設計を仮置きし、運用し、違和感を拾って、また組み直す。このサイクルを回し続けるしかありません。設計原則は、このサイクルの中で判断のショートカットとして使う道具であって、サイクルの代わりにはならない”

[remonoil]

合理的な設計は大前提のうえで唯一解に定まらない要素を選ぶ手段という別ベクトルの議論だと思ってた。例えば "設計を仮置きして" や "違和感を拾って" の部分

[simplememofast]

『境界の妥当性は…外側にある要請から決まる』が刺さる一文。認知タイプ論で人に押し戻すより、変更頻度と責務で線を引いた方が現場での寿命は長い

[nguyen-oi]

「認知特性」に逃げずに設計の妥当性を対話で詰めろってのは正論すぎて耳が痛いエンジニア多そう

[katzchang]

考えをまとめました