【研修資料】Webアプリケーション開発基礎

Webアプリケーション開発基礎 2025年度エンジニア内定者研修

Copyright © 2015 every, Inc. All rights reserved. 2 •
講義の目的とゴール • Webアプリケーションの構成要素 ◦ 前置き ◦ ブラウザが表示する HTMLはどこから取得できるのか ◦ 外部データソースを利用した動的なレンダリング • バックエンドとフロントエンド ◦ バックエンド ◦ フロントエンド • 開発で必要な知識 ◦ アーキテクチャ ◦ テスト ◦ CI/CD 目次

講義の目的とゴール

4 Copyright © 2015 every, Inc. All rights reserved. •
Webサイト（Webアプリケーション）がどのようにしてユーザーに届けられているのかを知る • Webアプリケーションの基本的な考え方を知る • フロントエンドとバックエンドについて理解する • チーム開発に必要な知識を知る講義の目的とゴール前置き

Webアプリケーションの構成要素

前置き

Copyright © 2015 every, Inc. All rights reserved. 7 「Webサイト」と「Webアプリケーション」の違いとは？🧐
【Webサイト】【Webアプリケーション】 Webアプリケーションとは？前置きクライアント（ブラウザ）クライアント（ブラウザ）サーバサーバレスポンス（HTML）レスポンス（結果）リクエスト（操作）

Copyright © 2015 every, Inc. All rights reserved. 8 Webページを構成する三大要素
前置き Webページの「骨格」見出し・段落・リストリンクなどページの構造を定義する役割 Webページの「見た目」文字の色や大きさ・レイアウト・背景色などを装飾する役割 Webページの「動き・機能」操作に応じた表示変更やサーバーと通信するなどページに動きを与える役割

Copyright © 2015 every, Inc. All rights reserved. 9 HTML（HyperText
Markup Language）：ハイパーテキストを記述するためのマークアップ言語　　　　　　　　　　　　　　　　　　→ 複数のテキストなどを相互に関連付けたシステム HTMLとは？前置き

Copyright © 2015 every, Inc. All rights reserved. 10 HTMLの基本構造
HTMLの基本的な構造前置き DOCTYPE宣言 html要素 head要素 body要素 HTMLの種類を宣言 HTMLの最上位要素メタ情報（タイトル等）本文を記述 <meta charset “UTF-8”> <title>HTML</title> <h1>見出し</h1> <!DOCTYPE html>

Copyright © 2015 every, Inc. All rights reserved. 11 HTMLの基本構造
ブラウザが HTMLをどのように理解するか前置き DOCTYPE宣言 html要素 head要素 body要素 HTMLの種類を宣言 HTMLの最上位要素メタ情報（タイトル等）本文を記述 <meta charset “UTF-8”> <title>HTML</title> <h1>見出し</h1> <!DOCTYPE html> DOMツリーとして理解（Document Object Model）ブラウザが変換

Copyright © 2015 every, Inc. All rights reserved. 12 CSS（Cascading
Style Sheets）：DOMツリーの各要素に対して色・サイズなどのスタイルを適用 CSSとは？前置き基本ルールセレクター｛プロパティ：値；｝（どこの）（何を）（どうする） CSSOMツリーとして理解

Copyright © 2015 every, Inc. All rights reserved. 13 JavaScript：クリックや入力をきっかけにDOMツリーを直接変更
（操作）することが可能 JavaScriptとは？ Webページの成り立ち

Copyright © 2015 every, Inc. All rights reserved. 14 DOMツリーとCSSOMツリーからレンダリングツリーを形成（各表示要素の計算に使用）
ブラウザの表示の仕組み：レンダリングツリーの構築 Webページの成り立ち DOMツリー CSSOMツリーレンダリングツリー画面に表示されない要素は含まれない（ ex. meta, head）

