フロントエンドのアプリケーションでチームの規約として考えるべきことってなんだろう

最近チームで今後のフロントエンドのアプリケーションをどうしていきたいかみたいな話をする機会を設けている。

最近は、

Composition API でロジックをコンポーネントから切り出すときにどういう単位で切り出すか
- ディレクトリ構成とかファイルの切り方とか
null とか undefined の使い方
- 両方使うかどっちかにするかはたまた……
コンポーネントの切り分け方をどうするか
- Atomic Design かその他か
データの持ち方
- Vuex で持つ or 持たない
- コンポーネントでよしなに Store にアクセスする or props でバケツリレーする

みたいなことを話し合ったりしている。

みんなこういうところどうやっているのかなというのが結構気になる。

6/15で書いたような記事をもう一度読んでみたりしようかな。

React は本当に自由な使い方ができるツールなので、コンポーネントの分割粒度から宣言場所、 import / export の方針、state 管理、 Hooks の使い方、コードのフォーマット、プロジェクトのディレクトリ構造に至るまで、現場のエンジニアが「あ〜これはこうしたろ」と思いついたものが大体そのまま違和感なくコードベースに吸い込まれてしまいがちであると言える

Nuxt でも同様な部分があり、コーディング規約を作るという人が出るのも頷けるなあという気持ちがある。僕が Rails を書いてきて CoC(設定より規約)に馴染んでいたので、未だに「決める」力が弱いと感じる。決める力が弱いので決まらなくて、決まらないと方針が人によって変わるのでバラバラになっていくので、ちゃんと話しあうのは大事だなと思っている。

社内の別のプロジェクトで Nuxt.js を使っているリポジトリがいくつかあるので、そういうところのコードを読んでみようかなと思う。