リポジトリ構成

# リポジトリ構成

- シンプルなvite+ReactのSPA構成
- Github Pagesで公開される

# コミット規約

1. fix: feat: chore: style: refactor: docs: test: のプレフィックスをつける
2. 本文は日本語で、明快に書く

# 開発

1. 変更作業が終わった際には npm run format でコードを整形する(コード整形はフォーマッタに任せる)
2. コミットをする場合、npm run test を実行してテストを通してから実施する
3. PullRequestを作成する際は .github/pull_request_template.md のテンプレートを使用する
4. マージ先は、派生元の topic ブランチに対して行う

# コーディング規約

- SOLID原則に従い、クラスの責務を明確にする
- ファイルは1つのクラス・関数を持つことが望ましい
- ロジックはhooksとして切り出す。コンポーネント、hooksをできるだけ小さく保つ
- staticにできるメソッドは積極的に関数として切り出す
- コメントは最終的に必要なだけを書く: リーディングガイド、およびコンテキストを提供する
  - AIによるコードの解説においても、過剰なコメントを追加しないようにする
- anyを避け、安全な型を使用する
- その場しのぎ的、または後からメンテナンスコストがかかるコードや設計を避け、小さく、シンプルで、重複のない、密度の高いコードを書く
- privateはSoft privateを使用する( # はまだ使用しない )

## ファイル名

- ファイル名はそのファイルの主となるクラス・関数名とケースを含め同一にする
- utilsなどの集約ファイルやフォルダは概念名を使い、kebabu-caseを使用
  - クラス名はUpperCamel、関数名はlowerCamelを使用する

## 命名

- 端的で明示的な名前を使用する
- メソッド・関数は動詞から始め、変数は名詞を使う
- booleanはis〜 has〜 will〜 といったプレフィックスを使用する
- private変数等も _ のプレフィックスは使用しない
- CSSのクラスはケバブケースを使い、インポートしたクラス名はLowerCamelで参照する（相互変換されている）

## ロギング

- 開発中は console.log を使用し、最終的には削除する
- 開発者向けのメッセージはconsole.debug, 社内チーム向けエラーは console.warn / console.error を使用する