Copyright © 2015 every, Inc. All rights reserved. 15 レンダリングツリーの各ノードの位置と大きさを計算
ex. 「見出しを画面上部に配置して、その下に本文を置く」といった座標とサイズの計算をするブラウザの表示の仕組み：レイアウト Webページの成り立ちレンダリングツリー

レイアウトで決まった情報を元にピクセルを塗る処理を行う（文字色・背景色などを描画） • その後、レイヤー合成をされて最終的に画面に表示されるブラウザの表示の仕組み：ペイント Webページの成り立ち

ブラウザが表示するHTMLはどこから取得できるのか

Copyright © 2015 every, Inc. All rights reserved. 18 Webサイトを訪問すると、ブラウザが
HTML を元にページを描画するしかし、肝心の HTML のソースは手元にはない・・・＝＞「どこか」から HTML をブラウザまで届ける必要がある 🧐 ブラウザが表示する HTMLはどこから取得できるのかブラウザで https://delishkitchen.tv/ にアクセスすると、以下の画面がブラウザで表示される

Copyright © 2015 every, Inc. All rights reserved. 19 ブラウザが表示する
HTMLはどこから取得できるのか「サーバー」が HTML をブラウザに渡すブラウザ（クライアント）は、 HTML を取得するためのリクエストを送信する →サーバーがクライアントからのリクエストを受け取って、レスポンス (HTML)をブラウザに返す（クライアント／サーバーシステムの一種）第2章で登場したHTTPを用いて通信 GET “https://example.com/” ステータスコード：200, OK

Copyright © 2015 every, Inc. All rights reserved. 20 サーバーが
HTML を返す方法① リクエストを受け取るたびに静的 HTML を返すブラウザが表示する HTMLはどこから取得できるのか〜静的サイト〜イメージ ※実際のDK webの構成とは異なる部分がありますブラウザサーバー GET https://delishkitchen.tv/

HTML を返す方法① リクエストを受け取るたびに静的 HTML を返すブラウザが表示する HTMLはどこから取得できるのか〜静的サイト〜　イメージ ※実際のDK webの構成とは異なる部分がありますブラウザサーバー GET https://delishkitchen.tv/ HTML 画面描画

HTML を返す方法① リクエストを受け取るたびに静的 HTML を返すブラウザが表示する HTMLはどこから取得できるのか〜静的サイト〜イメージ ※実際のDK webの構成とは異なる部分がありますブラウザサーバー GET https://delishkitchen.tv/ 「材料から探す | 豚肉」をクリック GET https://delishkitchen.tv/categories/458 HTML 画面描画

HTML を返す方法① リクエストを受け取るたびに静的 HTML を返すブラウザが表示する HTMLはどこから取得できるのか〜静的サイト〜イメージ ※実際のDK webの構成とは異なる部分がありますブラウザサーバー GET https://delishkitchen.tv/ 「豚肉のレシピ」ページへ遷移 GET https://delishkitchen.tv/categories/458 静的HTML① 静的HTML② 画面描画画面描画

HTML を返す方法① リクエストを受け取るたびに静的 HTML を返すブラウザが表示する HTMLはどこから取得できるのか〜静的サイト〜イメージ ※実際のDK webの構成とは異なる部分がありますブラウザサーバー GET https://delishkitchen.tv/ 「豚肉のレシピ」ページへ遷移 GET https://delishkitchen.tv/categories/458 静的HTML① 静的HTML② 画面描画画面描画 HTML はページごとに異なる

外部データソースを利用した動的なレンダリング

Copyright © 2015 every, Inc. All rights reserved. 26 外部データソースを利用した動的なレンダリング
〜動的サイト〜サーバーが静的な HTML を返す方式は、自由度が低くなってしまう

HTML を返す方法② リクエストを受け取るたびに動的にレンダリングした HTML を返す外部データソースを利用した動的なレンダリング〜動的サイト〜イメージ ※実際のDK webの構成とは異なる部分がありますブラウザサーバー GET https://delishkitchen.tv/ DB 外部データソース

