ReactにとってStoreライブラリなんてもんはほんまにどうでもいい

まとめ

• なんでもいい、どうでもいいと言い出すやつはだいたい内心でどうでもよくないと考えている

• Storeの話をするまえに https://react.dev/learn を読んでReactの基礎を理解しよう

• experimental state management frameworkと一生言い続けているライブラリをプロダクションで使うべきではない

• experimentalと一生言い続けているライブラリをプロダクションで使うならその部分は特に気をつけて疎結合にすべき

• ライブラリの話をしてないでreact.dev/learnのThinking in Reactを読もう

• とにかくreact.dev/learnを全部読んで、Reactのstateの基礎コンセプトを理解してからStoreへ移動しよう

• useContextは似て非なる存在で擬似的な流用はできるがまともな代用たりえない

  • useStateも同様

• なぜReactのhookだけでStore管理しよう論者の多くはuseReducerやuseSyncExternalStoreに言及しないのか

• React世界からみてStoreライブラリの詳細とかどうでもいいので癒着の余地はない

  • よくない場合、アプリ実装に原因がある

• ライブラリの批判をする前にreact.dev/learn LEARN REACTを読もう

• Store的機構の流用自体は有用だが、覚悟をもってやるべき。あとそういう目的外利用の結果でライブラリに文句をいってはいけない

• 初心者は、Reduxは使わないにしても Style Guide | Redux には一度目を通しておこう

  • お前がこれから踏む地雷の位置がだいたい書いてある

• https://react.dev/learn は、やる気があるぶんだけ無料で読めちまうんだ！

いいかげんAtomic Designを捨てて別の統一解が欲しい

Atomic Design、どうですか？
フロントエンドをやってる系の人たちはぶっちゃけしっくりきてないとおもいます。
僕を含めて、当初より「これ微妙やね（まぁ流行ってるし適当ではあるから使っておくか）」という見解の人はチラホラみかけました。

それもそのはずです。
朧げな記憶ではありますが、Atomic Designはそもそもプログラマーのために作られたメソッド……ではありません。
デザイナーの方が考案した、デザインシステム構築のためのフレームワークです（そうだよね？）。

Sketchでデザインコンポーネントを作成する際に（たしかSketchだったはず。懐かしいですね）、Sketch上のコンポーネントの再利用性を高めて使いやすくするためのものだったのです（だったはずです）。

それが「増えまくったReactコンポーネントをいい感じにフォルダわけしてえなあ」という需要と噛み合って流行ったと認識しています。

筆者のメインフィールドはReactですが、コンポーネントの表示上の見た目と実装や内包するDOMの複雑度はAtomic Designの方法論で抽象化できない、と当初より感じていました。

タスクの管理の属性に優先度を使っちゃいかん

おそらくは既知の話題。

古きよきIssue管理システムの各チケットにはたいてい「優先度」という属性があった、ある時代があったようにおもう。
これはやめましょうねという話。

だいたいこの手のシステムだとIssueをあげた本人、あるいは連絡を受け取った人がその場の雰囲気で「優先度: 高」とかをつけて、そこから開発チームがスクラムイベントとかそういう場でそのチケットの「優先度を判断」することになる。
チケットにはすでに優先度が付与されてるのに優先度を判断ってどういうことだよあーっ！？ 優先度: 高 のラベルがついてるんだから最優先でやれッッ！！ あの……優先度が高いチケットはすでに100枚くらいあるんスけど、最優先ってことは他のは優先度低いってことっスか？

どうしてこういう問題が生じるのか？
それは優先度、というそのIssue単体で機能しない概念を、しかも全体観を把握していない個人が主観で付与しているのが原因である。

Issueが主観で書かれているのは正しい（もちろん発生している事象が客観的に記述されている必要はある）。
しかし優先度は現場が相対的に評価するもので、なおかつ流動的に変動するものだ。
「低、中、高」みたいな粒度で管理できるものではない。

NIH症候群の逆襲

僕がプログラマーになった20代前半の時期は、ちょうどRubyやPythonが日本でもキャズムの峠を越え始めたあたりだったようにおもう。
なので最初の数年間は、当初の所属組織がSIerやハードウェア寄りのお堅い環境だったのもあって
「OSSはとにかく最高でバンバン使え」
「（他人が作った）小さいパーツをとにかく組み合わせろ」
「自分で書いたコードは少ないほど良い」
という当初の風潮を無邪気に信用していたようにおもう。
（とはいえ僕がプログラミングを覚えた言語であるPythonは他と比べると比較的堅実で、標準でできることをちょっと楽に書けるだけのライブラリは入れるんじゃねえ！というような文化はあった）

どうしてスタートアップのソフトウェア設計はいつもいつもブッ壊れてるんですかぁ？

そんな皆さまの疑問にお答えします。

スタートアップのアーキテクチャがブッ壊れてるのってなんでェ？

先にざっくりまとめましょう。

巷でよく言及されるのはカネ、つまりは雇用するエンジニアの能力問題を元凶とする方が多いようです。
スタートアップの内情を知っていれば金と雇用の問題がどれだけ切実であるかについて異論を唱える人はいないとおもいます。しかし僕の考えによればこれはスタートアップのソフトウェア開発が抱える問題のうちのひとつ側面にすぎません。

つまりどんなに優秀な人間をかき集めようがスタートアップのソフトウェア設計は近い将来壊れる宿命にあるということです。

スタートアップの存在意義は未来の不確実性そのもの