Next.js,React,TypeScript,Ruby on Rails,RSpec扱った 受託開発の案件に参画した時に学んだこと

# 自己紹介
1. ***PHPからRubyに切り替えた案件***
2. ***フロントエンド開発(React,Next.js)に初参画。バックエンドでは初のテスト実装***。
3. ***QiitaでやZenn技術やマインドの記事を発信し、300記事以上投稿***
4. ***未経験時代に共同開発をやっていた時に経験者と未経験がいる中でリーダーを務めた***
5. ***オンラインコミュニティーで勉強会を主催する***

# 情報発信
***QiitaやZennに300記事以上投稿***し、アウトプット。

https://qiita.com/Hashimoto-Noriaki

https://zenn.dev/norihashimo

# 概要
細かい詳細は都合上書けないのですが、可能な範囲で書いたのでご了承ください。
```自身2度目の開発案件(株式会社DEPARTURE)```に参画した。

### ```1.受講生を管理する教育サービスの開発```案件。
***バックエンドとフロントエンド担当***。こちらが```メインの案件```です。

・人数(***4名)***
***リーダー1名、レビュアー2名***

#### 環境
<dl>
<dt>テキストエディタ</dt>

  ```VSCode```
</dl>

<dl>
<dt>インフラ</dt>

 ```Docker```
 ```AWS```
</dl>

<dt>フロントエンド</dt>

```JavaScript```
```TypeScript```
```React```
```Next.js```
</dl>

<dt>バックエンド</dt>

```Ruby```
```Ruby on rails```
</dl>

<dt>その他</dt>

```ngrok```
</dl>

受講生が質問したり、日報を書いたりした時に履歴を管理できるサイトで、
受講生の進捗状況なども確認できるサイト。

### ```2.飲食店向け農産物の販売サイトの開発(RSpecを使ったテストの担当)```案件。
・人数(***9名)***
・***バックエンド8名***
***リーダー1名、レビュアー2名***

⚫︎***環境***
<dl>
  <dt>テキストエディタ</dt>

  ```・VSCode```
</dl>

<dl>
<dt>インフラ</dt>

 ```・Docker```
</dl>

<dl>
<dt>サーバーサイド</dt>

```Ruby(3.1.0)```
```Ruby on Rails(7.0.4)```
```RSpec```
```RuboCop```
</dl>

多種多様な新鮮野菜などを、スマホやPCから注文すれば。
自社およびパートナー便により、
首都圏を中心に全国主要都市の飲食店に直接配送するためのサイト。


#### タスクやスケジュール管理などのツール
共通で以下のツールを使っていました。

1.```GitHub```
2.```Slack```
3.```Postman```


# タスク(フロントエンド)
***フロントエンド開発は初参画***でした。

⚫︎***フロントエンドの環境構築***
***リーダーの方が作ってくれた環境に沿って構築する際に環境構築がうまくいっていない人にもアドバイスをする***ようにした。経験年数が長いエンジニアでも環境構築は苦労するので、***どういう意図でこのような環境を作ったのか***を考えていきたい。

●***Footerの修正*** 
***MUIコンポーネント***を使った実装でした。```Tailwind```を初めて使用した。
TailWindを使った実装を身につけることができた。

⚫︎***PR履歴の作成***
***かなり時間がかかるチケットで、20ファイル以上変更したのは開発現場に入ってから初***だった。
***PR一覧のテーブルのbodyとheadの両方も作ったので、1人で3人分のタスク***でした。

⚫︎***PR履歴のhead追加***
上のタスクでこなす

⚫︎***PR履歴のbody追加***
上のタスクでこなす

⚫︎***インポートエイリアスを使ったリファクタリング***
コードを見やすくするためにコードの整形をして、***他の開発者やリーダーからもコードが読みやすくなったと現場から評価***をいただいた。

⚫︎***ISSUEの作成***
初めて自分でISSUEを作った。今どういうISSUEが必要なのかを考えて、現場の業務改善に務めていきたい。