HTML を返す方法② リクエストを受け取るたびに動的にレンダリングした HTML を返す外部データソースを利用した動的なレンダリング〜動的サイト〜イメージ ※実際のDK webの構成とは異なる部分がありますブラウザサーバー GET https://delishkitchen.tv/ DB 外部データソース SELECT おすすめレシピ動画結果

HTML を返す方法② リクエストを受け取るたびに動的にレンダリングした HTML を返す外部データソースを利用した動的なレンダリング〜動的サイト〜イメージ ※実際のDK webの構成とは異なる部分がありますブラウザサーバー GET https://delishkitchen.tv/ HTML 画面描画 DB 外部データソース埋め込み SELECT おすすめレシピ動画結果

HTML を返す方法② リクエストを受け取るたびに動的にレンダリングした HTML を返す外部データソースを利用した動的なレンダリング〜動的サイト〜イメージ ※実際のDK webの構成とは異なる部分がありますブラウザサーバー GET https://delishkitchen.tv/ 「豚肉のレシピ」ページへ遷移 GET https://delishkitchen.tv/categories/458 画面描画 DB 外部データソース SELECT おすすめレシピ動画結果 HTML 埋め込み

HTML を返す方法② リクエストを受け取るたびに動的にレンダリングした HTML を返す外部データソースを利用した動的なレンダリング〜動的サイト〜イメージ ※実際のDK webの構成とは異なる部分がありますブラウザサーバー GET https://delishkitchen.tv/ 「豚肉のレシピ」ページへ遷移 GET https://delishkitchen.tv/categories/458 画面描画 DB 外部データソース SELECT おすすめレシピ動画 SELECT 豚肉レシピ動画結果結果 HTML 埋め込み

HTML を返す方法② リクエストを受け取るたびに動的にレンダリングした HTML を返す外部データソースを利用した動的なレンダリング〜動的サイト〜イメージ ※実際のDK webの構成とは異なる部分がありますブラウザサーバー GET https://delishkitchen.tv/ 「豚肉のレシピ」ページへ遷移 GET https://delishkitchen.tv/categories/458 HTML 画面描画画面描画 DB 外部データソース埋め込み SELECT おすすめレシピ動画 SELECT 豚肉レシピ動画結果結果 HTML 埋め込み

バックエンドとフロントエンド

Copyright © 2015 every, Inc. All rights reserved. 34 多くのWebアプリケーションはだいたい次のような構成になっている
• ブラウザ • Webサーバー • APIサーバー • データベース主な登場人物バックエンドとフロントエンドブラウザ Webサーバー APIサーバーデータベース

Copyright © 2015 every, Inc. All rights reserved. 35 多くのWebアプリケーションはだいたい次のような構成になっている
• ブラウザ • Webサーバー • APIサーバー • データベース主な登場人物バックエンドとフロントエンドブラウザ Webサーバー APIサーバーデータベースフロントエンドバックエンド

Copyright © 2015 every, Inc. All rights reserved. 36 フロントエンド
• 見た目の部分 • UI/UX バックエンド • 必要なデータの保存、整形、返却それぞれの役割バックエンドとフロントエンドブラウザ Webサーバー APIサーバーデータベースフロントエンドバックエンド

責務が違う ◦ フロントエンド：見た目に集中 ◦ バックエンド：データの処理に集中 • 柔軟性 ◦ 元々Pythonで書かれていたAPIサーバーをGoで書き換える、でもWebサーバーはそのまま ◦ Web用に作られていたAPIサーバーをモバイルでも使えるようにするこの辺りは「アーキテクチャ」の説明でより詳しく説明しますなぜ分けるのか？バックエンドとフロントエンドブラウザ Webサーバー APIサーバーデータベースフロントエンドバックエンド

フロントエンド

MPA, SPA • SSR, CSR • 使われている言語、フレームワーク • DOM • 非同期処理 • APIとの通信目次フロントエンド

MPAとSPA

