これからエンジニアを目指す人に読んでほしいWeb開発まとめ

# はじめに
この記事は，以下に当てはまる方が読むことを想定しています．
- エンジニアとして働いたことがない方
- IT企業に就職を考えている方
- Web開発の流れを理解したい方
- HTMLやCSS以外のことを知りたい駆け出しエンジニアの方

# 全体の流れ
どの企業もそうだと思いますが，いきなり<b>開発</b>から始まることはめったにありません．
基本的には，以下のような流れでシステム開発が進んでいきます．知らない単語が出てくると思いますが，後で詳しく説明するので，気にせず読み進めて大丈夫です．

1. <b>チケット</b>が切られる
1. MTGに参加する
1. スケジュールを立てる
1. 調査を行う
1. 設計をする
1. 設計書をもとに<b>DEV環境</b>で開発を行う
1. <b>ユニットテスト</b>を行う
1. ソースコードをGitHubに上げて，チームの人に<b>レビュー</b>してもらう
1. <b>STG環境</b>に<b>デプロイ</b>する
1. テストケースを作成する
1. ブラウザテストを行う
1. <b>リリース</b>に向けたドキュメントを作成する
1. リリースの判定MTGを行う
1. 本番前の<b>PRE環境</b>へリリースし，テストを行う
1. 本番の<b>PROD環境</b>へリリースし，テストを行う
1. masterブランチにマージする
1. お仕事完了！

# チケットが切られる
チケットとは何かを説明します．
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1917122/f7edee60-4b50-1a1e-4104-7e8d6148f377.png" width="40%"/>
企業では，ソースコード管理やプロジェクト管理のツールとしてGithubやJIRAなどを使います．そこでタスク管理のために使われるのが<b>チケット</b>というものです．プロジェクトマネージャ（以下，PM）がタスクの概要と開発してほしい要求をチケットにまとめ，そのタスクに合うエンジニアをアサインします．エンジニアはチケットを見ることで，自分が何の仕事を行えば良いかすぐに分かります．

# MTGに参加する

チケットが切られたら，そのタスクを行うチームメンバーとPMがMTGを行います．そこで話す内容は，以下の通りです．

- どのような機能を開発すればゴールなのか
- どこにドキュメントをまとめるか
- 大まかなスケジュール

# スケジュールを立てる

タスクの概要が分かったら，見積もりを立てていきます．以下に例を挙げます．
| ||Period|
|:--|--:|:--:|
|1|要件定義，調査|2022/10/01-|
|2|設計|2022/10/08-|
|3|開発|2022/10/15-|
|4|テスト|2022/10/22-|
|5|リリース判定|2022/10/27-|
|6|PREリリース|2022/11/01-|
|7|PRODリリース|2022/11/08-|

# 調査を行う
スケジュールを立てたら，調査を行っていきます．ここでの<b>調査</b>とは，チケットのタスクを行うにあたって，以下を調べることです．

- どこのソースコードを修正すればよいか
- 今回の開発・修正が影響する範囲はどこまでなのか
- 何を新規開発すれば良いか

# 設計をする
設計をするときには，PMからもらった（or聞いた）要件定義をもとに，どのようなシステムを開発すれば良いかを定めていきます．ここでは，基本設計と詳細設計に分けてドキュメントを作っていきます．
## 基本設計
基本設計では，タスクの概要，ビジネスフロー，開発する機能の定義などを書いていきます．ビジネスフローとは，下の画像のような流れを図で描くものだと思ってください．
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1917122/f273de10-a59e-c548-4a60-2043967b6a4f.png" width="100%"/>

開発する機能を定義するときには，以下の点を踏まえながら書いていきます．

- どのような機能を持っているか
- Webページであれば，どのような部品を作るか
- APIであれば，inputとoutputを何にするのか
- どのような条件で動作するのか
 
## 詳細設計
詳細設計では，具体的にどのように開発するのかを書いていきます．
既存のソースコードがどうなっているか，修正する場合はどこを変更するかをまとめます．Webページを開発する場合には，画像などを用いて改修部分を示すと良いですね．またAPIの場合には<b>データ構造</b>や，<b>GET/POST/PUTなどの機能</b>，<b>エンドポイント</b>をまとめていきます．また，下の画像のようなプロセスフローを図示していきます．

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1917122/772a7999-a818-fff4-9aca-36616327a20f.png" width="60%"/>

# 設計書をもとにDEV環境で開発を行う
設計が終わったら，ようやく開発に着手します．すでに設計でどのソースコードを変更するか決めているので，設計書に沿って修正すれば大丈夫です．新規開発の場合には，既存のソースコードが再利用できるか考え，できない場合にはgoogle先生に頼りましょう．googleで検索するときには，以下のポイントに気をつけましょう．

- 英語で検索する
- ２次ソースではなく，公式ドキュメントを読む（〇〇 official document 🔍）

ここで，<b>環境</b>とは何か説明します．
開発フェーズによって，環境の呼び方が異なり，基本的にはDEV→STG→PRE→PRODの順番で使用されます．