⚫︎***interfaces/index.tsを個別ファイルに分割***
ファイル構成も見やすくするにはどうするかを学んだ。

⚫︎***ボタンの共通化***
共通化の概念を理解できた。

⚫︎***PRの一覧をfetchを用いてPRデータを取得して表示するように修正***
まだバックエンドを作っていなかったので、ダミーデータを作成してapiフォルダを作って、
fetchを用いてデータを取得。

# フロントエンド開発で学んだこと
1.***Tailwindを使ったこと***
Tailwindを初めて使い、CSSよりも便利だと感じた。

2.***実装のやり方はプロジェクトに合わせる***
動作上問題無くても、コードの書き方は現場に合わせることが大切と学んだ。

3.***React,Next.jsの基本***
インプットしかしていない状況での開発だったのバックエンドの業務よりかなり苦戦した。

4.***TypeScriptを使った案件に参画***
実務でやる機会がなかったので今回初めて実務で扱うことができた。

5.***PRを出す前にESLintやPrettierを使うこと***
コードの品質のためにもコードの整形は毎回やることが大切だと学んだ。

6.***importエイリアスを使うこと***
コードが圧倒的に読みやすくなる。

https://qiita.com/Hashimoto-Noriaki/items/1e48c028cadeb48c2889

7.***useStateやuseEffectなどの基本を理解できたこと***
実践で使って使い方が理解できました。

8.***Issueの作り方***
今何が問題なのかを考えて作るので、かなり学びが多かったです。

9.***フロントエンドでAPI関連の実装***
自分が実装した段階ではバックエンドの開発はできていませんでしたが、
API関連の実装を学べました。

10.***どうすればコードが読みやすくなるかを考える***
自分より経験がある人のコードを読むことができたのが収穫でした。

11.***Issue通りに実装すればいい訳ではないこと***
間違っていることもあるし、それをフォローするのがエンジニアの仕事。
***ロボットみたいにIssueを捌くのではなく、どうすれば売上が上がるかも考えてやっていく必要がある。***

# 苦戦したこと、指摘されたこと、反省点、改善点(フロントエンド)

1.***Footerはfixedやabsoluteで固定しないこと***
Footerを画面の下に固定するとユーザー体験が悪くなります。基本どのサービスもフッターはflexやabsoluteを使わないです。当たり前だが、初めてフロントエンドの実装をした時に指摘された。(フロントエンド1ヶ月目)

2.***pagesフォルダの中のusersフォルダの中にユーザーのみが利用できるコードを使う***
PRの履歴ページを作っているときにpagesフォルダにPR履歴ページを作るためのファイルを作っていたのですが、これだとユーザーしか閲覧できないようにならず、ユーザー以外も見れてしまうと指摘が入った。(フロントエンド1ヶ月目)

3.***commonファイルはnavやheaderなどのどの画面でも使うファイルでしか使わない***
ファイルで再利用することと勘違いをしてしまっていたので指摘が入りました。
headerやnavなどが共通ファイルにすることが多いと学んだ(1ヶ月目)

4.***他の実装者のコードを参考にして書き方を合わせる***
バックエンド開発でも指摘されたのですが、フロントエンド開発でも同じでした。

5.***インポートする際にライブラリの順を分けておくこと***
reactならreact、TableはTableで分けておくという意味。
```tsx
import React from "react";
import { useState } from "react";
import Table from "@mui/material/Table";
import TableBody from "@mui/material/TableBody";
```
　
6.***チケット以外の変更はPR欄に書いておく***
チケット外の対応でインポートaliasをサービスのファイル全体に適用させることになった時、
PR一覧に書いていなかったのがPRで指摘が入った。
後削除したファイルの理由もちゃんと書くべきだった。

7.***ISSUEを作る時に苦戦したこと***
以下のことを指摘される。
```
1.他の人が1ヶ月後にやることを意識して書く
2.わかりきったことは書かない
3.概要を書く時はWHY 実行手順はWHAT　で書く
```
特に1が難しい。
***コツは文章が長すぎると伝わるけど、短すぎても伝わらない***。
***この中間をうまくやることが大切***。
だから日々日報やドキュメントを書いて言語化するトレーニングが必要だと痛感した。