複数のページからなる • ページ遷移のたびにサーバーへリクエストを送る • サーバーは完成したHTMLをレンダリングして返す • 2000年代前半以前のWebアプリケーションでよく見られた MPA(Multiple Page Application) フロントエンドブラウザサーバー ①ページ訪問レンダリングされた HTML HTML ②リンククリック

Copyright © 2015 every, Inc. All rights reserved. 42 メリット
• 初回ロードが軽い • SEOに強いデメリット • ページ遷移のたびにフルリロードを行う → UXが良くない • CSSやJavaScriptなどの共通リソースを毎回読み込む必要があり、パフォーマンス面でオーバーヘッドが生じる MPAのメリデメフロントエンド

JavaScriptを使って動的に更新 • ルーティングはブラウザ側で行われる • History API ◦ ブラウザのセッション履歴を管理する Web API (Web APIについては後述) ◦ リロードせずとも、ブラウザの「戻る」「進む」ボタンが使える • レンダリングもJavaScriptで動的に行う • 2010年代前半 SPA(Single Page Application) フロントエンドブラウザサーバー空のHTML + JavaScriptファイル HTML レンダリング ①ページ訪問

Copyright © 2015 every, Inc. All rights reserved. 44 メリット
• ページ遷移が高速 • • バックエンドとフロントエンドが分けやすい（UIとリソースの分離）デメリット • SEOに弱い • 初回ロードが重くなりやすい • JavaScriptがクライアント側で肥大化しがち→パフォーマンスの悪化 SPAのメリデメフロントエンド

Copyright © 2015 every, Inc. All rights reserved. 45 CSR
(Server Side Rendering) • HTMLとJavaScriptがブラウザに送られてレンダリング • 典型的なSPAはこっち SSR (Client Side Rendering) • サーバーでレンダリング済みのHTMLを返す • 典型的なMPAはこっち SPAも初期表示だけ SSRを採用すれば、デメリットを補える！最近のフレームワークは大体CSR, SSRどちらにも対応している CSRとSSR フロントエンドブラウザサーバー ①ページ訪問レンダリングされた HTML HTML ②リンククリックブラウザサーバー空のHTML + JavaScriptファイル HTML レンダリング ①ページ訪問

使われている言語・ライブラリ・フレームワークなど

Copyright © 2015 every, Inc. All rights reserved. 47 言語
• HTML • CSS • JavaScript • TypeScript (JavaScriptに型システムを入れたもの) ライブラリ • React • Vue フレームワーク（どちらもSSRに対応） • Nextjs • Nuxtjs 主な言語・ライブラリ・フレームワークフロントエンド

JavaScriptのランタイム環境 • Google Chromeと同じV8エンジンを採用 • JavaScriptをサーバーサイドで実行可能 • fsモジュールなどでファイルの読み書きもできる（サーバーならでは） npm • Node.jsのパッケージ管理ツールランタイム環境は他にもBunやDeno、パッケージ管理ツールはyarnやpnpmなど色々ある Node.js フロントエンド

Copyright © 2015 every, Inc. All rights reserved. 50 DOMとは
フロントエンド • DOM (Document Object Model) ◦ HTMLやXMLドキュメントの構造、操作を定義したもの • DOMツリー ◦ DOMから作られる木構造のオブジェクト JavaScriptはこのDOMを操作して画面の更新を行う

実際のDOMの軽量コピーをメモリ上に持つ仕組み • VueやReactなどで用いられる • 差分を計算し最小限の変更のみを実際のDOMに適用、同期する → JavaScriptとDOMの中間レイヤーとして仮想DOMを挟むことで、実DOMを効率的に操作できる！仮想DOM フロントエンドメモリ上で差分を計算実際のDOM に反映

jQuery時代 ◦ .addClass()や.append()など、命令的にDOMを直接いじる ◦ 「こうして、ああして」の処理を書いていくので、状態が追いづらい • ReactやVueなど、宣言的なフレームワークの登場 ◦ 「今の状態はこう」と宣言的に UIを記述できる ◦ 宣言したものを全て再描画していたらコストが高すぎる →差分の計算の必要性が高まり、仮想 DOMが導入された仮想DOMが出てきた背景フロントエンド

