# プレゼン用メモ

## 概要

- コーディング規約の作成
- チーム全体として認識しているコーディング規約がない

## 具体的な問題点

- 変数や関数の命名規則がないため、ぱっと見で何のためのものなのかわからないものがある
- tailwindを使わないようにするという方針をコーディングし始めてから知った
- 他の人が使っていたいconsole.logが残っていて確認する手間が増えた
- 書いた人以外理解が難しいコードが出てくる可能性がある
- ターミナルに大量のlintエラーが表示されていて、ほんとに必要なエラーの情報があったときにわかりにくい
- 個人の環境の影響で表示されないひともいる

## メリット

- 新規で参画する人が比較的すぐに業務に入れる
- コードを解読する時間が減るため、タスク完了までの時間を短縮できる
- 引継ぎが楽
- 書き方が統一されていれば細かいところまで説明せずに済むので引継ぎの時間を短縮できる
- コードの品質があがる
- 書き方によってはアプリの容量自体が軽くなったり、処理が速くなったりする
- コードチェックの時間が短縮される

## デメリット

- 規約を守ってもらえるような環境を作る必要がある
- commit時に規約に違反してるコードがないか自動でチェックする処理を作成するなど
- 既存コードの扱いが難しい
- 既存のコードを新規作成した規約に合わせるには結構なコストがかかってしまう
- これから追加されるコードにのみ適用させて既存コードは少しずつ変えていくようにするなどして対応は可能
- 慣れるまで少しタスクのペースが落ちる可能性がある
- 導入のタイミングを考えれば解決しそう
- とりあえずリリースまでは今まで通りでリリース後の修正や機能追加から変えていくなど
- 定期的に規約自体が正しいのかどうか確認する必要がある
- 規約が最新のベストプラクティスにそっているのかなどを新しい技術がでたときとかに確認する必要がある
- 新技術を取り入れるときにそれに合わせて変更したりとか

## 実際にやりたいこと

1. 命名規則や推奨事項・禁止事項のドキュメント作成
- キャメルケースを使うようにする。グローバル変数は使わない。などを意識としてもっているのではなく、実際にドキュメントを作成し共有する
- ある程度の大枠は作るが、最終的には開発チーム全員の意見を取り入れて作りたい
1. プロジェクトのためのlintを設定
- デフォルトのものやvscodeの設定を読み込むのではなく、プロジェクトごとに設定し、それを読み込むようにする
1. huskyなどでチェックを自動化する
- コミット時にlintを実行し、引っかかる箇所があるとエラーを返すようにする
1. 共通処理に関するドキュメント作成
- アカウントの管理場所やAPIの叩き方、頻繁に呼び出されるコンポーネントの使い方など

## 例

### 命名規則について

#### 関数

- キャメルケースで書く
- 複数単語の組み合わせで書く
- 動詞＋名詞の組み合わせで書く

// Do

function updateEmployee() {}

// Don't

function update() {}
function employeeUpdate() {}
function update_employee() {}
function UpdateEmployee() {}

## 1/26までにできること

- 命名規則、禁止事項などのドキュメント作成
- これを成果として提出し実際に使ってもらう？
- lintの設定は設定から導入まで結構時間がかかる気がしてるので厳しそう

## 確認事項

- 既存の規約
- 開発してる人は認識してない
- あるかわからない
- 実際作るとなったときどこに作成すればいいのか
- docbase?box?

## リンク集

- [システム開発部コーディングルール](https://softbrain.ent.box.com/file/674209742198?s=p904b3v2fhtt23aso44imrpji8b0nsx4)

## めも

- 具体的な問題点をもう少し深堀したほうがいい
- それぞれにたいして具体的などういった問題があったのかあげる
- コーディングルールの作成だけで本当に解決できるのか
- ソナーりんと
- フロントようの設定を見直す
- 1か月でおわることではなく、具体的なスケジュールを発表する
- 高見さん