決定的なフロントエンドアーキテクチャがいい
「xxx ディレクトリに設置しませんか?」「utils に切り出しませんか?」「composable 化しませんか?」「watch を使わないで computed で書けませんか?」
これらはフロントエンド開発の設計観点から度々発生する議論です。
生成AIで開発速度が高速化されていく中、これらの判断を1つずつすることは現実的でしょうか?
私がフロントエンドエンジニアとして関わる新規プロダクトでは、Nuxt を採用する中、ファイルや関数の設置場所や命名、API の使い方など、可能な限り決定的に取り決め、リンターによるガードレールを設定しています。
その結果、殆どのPRが数分でレビューし終わる状態を実現できたり、フロントエンドに詳しくなくても開発可能な体制を整えることに成功し、堅牢かつ高速な開発環境を実現しました。
本セッションでは、開発中の Nuxt プロジェクトのアーキテクチャを例に、実際の現場でどのような決定的な判断ルールを取り決め、迷わないアーキテクチャを構築しているかについて紹介します。
辻佳佑
決定的なフロントエンドアーキテクチャがいい
「xxx ディレクトリに設置しませんか?」「utils に切り出しませんか?」「composable 化しませんか?」「watch を使わないで computed で書けませんか?」
これらはフロントエンド開発の設計観点から度々発生する議論です。
生成AIで開発速度が高速化されていく中、これらの判断を1つずつすることは現実的でしょうか?
私がフロントエンドエンジニアとして関わる新規プロダクトでは、Nuxt を採用する中、ファイルや関数の設置場所や命名、API の使い方など、可能な限り決定的に取り決め、リンターによるガードレールを設定しています。
その結果、殆どのPRが数分でレビューし終わる状態を実現できたり、フロントエンドに詳しくなくても開発可能な体制を整えることに成功し、堅牢かつ高速な開発環境を実現しました。
本セッションでは、開発中の Nuxt プロジェクトのアーキテクチャを例に、実際の現場でどのような決定的な判断ルールを取り決め、迷わないアーキテクチャを構築しているかについて紹介します。