JavaScriptの非同期処理

Copyright © 2015 every, Inc. All rights reserved. 54 ↔
同期処理 : 複数のタスクを実行する際に順に実行されるファイル操作やAPIリクエストのような重いタスクを実行する際に、処理をバックグラウンドに移すことでタスクの処理を止めることなく別のタスクを実行できる → JavaScriptエンジンはシングルスレッド　これのみでは非同期処理は実現できないので他の仕組みを利用している！非同期処理とはフロントエンド

Copyright © 2015 every, Inc. All rights reserved. 55 ブラウザでの非同期処理
Web APIを用いることで非同期処理を実現している Web APIの例 • fetch api • storage api • DOM ブラウザは複数のスレッドを持っており、メインスレッドとブラウザのスレッドに分けられる 1. メインスレッドから非同期処理を呼び出す 2. Web APIが呼び出される 3. Web APIがブラウザのスレッドで実行される 4. 完了後コールバックがタスクキューに追加される 5. メインスレッドが空くとコールバックがメインに移動し実行されるフロントエンドメインスレッド（コールスタック） Web API タスクキュー非同期処理イベントループ監視非同期処理コールバック 1 2 3 コールバックコールバックコールバック 4 5

再読み込みをせずに画面の状態を変えられる • 例：Google Mapの移動 • 今まで散々上のことについて喋ってきたが、当時はすごいことだった参考： Ajax (Asynchronous JavaScript and XML) • JavaScriptを使った非同期処理の技術 • 現在はあまり使われていない • XMLHttpRequestを使ったHTTP通信 • 初期のGoogle Mapに使われた • 直接DOM変更を行う非同期処理は何が偉いのか？フロントエンド

APIとの通信

Copyright © 2015 every, Inc. All rights reserved. 58 動的コンテンツや負荷の高い処理、外部システムの利用などF/Eで完結できないことが多い
• レシピデータやユーザーデータなどの動的なコンテンツはDBに保存されている • 画像の加工やDBから取得したデータの操作など負荷の高い処理はB/Eが行う • 認証認可などの複雑な処理は自作したくない APIとの通信フロントエンド

Copyright © 2015 every, Inc. All rights reserved. 59 動的コンテンツや負荷の高い処理、外部システムの利用などF/Eで完結できないことが多い
• レシピデータやユーザーデータなどの動的なコンテンツはDBに保存されている • 画像の加工やDBから取得したデータの操作など負荷の高い処理はB/Eが行う • 認証認可などの複雑な処理は自作したくない → APIを呼び出すことで上記の問題を解決する ! APIとの通信フロントエンド

Copyright © 2015 every, Inc. All rights reserved. 60 API通信フロー
リクエストの作成・送信 • url, method, parameterなどを指定してリクエストを送信するレスポンスの受信 • status codeやbody(jsonなど)を受け取るデータの利用 • レスポンスを元に状態やDOMの更新を行うこれらの処理はfetchやaxiosなどの非同期通信を用いるフロントエンド

バックエンド

データの処理 • ビジネスロジック • API • 認証・認可 • 使われている言語、フレームワーク目次バックエンド

データの処理

外部ソースからデータを取得しフロントエンドに返す • フロントエンドから来たデータを外部ソースに永続化したり送ったりする基本的にはこの2つだけ基本的な役割バックエンドバックエンドサーバー外部データソースサーバークライアント外部データソースから見るとバックエンドサーバーがクライアント

データベース ◦ RDB ▪ MySQL ▪ PostgreSQL ◦ NoSQL ▪ DynamoDB ▪ MongoDB • キャッシュ ◦ オンメモリキャッシュ ◦ リモートキャッシュ ▪ Redis ▪ Amazon ElastiCache • 外部API ◦ 認証や課金用のAPI ◦ 企業が提供するAPI • クラウドストレージ ◦ Amazon S3 ◦ Google Cloud Storage 外部ソースの例バックエンド

