複雑性保存の法則
#UI/UX #プログラミング #複雑性 #柔軟性
@manabuueno: テスラーの「複雑性保存の法則」のオリジナル文言。“全てのアプリケーションには、それ以上減らすことのできない固有量の複雑性がある。唯一の問いは: 誰がそれを扱うかだ - ユーザー、アプリケーション開発者、それともプラットフォーム開発者?” https://t.co/FSvjNnLDpS
@okunokentaro: クソデカComponent
→クソデカHookに大量のuseStateとuseEffect
→大量のatomと大量のSelectorと大量のuseRecoilCallback←今ここ
要件がデカいとどうリファクタリングしても別に実装が小さくなるわけではない
Redux#63ec081e86603000007d1a4f
難しさが廃されるのではなく、難しい部分が一箇所に集中する。React Component の末端では、何も考えることがなくなる。状態管理という難しい部分を作る人と、末端のコンポーネントのデザインに注力する人を分けられる。
大規模になっても設計が破綻しにくい、というエンタープライズ向きな特性を持つ。が、その技術基盤は(静的)関数型由来の考えが多く、基礎設計や基盤理解にはハイスキルが要求され、需要と適用対象のミスマッチを感じることはある。結果として、そもそもハイスキルを前提として、大規模であることが自明な SPA 向きということになる
redux の作者でありオピニオンリーダーだった Dan Abramov は、現在 redux との距離を置いているように見える。React コアチームに近い、よりシンプルなものを、という立場になっている
複雑性を見かけのコードで減らすという考え方は根本解決ではない
多くのケースで、ライブラリの責務を誤解していたり、単なる無理解でそのようなハックに手を出す人が多い。ハックは目先の問題を解決するが、それがどれぐらい重大な副作用が発生しうるか、想像できる必要がある。
「今どう見えるか」ではなく「どう進化していくか」
複雑性は受容し、理解し、依存関係を整理する
抽象化とモデリングの違い
不確実性や複雑性は隠蔽するのではなく向き合い方を知るべし
やるべきことは、モジュール境界を明確にして複雑さを局所化すること
困難は分割せよ(サブドメイン分割)
依存関係の意味を区別する
重要なことと重要ではないことを区別する
GUI、というかReactのカプセル化単位はコンポーネント
宣言的UIのデータアーキテクチャはコンポーネントを中心に考える
GUIでスケーラブルなアプリを書く秘訣は、良いコンポーネントを適切なタイミングで抽出することで、それ以上のことはない