8.***export default  Buttonじゃない場合***

1つしか処理がない場合はexportでまとめる。


# タスク(バックエンド)1の案件
⚫︎```RuboCopの導入```
bundle installをコンテナ内でやらなかったら不要なファイルまで変更されてしまった。
この点が反省点だった。

⚫︎```ユーザーの日報一覧取得APIの作成```
***コンソールの使い方やJWTの検証***など、BaseControllerの継承などを学ぶ。
***テスト環境の設定やcredentials、FactoryBotを使ったrspecの実装***などを
学んだ。

⚫︎```日報一覧取得APIの作成``` 
RSpecのテストの実装の理解が浅いせいで、このチケットは苦戦してしまいました。

# タスク(バックエンド)2の案件
***RSpecやRuboCopを使ったテストの実装***が多かった。

⚫︎```RSpec/NestedGroupsの修正```
***このタスクではRuboCopを起動した時にネストが深すぎて、RuboCopがあまり通らなかった***。
テストでも開発でもネストをあまり深く使いすぎるとコードの品質に影響が出ると学んだ。

⚫︎```Style/CommentAnnotationの修正```
***このタスクではRuboCopを起動した時にコメント欄でエラーが発生した。原因は# 〇〇:~とコメントを書く時に# 〇〇:の後にコメントを書いていなかったことが原因。***
動作上問題無くてもコメントもわかりやすく書くべきだった。

⚫︎``` RSpec/SendPdfService.insert_logの修正```
***異常系テスト***のタスクだった。現場に入った時に書いてあったコードにミスがあり、
そのミスに気がつかず、テストが通らず大苦戦し、オンスケにならなかった。
もっと全体的な処理のつながりを見ていけば速く解決できた。

⚫︎```RSpec/pdf.rbの修正```
FactoryBotを現場で使っていなかったのが苦労した。
テストコード、テストデータ、コードのどれが間違いでテストが通らないのかがわからず苦戦した。
デバックを使いながら考えられる原因を1つずつ潰していった。
***どういうコードは見づらいのかを自分でも気づくことができた***。

⚫︎```RSpecのテストコードの修正```
ネストなどがごちゃごちゃになっていたので綺麗にコードをリファクタリングをした。

# バックエンド開発で学んだこと
1. ***現場によってルールが変わること***
現場によってルールが変わるので今後も上長や先輩に確認したい

2. ***デバックの手法はbinding.pryだけではない***
binding.pryしか知らなかったので新しく知れたので良かった。

https://qiita.com/Hashimoto-Noriaki/items/28632ad8b809b31d3570

3.***git addやcommitの取り消しなど***
前回は使用しなかったが、今回初めて使用した。今後も使うことが増えそう。

4.***PRを出す前にRuboCopを使ってコードの整形をすること***
RuboCopを起動してからPRを出した方がいいと学んだ。

5.***細かい空行などに気を配り、プロ意識を持つこと(PRを出す前に自分でレビュアーをやる)***
***コードは長ければいい訳ではない。短いと後から来た人が読みやすいようにする。人のために書く意識を持つこと***。リーダブルコードにも載っていたのでしっかり身につけていきたい。

ex) 
誰が読んでもわかるコードにコメントはいらない。複雑な処理にはコメントを書く。など

https://qiita.com/Hashimoto-Noriaki/items/1fe13d15b10fd6a5b9bf

5.***ハッシュを使うとわかりやすくなること***
マージされてしっかりとチケットをクリアできましたが、1点アドバイスをいただいた。
RSpecのテストの中で以下のようなコードがあった。(実際のコードとは変えています。)
```
context '不正な値が入力された場合' do
        context '〇〇がnilの場合' do
          before { order[:details][0][0] = nil }
```
この[0][0]は現場にいればわかりますが、全くの初見だとわかりづらいです。
ハッシュとかにすると初見の人でもわかりやすいみたいです。