ビジネスロジック

外部からデータを取得しフロントエンドに返す • フロントエンドから来たデータを外部に永続化したり送ったりする基本的にはこの2つだけ基本的な役割バックエンドバックエンドサーバー外部データソースサーバークライアント外部データソースから見るとバックエンドサーバーがクライアント

外部からデータを取得し（整形して）フロントエンドに返す • フロントエンドから来たデータを（整形して）外部に永続化したり送ったりする基本的にはこの2つだけ基本的な役割バックエンドバックエンドサーバー外部データソースサーバークライアント外部データソースから見るとバックエンドサーバーがクライアント

Copyright © 2015 every, Inc. All rights reserved. 69 （雑に言うと）アプリケーション特有の整形、バックエンドサーバーの中核の役割
• ECサイト：注文金額が5000円以上なら送料を無料にする • SNS：フォローしていない人の投稿は表示しない • 予約サイト：前日になったらキャンセルできないなど。これはフロントエンドに書かないレスポンスのための整形 • 日付のフォーマット • DBには1がiOS、2がAndroidとして保存されているのを、stringに変換するなどはビジネスロジックではないが、少なくとも後者はバックエンドサーバーで実装すべきことビジネスロジックバックエンド

プログラムにとってのインターフェース • Webアプリケーションで使われるほとんどのAPIは以下のどちらかの形式のデータを返す ◦ JSON ◦ XML API (Application Programming Interface) バックエンド

Copyright © 2015 every, Inc. All rights reserved. 72 ヘッダ
• Content-Type：レスポンスの種類 • Authorization：認証情報 • Cache-Control, Expires：キャッシュに関する情報 • Last Modified：最後に更新された日時リクエスト種類 • GET：取得 • POST：作成 • PUT：（全体）更新 • PATCH：（一部）更新 • DELETE：削除 HTTPリクエストバックエンド

よく使われるAPIの設計手法 • 次の6つの条件を満たす ◦ クライアント／サーバー (Client-Server) ◦ ステートレス (Stateless) ◦ キャッシュ (Cache) ◦ 統一インターフェース (Uniform Interface) ◦ 階層システム (Layered System) ◦ オンデマンドのコード (Code-On-Demand) 例： /users/1 → ユーザー情報 /users/1/orders → 注文履歴 REST API バックエンド

比較的新しい設計手法 • Facebookが開発したOSS • 必要なデータをクエリで指定できる • 一度に複数のデータを取得できる例： query { user(id:1){ name, orders } } → クエリで複数のデータを取得 GraphQL バックエンド

認証・認可

認証（Authentication） ◦ ユーザーが本人であることを証明する仕組み • 認可（Authorization） ◦ ユーザーに対して、アクセスできるリソースや操作を制御する仕組み似てるけど別物例：特定のCIDRからだけアクセスを許可する（認証はしてないけど認可はしている）認証・認可バックエンド

認可のための仕組み • アクセストークンを使って、自分の認証情報を第三者のアプリケーションに渡すことなく、捜査の許可をする • 代表的なフローはAuthorization Code Flow (複雑なので各自調べてください) 例：あるアプリがGoogleカレンダーに予定を書き込みたいとき、ユーザーがGoogleログインして承認すると、アクセストークンを使ってカレンダーへの書き込みを行う OAuth2.0 バックエンド

OAuthの拡張仕様 • アクセストークンに加えてIDトークン(JWT)も渡すことで、認可と同時に認証も行う例：SSO（シングルサインオン） OpenID Connect バックエンド

アーキテクチャ

Copyright © 2015 every, Inc. All rights reserved. 80 アーキテクチャとは
アーキテクチャとは →システムを構築するための設計思想や構造

Copyright © 2015 every, Inc. All rights reserved. 81 アーキテクチャの目的
アーキテクチャの目的 • システム構造の明確化 • システムの保守性、拡張性の向上 • 再利用性の向上