| |Environment|Description|
|:--:|:--:|:--:|
|DEV|Development|開発環境|
|STG|Staging|機能を検証する環境|
|PRE|Pre-Production|本番環境に近い環境|
|PROD|Production|本番環境|

開発をするときには，自分のpcで実行することで，<b>localhost:8080/</b>のようなところで確認しながら進めます．
また，gitを使って新しいブランチを作成してから，開発を行います．
```
//もともとmasterブランチにいる想定
git pull origin master
git checkout -b feature/componentA
```

# ユニットテストを行う
APIを開発するときには，データをGETしたり，POSTしたりする必要がありますが，いきなり本番環境でデータのやり取りを確認することはできないので，<b>Mock</b>と呼ばれる擬似的な部品を作ってテストをしていきます．これをユニットテストと呼びます．JavaだとJunit，JavascriptだとJestが定番ですね．公式ドキュメントを載せますので，興味がある方はこちらをご確認ください！テストでは，<b>カバレッジ</b>と呼ばれる指標が100%になることを目指します．カバレッジが100%になると，自分が書いたソースコードに対して，網羅的にテストが行われ，全てクリアしたことを意味します．

https://junit.org/junit5/

https://jestjs.io/ja/docs/getting-started

https://pleiades.io/help/idea/code-coverage.html

# ソースコードをGitHubに上げて，チームの人にレビューしてもらう
ソースコードを開発したら，チームの共有レポジトリに上げます．
一般的にはGithubを使うことが多いです．
Gitの使い方については省きますが，次の手順を踏めば共有レポジトリにあげることができると思います！（feature/componentAというブランチにあげる例）
```
git add .
git commit -m "created componentA"
git push origin feature/componentA
```

pushが終わったら，GitHubでプルリク（Pull Request）を作成します．ここでは，チームメンバーをアサインして，レビューしてもらいます．プルリクに興味がある方は，以下のサイトに飛んでみてください！

https://docs.github.com/ja/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request

# STG環境にデプロイする
デプロイとは，ブラウザ上でアプリケーションを表示させるために，開発したシステムをサーバ上に配置することです．これをすることで，<b>localhost:8080/</b>とやらなくても，<b>https://</b>のようなURLからアクセスすることができます．このデプロイを行うために使う，有名なツールがJenkinsです．
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1917122/3cae0339-817a-ee32-18be-f18c3e393bdc.png" width="60%"/>

Jenkinsでは，パラメータとして環境（stg, pre, prod）を設定し，GITブランチを指定して，Buildというボタンを押すと，自動でデプロイすることができます．ただし，こちらはJenkinsファイルを作成していることが前提となるので，個人開発ではあまり使用しないかもしれません．Jenkinsを使ってSTG環境にデプロイができたら，STG環境で不具合が起きていないか確認し，大丈夫そうならテストに進みます．

# テストケースを作成する
各ブラウザ（Chrome, Safiri, Firefox, Microsoft Edge）に対して，WebモードとSPモードの両方を使用してレイアウト崩れがないか，開発したコンポーネントが機能するかをテストするために，以下のようなテストケースを作成します．

|No|確認観点|ブラウザ|確認内容|エビデンス|
|:--:|:--:|:--:|:--:|:--:|
|1-1|初期表示|Chrome|表示されること|画像|
|1-2|ボタン押下|Chrome|遷移すること|画像|
|2-1|初期表示|Safari|表示されること|画像|
|2-2|ボタン押下|Safari|遷移すること|画像|

# ブラウザテストを行う
テストケースを作成したら，そのテストケースに沿ってブラウザテストを実施していきます．こちらを<b>インテグレーションテスト（IT）</b>と呼びます．全てのテストケースを行い，100%になるまで実施します．もし不具合が見つかった場合には，開発に戻り，ソースコードの修正及び再度デプロイを行います．

# リリースに向けたドキュメントを作成する
ITが終わったら，リリースに向けたドキュメントを作成します．リリースする際にどのような手順で行うのか，もしリリースができなかった場合には，ロールバックをどのように行うかをこのドキュメントに記載します．

# リリースの判定MTGを行う
チームメンバーと共にリリースドキュメントを見ながら，この手順でリリースを進めて良いか判定MTGを行います．こちらで指摘された場合には，ドキュメントを修正します．

# 本番前のPRE環境へリリースし，テストを行う
いきなり本番環境にデプロイすると危険なので，本番前のPRE環境へリリースを行います．PRE環境にデプロイが成功したら，動作確認のテストを行います．

# 本番のPROD環境へリリースし，テストを行う
最後に本番環境にデプロイします．これにより，全世界の人々がサイトを見れるようになります．

# masterブランチにマージする
リリースに成功したら，対象のブランチをmasterブランチにマージします．これにより，masterがPROD環境で公開されているソースコードと同じになります．

# 最後に
ここまで読んでくださり，ありがとうございました！
他にも記事を書いていますので，よかったらご覧ください！

# 他の記事

https://qiita.com/walnut-pro/items/0124a5a0c83c9b4e2669