7.***バグを見つけたらバグ報告をする***
***Issuesを作ってBugやコード改善の報告をすることを学んだ***。
自分からコードの改善をもっとできるようにしたい。

8.***バックエンドのAPI開発は基本curlかPostmanで挙動確認する***
最初ブラウザに表示されなかったので、かなり苦戦していたが、
実際はcurlでJSON形式でデータを取得できればよかった。

9.***railsコンソールの使い方***
ユーザーデータがない時はコンソールでデータを作るということを最初思いつかなかった。
今回の案件で使いこなし方がわかってきた。

10.***credentialsやenvの環境変数などのtest環境の意識があまりなかったこと***
当初test環境ができていないにもかかわらずrspecが通らずに苦戦してしまっていた。
開発環境、テスト環境、ステージング環境、本番環境に対する意識ができるようになったのがよかった。


# 苦戦したこと、指摘されたこと、反省点、改善点(バックエンド)
1.***コマンドが入力できず苦戦した***
最初のタスクでRuboCopを使用した時に、コマンドが入力できなかった。
```
$ make bash
```
を入力した後にRuboCopのコマンドが使用できた。
***現場によって環境が変わるので先輩に必ず確認をこれからすべきと思った***。

2.***日報などを書くときは数字を使う***
数字で何件終わったとかではなくて残り何件など上長が把握しやすいようにコードを書くべきだった。

3.***チケットの背景までを上長に「何が目的で、どう取り組むか」を整理できていなかった***。
ただ目の前のチケットをこなすのではなく、このチケットの目的などを考えながら実装していなかったと反省した。
(案件参画1ヶ月目)

4.***コメントも細かいとこまで綺麗に書く***
RuboCopを起動時に、コメントの空欄でエラーが出た。細かいとこだけどコメントの小さな空行なども気をつけたい。

5.***マージした後ほissueをcloseすること***
チケットが終わったにもかかわらずチケットをオープンにしておくと
チケット管理ができなくなるので次回からは気をつける。

6.***デバックを使いこなすこと***
テストコードの修正をしている時になかなかエラーの原因がわからずに苦戦していたところ、
「デバックをもっと使いこなせる」と指摘された。***実際は開発するより、デバックしている時間の方が長い***。

7.***元々書いてあったテストコードが汚かったのでバグがでてしまい、エラーの解消に苦戦したこと***
以前テストコードを書いた方のコードのインデントやネストがぐちゃぐちゃだったために、
エラーが出てしまい、その後処理に苦戦をした。
***この経験からコードを綺麗に書かないと他のメンバーに迷惑がかかると学んだので
コードは綺麗に書こう***と思った。

8.***PHPの書き方から頭が抜けなかったこと***
前回の現場がPHP,LaravelだったのでRailsで開発にもかかわらずLaravelの書き方をしてしまった。
新しい言語やフレームワークにも慣れていくのが大切だと思った。

9.***FactoryBotを使わずにテストをしていたこと***
***現場ではFactoryBotを使われていなくて手動でテストデータを作成したのが大変***だった。

10.***配列が多い時は%Wを使うこと***

https://qiita.com/Hashimoto-Noriaki/items/dac86e74b0c03c534e2f

11.***繰り返し同じメソッドなどが使われる時はリファクタリングして後の人が見やすいようにすること***
何回も同じメソッドがあると他のエンジニアがコードを読みづらくなるので、
他の人が読みやすいコードを心がけたい。

12.***これからやりたいことを言語化する***
これができないとそもそもコードを書くことなんかできないです。
実装する前にまずはやりたいことを言語化するために2行程度の簡単な言葉で説明する。
そしてコードを説明しながら書く。

13.***APIのデータ取得はcurlかPostmanがメイン***
上記のことの認識がなかったので不要な作業や時間がかかってしまった。
ゴールを確認するのと、上のことを認識した上で実装していきたい。