Copyright © 2015 every, Inc. All rights reserved. 82 システム構造の明確化
アーキテクチャの目的システム全体の見通しを良くし、開発者間で共通の理解を持つことができる → システム全体を把握せずとも、特定の部分を効率的に開発したり修正したりすることができる

アーキテクチャの目的例. MVCを用いた場合 • Model : ビジネスロジックを管理する。データベースや外部APIからデータ取得・保存を行う • View : ユーザーに情報を表示する部分。画面のレイアウトなどのインターフェースを提供する • Controller : ユーザー入力を受け取り、ModelやViewに伝える。 View Controller Model

アーキテクチャの目的 Q. 「入力フォームの位置を変えてほしい」どこを修正すれば良い？ A. View → ModelやControllerなどでどのような実装がされているか完全に把握する必要がない！ View Controller Model

保守性 : システムの修正や更新する際の容易さ • コードの分割やテスト可能な設計を行うことで向上する ◦ 責務を明確にし最小限にすること(SRP Single Responsibility Principle) ◦ 重複したコードを減らす(DRY Don’t Repeat Yourself) アーキテクチャの目的

アーキテクチャの目的拡張性 : システムに新しい機能を追加する際の容易さ • 設計の柔軟性が高く、変化に対応しやすいことが求められる ◦ オープン・クローズドの原則(OCP)に基づいた設計 ◦ 将来の変更を想定した構造化 ▪ インターフェースの汎用化 ▪ 例 REST APIなど

アーキテクチャの種類

Copyright © 2015 every, Inc. All rights reserved. 92 アーキテクチャの分類
B/E 層ベースのアーキテクチャ Layered Architecture Clean Architecture Hexagonal Achitecture ドメイン中心アーキテクチャ DDD 分散システムアーキテクチャ Microservice Architecture Event-Driven Architecture

Architecture: クイズ1 B/E - 層ベースのアーキテクチャシナリオ：レシピデータをMySQLに保存する問題：「ライブラリを使用してSQL INSERT文を実行する」処理はどの層に実装すべきですか？ A. User Interface層（フォーム送信処理の一部として） B. Business Logic層（レシピ作成ロジックとして） C. Data層（データアクセス抽象化として） D. Infrastructure層（SQL実行の技術的実装として）

Architecture: クイズ2 B/E - 層ベースのアーキテクチャシナリオ：レシピ検索結果を返す実装を行うが、以下のルールを適用させたい • ユーザーがプレミアム会員の場合、お気に入りレシピを上位3件に表示 • 通常会員の場合、お気に入りレシピに「★」マークを付けるだけ • 残りは人気順でソート問題：この「お気に入りレシピの表示順制御」ロジックはどの層に実装すべきですか？ A. User Interface層（画面表示のレイアウト制御として） B. Business Logic層（ビジネスルールの実装として） C. Data層（データ取得時のソート処理として） D. Infrastructure層（キャッシュシステムの一部として）

Copyright © 2015 every, Inc. All rights reserved. 96 Clean
Architecture B/E - 層ベースのアーキテクチャ • Entities(ビジネスロジック)を中心に設計 • それぞれの層の依存関係を外→内に明確化 • フレームワークやインフラ(DB等)に依存しない状態にすることで変更や拡張に強い https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

Copyright © 2015 every, Inc. All rights reserved. 98 Microservice
Architecture B/E - 分散システムアーキテクチャ A B C D A B C D User Interface User Interface • アプリケーションを、独自の責任範囲を持つ独立した小さな部分に分割 ◦ 例. 全社共有の認証機能を認証サービスとして独立させる • 大規模システムやスケーラブルなシステムで利用 • 各サービスの管理コストが増加してしまうデメリットもある従来の設計マイクロサービスアーキテクチャ

テスト

