# アプリの使用環境
- Next.js
- Fireabse
- ChakraUI
- React-hook-form
- Typescript
- SWR

## アプリの概要

学習コミュニティ内でリーダーさんの知り合いの農家さんに向けた発送管理アプリをプログラミングの学習を兼ねて作ってます。
細かい部分は割愛しますが、プロダクトオーナーでもありチームリーダーの方が書いた記事を載せておきますのでご興味のある方はぜひ読んでみて頂けると幸いです。

https://qiita.com/6983/items/818fa903e9ea0ac73230

## 参加した経緯

2021年7月末で13年勤めた飲食店の退職を期に参加しました。
参加している学習コミュニティの中で参加者同士で集まって学習しているコミュニティの中で今回のチームが一番長く活発に活動しており非常に興味がありました。

また
- 個人での学習に停滞感を感じていた
- 退職して生活がだらしなくなりがちだったので早起きする理由を持つため（毎朝7時のデイリースクラム参加がプロジェクト参画条件だった為）
- 自分の為だとなかなか頑張れない性格なので、誰かの為だとより頑張れると思ったから
などの理由からプロジェクト参加を決意しました。

## チーム内でやったこと

私が参加したタイミングは2ndリリースのフェーズで既に上記の農家さんにはプロダクトは納品済みでした。
2ndリリースは一般リリースに向けての機能拡張やリファクタリングなどが主な開発でした。
その中で自身が担当した役割やチケット内容として
- 毎週のスプリントのプランニングをもうひとりのメンバーとミーティングを行いチケットの起票や優先順位決め、既知のエラーの確認など毎週行い、日曜日に隔週交代で司会進行を行いました
- コンポーネントのReact-hook-formの導入
- SWRでfreeeAPI情報をキャッシュデータとして取得する処理を記述
- TyperScriptの導入
- ChakraUIのコンポーネントのグローバルスタイル設定

https://qiita.com/hirock_e1983/items/b8163a59f46ed1a4263a
- freeeAPIのエラーハンドリングリファクタリング
- freeeAPIを用いて請求書更新処理の実装
- ヤマトCSVの伝票番号一括インポート機能の実装（使用パッケージReact papaparse）
(公式ドキュメント)

https://react-papaparse.js.org/docs
...etc

などを主に行って来ました。

-----

## 学んだこと（プログラミング編）

### Git、Githubの使い方
Githubなど個人開発では使ったことがあるが、『ブランチを切る』やローカル、リモートの概念などコマンドにも苦手意識があったが使っていくことで克服していった。
【参考にした講座】

https://www.udemy.com/course/intro_git/
【自身で作成したGitコマンド一覧表】

https://qiita.com/hirock_e1983/items/9e04461346c38d16d496


### React-hook-formやSWRなど使用したことがないパッケージを用いた開発を体験できる
チームに参画した時、各コンポーネントでReact -hook-formのリファクタリングの段階だったがこちらも誰かが先に実装したコードを読み取って理解を深めたり、後に書くそれぞれのドキュメントを読んだり苦手だったことが少しずつ出来るようになった。
特にSWRなどはずっと講座など見て学んでいても理解できず、プロダクトに落とし込めなかったが、チームのどのデータを扱いたいかが明確になることで概念理解が格段に上がった。

### ドキュメントやMDNを読む癖がついた
React-hook-formやSWR、freee-APIのリファレンスなど各実装のチケットで必要な情報を取りに行くとき今までは、読みやすい記事を探してたが根本理解が必要な場合はドキュメントやMDNを読んだりGithubのissueを調べたりするようになった。

### console.logを頻繁に使用するようになった（データの型を調べるようになった）
開発中盤〜後半にかけてはデータのやり取りを多く使うことになり、objectやArrayの型などをより意識して調べるようになった。特にlog を頻繁に出すようになり値の取得がしっかり出来てるか、データ型があっているか？などをしっかり調べるようになった。