14.***タスクのゴールを明確にすること***
想定の挙動になっているにもかかわらず、想定通りになっていないと勘違いをしてしまい、
余計な労力を使ってしまった。***ゴールはどうすればいいのかを必ずチケットの作成者に確認を入れる***ようにしたい。

15.***今自分がいる環境を意識すること***
開発環境、テスト環境、ステージング環境、本番環境の意識を持つことが大切だった。
テスト環境のenvやcredentialsがないのにテストを通らないのは当たり前だった。
この辺の認識をしっかりと持ちたい。

16.***問題の切り分けをやること(いきなり手を動かすのではなく、まずは考える)***
APIの実装でcurlでちゃんとデータは取れていて、テストで問題があったにもかかわらず、
モデルに問題があるみたいにエラーの特定で仮説を立てることができなかった。

17.***簡単なコードなら変数は不要***。
orderしたりwhereなどして、長くなる場合は変数に入れるといい。

```rb
class Api::V1::Web::POstController < ::Api::V1::Web::BaseController
  def index
    posts = Post.all
    render json: posts, status: :ok
  end
end
```
を
```rb
class Api::V1::Web::POstController < ::Api::V1::Web::BaseController
  def index
    render json:  Post.all, status: :ok
  end
end
```
みたいにする。

18. APIのバックエンド開発でブラウザにて挙動テストするものだと思っていた。これは覚えていく。

19. railsのコンソール操作が不慣れだった。(データ作成してってなってもすぐにはできなかった)
実際にコマンドを打って練習して行きたい。

20. curlを実行して
```
{"status":500,"error":"Internal Server Error","exception":"#\u003cNoMethodError: undefined method `daily_reports' for nil:NilClass\n\n    daily_reports = @current_user.daily_reports.all\n                                 ^^^^^^^^^^^^^^\u003e","traces":{"Application Trace":
#中略
```
のエラーを勘違いしていた。
```
サーバーエラーというよりかはアプリのコード内で発生しているエラーです。
undefined method `all' for nil:NilClass
は@current_userがnilにもかかわらず、
allで呼び出そうとしているのが原因です。
```
エラーの原因はここだった。
```
daily_reports = current_user.daily_reports.all
```
@current_user　がnilになってますが、どうすればnilじゃねくてデータが入るようにするにはどうすればいいでしょうか。***railsコンソールとかで入れるべきだった。***

***自分でこのエラーは何と言語化していきたい***。

21.***エラーが起きた時にエラーの意味を考えることができなかった***。いきなりChatGPTを使わないようにしたい。

22.***ISSUEにこういうテストをしてほしいと書いてあった。(コントローラーに)
```daily_reports_controller.rb
 # ISSUE: 実装。@current_userから日報一覧を取得して返す
    #  1. テストを作成する。
    #  2. 実装してテストする。
```
違う趣旨のテストになってしまった。***チケットの意図をまず考えて、質問する***(書いてあることも多いのでその辺りも確認)。

23.***Multi Environment Credentials関連のエラーの仮説がうまく立てられていなかった***ので、
***仮説を立てる時なぜを毎回考えるようにしていきたい***。

24.***いきなりChatGPTを使ってしまうことがあるので、まずは実装する時毎回言語化する***。(コメントを書きながら実装)

25.***デバックでresponse_dataが取れているかまで確認すればよかった。エラーが出た時は毎回デバックを使う(脱ChatGPT依存症)***

26.***何のデータとテストをしたいかを何に対してテストしたいかを把握する***

27.***状況整理！　　仕様理解！***(紙に書くようにした)

28.***User.firstを勘違い。id1とは限らない***

29.***ネストは２つまで***

30.レコード作成したが全部とれないような状況ですか？ 最後の一つだけ取れるような状況でしょうか？
という返事に対してわかりづらいと指摘されたこと

***ソースコードやスクショなどを使って説明していきたい。



# 成長したこと(バックエンドとフロントエンド)
1.***Git操作に慣れてきたこと***
Git操作で困ることは無くなっていました。
```git　rebase```などのコマンドはまだ使いこなせていないが、PR出すまでの流れはわかってきた。
作業中のpullなど前回苦戦したことが今回からはできていた。