Copyright © 2015 every, Inc. All rights reserved. 105 ソフトウェアエンジニアリングにおけるテスト
(test)とは？テストソフトウェアテストは、欠陥を発見し、ソフトウェアアーティファクトの品質を評価するための一連の活動テストでは指定されている要件をシステムが満たすかどうかの確認（検証）に加えて、ユーザーやその他のステークホルダーのニーズを運用環境でシステムが満たしていること（妥当性）を確認 JSTQB テスト技術者資格制度 Foundation Level シラバス Version 2023V4.0.J02 | 1.1 テストとは何か？より抜粋

静的テスト（プログラムの実行を伴わないテスト） ◦ 静的解析 ▪ タイプミスや型エラーがないかなどを確認する ▪ コードレビュー ▪ etc. • 動的テスト（プログラムの実行を伴うテスト） ◦ ユニットテスト ◦ 結合テスト ◦ システムテスト ◦ E2Eテスト ◦ 受け入れテストテストのスコープ良いコードを書くために

ブラックボックステスト ◦ 仕様に基づく手法。内部構造は気にせず振る舞いをテストする。 ◦ 利用者視点のテスト ▪ 境界値分析 ▪ 同値分割法 ▪ etc. • ホワイトボックステスト ◦ 構造に基づく手法。内部構造や処理を流れをテストする。 ◦ 作成者視点のテスト ▪ ステートメントテスト ▪ ブランチテスト ▪ etc. テスト手法良いコードを書くために

case.1 テスト b = 0 のとき、ゼロ除算でランタイムエラー

case.1 テスト仕様：税額は「円未満切り捨て」実装：四捨五入（math.Round）しており、1円多く請求するケースがある（107 x 1.08 = 115.56 → 115円が実際は正しいが、上記コードでは 116円になり多く請求してしまう）

case.2 テスト User オブジェクトのプロパティconcern が初期化されていない → panic になる

CI (Continuous Integration, 継続的インテグレーション) • CD (Continuous Delivery/Deploy, 継続的デリバリー／デプロイ) CI/CDとは？ CI/CD https://circleci.com/ja/blog/what-is-ci-cd/

CI (Continuous Integration, 継続的インテグレーション) ◦ 自動で作業成果物をテストしてリポジトリに共有する ◦ 開発者のコード作成に関与する • CD (Continuous Deploy, 継続的デプロイ) ◦ 自動で作業成果物を運用システムに反映させる ◦ 完成したコードに関与する CI/CDの目的・意義 CI/CD

lint ◦ ソースコードの静的解析 • format ◦ ソースコードのフォーマッティング • test ◦ ソースコードのテスト CIで使っている解析ツール例 CI/CD

デプロイ ◦ EC2のデプロイ ◦ ECSサービス／タスクのデプロイ ◦ Lambda Functions のデプロイ ◦ フロントエンドのビルド成果物を S3 にプッシュする ◦ etc. CDのユースケース CI/CD

エブリーで利用されているもの ◦ GitHub Actions ◦ Circle CI ◦ CodeBuild(AWSのCI/CD自動化サービス) • その他 ◦ Jenkins ◦ etc. CI/CDツールの紹介 CI/CD

開発者向けのウェブ技術 | MDN • レンダリングの仕組み | Vue.js • TypeScript誕生の背景 | TypeScript入門『サバイバルTypeScript』 • Actions | GitHub • AWS CodeBuild（継続的スケーリングによるコードのビルドとテスト） | AWS • Jenkins • Clean Coder Blog • Atomic Design by Brad Frost • CI/CD とは？開発に欠かせない理由と必要性を解説 • AWS シンプルアイコン - AWS アーキテクチャーセンター | AWS • Dissecting layered architecture - DEV Community • マイクロサービスアーキテクチャとは | Google Cloud • マイクロサービスとは？そのメリットを簡単に解説（初心者・非エンジニア向け） - NCDC株式会社参考・引用

【研修資料】Webアプリケーション開発基礎

【研修資料】Webアプリケーション開発基礎

More Decks by エブリー

Featured

Transcript