### コードを書くとき自分がやりたい事を言語化することでゴールに近づける
後に知ることになったのですが、ふりがなプログラミングという書籍があるのですがそこに書いてあるような事を自然にやるようになっていた。

自分がやりたいことを言語化してそのためにどのような処理が必要かlog を追いながら見るとよりゴールに近づけると知った。

### 一人よりもチーム、答えはわからなくても解決のためのアイデアは出し合える
一人でプログラミングをしていると、なかなか人に質問することや詰まった時に助けてもらおうというタイミングが難しかったりするが、チームだと毎日のデイリースクラムで意見交換できたり、解決のヒントをもらえたりして実装の近道になったり、自分では導き出せないアルゴリズムを作ることができたりした。

### 変数の名前の命名の大事さを知った
一人でコードを記述していたときはなんとなく名前など決めていたし自分が把握していれば被ることはなかったけど、チーム開発を通じて他人がこれからこのコードを読む可能性などを考え分かり易い命名を考えたり、適宜コメントを入れたりして対応することの大切さを学んだ。
特に長い関数だと名前だけでその関数が何をしたいかすぐわかるようにすることで相互の作業効率が上がると感じた。

### パッケージ選定などはいきなりnode_moduleに入れずにcodesandboxなどで一旦使ってみる
上記のReact papaparseを選んだ際にパッケージを色々調べて選定する時にcodesandboxは簡単にdependenciesにパッケージを導入出来るので本当に重宝します。
ドキュメントに書かれたサンプルコードをコピペで動作確認出来た点でもパッケージ選びに重宝しました（大事なので2度言う）

-----

## 学んだこと（レビュー編）
先ず前提としてチームのレビューのルールとして
1. レビュアーはチームメンバーが作ったくじ引きアプリで決める。
2. そのくじ引きで選ばれた人がレビュアーになる。
3. チームメンバーは7−10人でその中でチケットを取ってレビューを回す。
というのがチームのレビューの流れです。

### 失敗談
誰でもそうだと思いますが、最初は全然できなかったりコードを理解することができなかったり、チケットの実装内容の仕様がそもそも理解できていなかったりしてたくさんチームに迷惑を掛けました。

- 間違ってレビュー中のブランチに自分のチケットの内容をプッシュしてしまった。。。
- コンフリクト解消をミスってデクレ、、、
- 誤ったコマンド入力してプッシュしてしまい、リバートするもリバートの仕様を理解しておらず余計にややこしくしてしまう、、、
- etc...

などありました。（懐かしいｗ）
こういった出来ないことや失敗も一つずつ改善していきました。

### レビューをする上で気をつけてること
- コード面とアプリの挙動面の2パターンで確認する
- 仕様がわからなくてもチームのルールに準拠した内容のものは見落とさない様にする。例えば不要なconsole.logがないか、import文のパスの記述は絶対パスがルールだが相対パスになっていないか等。
- よくわからない変数は必ずlogを取って値を確認する。
- 上手く動かない部分の解決策をある程度探って出来る限り解を持ってレビューを書く。

### 学んだこと
- コードに対するコメントはsubmitを押す、LGTMしたらApprove（認証）を必ず押す
- レビュアーをアサインする（誰がレビュアーかわかるようにする）
などレビューで学んだことは本当にたくさんあります。

-----
## まとめ
プログラミングを初めて１年が経ちましたが、自身の成長を感じられたのがチーム開発でした。
顔も知らない開発メンバーとの開発でしたが、本当に他者から受ける学びは一人でインプットするよりも何倍も効果があると感じています。
また、冒頭で紹介させて頂いたリーダーの記事のように
顔も知らないメンバーと、顔も知らない農家さん（私は）に喜んでもらい、そのプロダクトをまだ知らない人々に届けるって素敵だなぁと思い最近はエンジニアが天職かもと強く思い始めています。

学習に停滞感を感じてる人は、チームで誰かの為に開発してみてはいかがでしょうか。