#◆Worse is Betterという考え方

http://chasen.org/~daiti-m/text/worse-is-better-ja.html
https://note.com/ruiu/n/n9948f0cc3ed3
自分が見てきた中でWebフロントエンドの開発効率が落ちてしまう一番の要因は、きれいで理論的には優れているアーキテクチャを構築しようとしてそれ自体がもたらす複雑性を支えきれないというパターンです。
少し前にフロントエンドにClean Architecture（以下CA、あの同心円の図を指すのは誤用に近いですがここではそれに乗ります）を導入する記事が流行ったと思いますがあんな感じです。ああいったクラスベースでDIが重要となる設計手法はサーバーサイドのJavaでSpringを使うのとは違ってReactがサポートしているものではないため、CAの実現自体に高い設計スキルが必要になると思います。もちろんつくるアプリケーションの複雑度にもよりますが、フロントエンドでCAを必要とするほど複雑なアプリケーションはそう多くはないと思います。
CAによって外部に依存しない純粋なビジネスロジックを表現したコードを手に入れることができますが、そのトレードオフとしてコード量や複雑性が増加することは無視できません。CAを諦めて、サーバーサイドのOpenAPIの型に直接依存するようにして薄く作るとコード量が少なく理解しやすいコードベースを構築できます。そうすることでCAのメリットとなるビジネスロジックの純粋性はトレードオフとして失われますが、代わりに得られたコードのシンプルさによる理解のしやすさや変更容易性を重視するというのが（自分の理解する限りでの）Worse is Better的な考え方です。

#◆コードの品質の価値を過小評価しない
書籍Clean Architectureはあの同心円の図が独り歩きしてますが、設計以前の考え方に結構なページ数が割かれていてしかもとても参考になります。

序盤に出てくる刺さったフレーズを2つ雑に要約してみます。

１．汚いコードを書く方がクリーンなコードを書くより常に遅い
　　・スタートアップだから、開発初期だからコードが汚くていいということはない
２．ソフトウェアの構造は振る舞いと同等の価値を持つ（構造≒変更が容易であること）
　　・完璧に動作するけど変更ができないより、バグだらけだけど変更が容易な方が良い

特に2番目は個人的には目からウロコで、ソフトウェアのユーザーに提供する動作・振る舞いと同じくらいアーキテクチャとコード品質が適切に保たれていることが大事という視点はなかったです。同書では構造というエンジニアにしか見えない価値を守るのはエンジニアの責任であり、そのためにはPdMやセールスといったステークホルダーと「闘争」して構造を守る必要があるとまで書かれています。そして1番目にもあるようにコードの品質を高くすることが結局は開発速度を速くするのであればそこに注力するのが正しいと言えそうです。この1番目については書籍Clean Architectureにあるような設計テクニックをつぎ込んできれいで正しい「良い」アーキテクチャを目指したくなりますが、トレードオフを見てWorse is Better的な設計・コードを採用すべきだと思います。