2.***コンフリクトを自力で解消できたこと***
前回はコンフリクトが起きた時に慌ててしまっていたのですが、今は「コンフリクトが起きそうだな」と予想ができたり、
コンフリクトが起きても冷静に対処できた。

3.***PRはなるべく早く出せたこと***
何も上がってこないと他のメンバーがの進捗が把握できなくなる。
***PRを早めに出してフィードバックをもらいながら改善していくことが大切だと前回学んだのでそれを実践できた。***

4.***コードの改善の提案をするようになったこと***
初月の時は任されたタスクをやるだけになってしまっていたが、わかりづらいコードがあったので、もっとこういうふうにした方がいいのではと経験が浅いなりにも自分なりに提案したのは成長だった。

5.***コードを説明しながらコードを書くようになったこと***
最初の頃は、何も考えずにただコピペしているだけだったが、
***今何をやっているのか、何をしたいのかを言語化しながらコードを書くことができた。***

6.***新しくISSUEを作ったこと***
自分で必要な点を提案してISSUEを自分で作ることができた。もっと大きなシステムになっていく時でも、***今現場では何が必要かを考えていきたい***。

7.***チケット以外でインポートaliasを書き換えてコードが読みやすなり現場から感謝された***
読みやすいコードを意識するようになった。そのためリーダーに提案して、 採用された。

8. ***コンソール操作で何をやっているか理解できるようになってきた***

9. ***A server is already running***のエラー対応ができるようになってきた

10. ***class Api::V1::Web::Users::DailyReportsController < ::Api::V1::Web::BaseControllerに修正***したことで、エラーが解決。***継承の理解ができた***。

11. ***既存のコードでcurrent_userがどのように取得されているかは理解***できた(リクエストの Authorization ヘッダーからトークンを取得していて、特定のトークンが使われた時に、Userモデルから最初のユーザーを取ってくる)

12.***前と比べたら自問自答できるようになった***



### ブランチのルール
***developブランチからブランチを切ってfeatureブランチ作成***

ex) 
    feature/〇〇


# 3ヶ月目からの感想
.***今回の案件からRuboCopやRSpecなどのテストやコードの整形などのタスクが振られたこと***
前回の現場は開発だけだったが、今回からは開発以外のタスクをやることがあった。


# これから実務で取り組みたいこと
1.***問題意識を持つこと***
言われたタスクをやるだけではなくて***業務改善提案***などもできるようになっていきたい。

2.***後から入ってきたメンバーに教える立場になっていきたい***
1年以内に仕事に慣れて、後輩などができた時に自分が教える側になっていきたい

3.***3年以内にチームリーダーになれるようにしたい***
タスクがこなせるようになるのは1年以内で、2年以内には教える立場になり、3年以内に開発リーダーになれるようになりたい。

4.***AWS(インフラ)の仕事もできるようになり、```Infracture as Code```もできるようになりたい***
インフラを学び、アプリがどう動いているのかを深く知りたい。
あと、今回はAWSの環境での開発ではなかったのでAWSを使って実務をこなしていきたい。
***最終的にはフルサイクルエンジニアを目指していきたい****。

# その他アドバイス
1. responseデータはカレントユーザーのデータだけ
2. createだから最後に作る
3. User.first  配列の要素　id1とは限らない 

出口を決める
ワーストケースを決める
テスト弱いチーム多い

弱いとこ見つけてあげる
レビューがないチーム多い



# 実務に入る上での有益資料
1.***学習と実務の違い***
学習とプログラムの違いをベテランエンジニアでスクールメンターの方の説明が載っています。
Rubyですがソースコードも見ることができます。

https://qiita.com/jnchito/items/c9ca22efa270ff1b7f3d

2.***実務にアサインされたらどうするのか？***
実務にアサインされたらまずどうするのかについて細かい説明が載っています。

https://qiita.com/jnchito/items/017487cd882091494298