テスト
フロントエンドでは
- 単体テスト
- 結合テスト
というお話をしてきましたが。
バックエンドでは、３つ説明していきます。
- 単体テスト
- 結合テスト
- 機能テスト
単体テスト
例えば、皆さんが野菜を切ると言ったプログラミングを書いたとき。
この事をモジュールと言います。
このモジュールの動作を確認するテストを単体テストと呼びます。
結合テスト
１つ１つのプログラムを結合したときにちゃんと作動するのか確認する。
機能テスト
実際のユーザーが使う手順で使って見てプログラミングが動くかどうかの確認
単体テスト／結合テスト／機能テスト
それぞれをJavaで作ったときに使えるツールの紹介
単体テストでは、
JUnint
結合テスト
JUnint
機能テスト
手打ちでやっても良いが、アップデートのたびに手打ちは大変なので、ここも自動化してください。
Selenium
ブラウザををプログラムで自動操作してくれるツール。
操作結果の検証／確認を自動で行ってくれる。
どんなプログラムにもバグがある。
テストをしないエンジニアはダメです！なので、皆さん必ずプログラミング書いた後はテストをするという事をしてください。
CI/CD
CI=Continuous Integration(継続的インテグレーション)
CD=Continuous Delivery(継続的デリバリー)
CI=Continuous Integration(継続的インテグレーション)
アプリケーションリポジトリ管理ツールにコミット（完了）した。
次にまた機能を直してコミットしました。
Aさん、Bさん、Cさんもコミットしましたと。
この３人が事前にテストをしてくれていたら問題ないんですよ。しかし、人が増えると忘れてしまいますよね？
忘れたときその忘れたまま世の中にサービスを出してしまったら、バグが発生するかもしれない。
なので、CIという仕組みは、このリポジトリ管理ツールにプログラムが登録されたら。
自動で、テストし、開発者に結果を返す
複数人での開発だとすぐ忘れてしまう。
CD=Continuous Delivery(継続的デリバリー)
CIでテストをしてOKになりましたと。
OKになったら、自動的に世の中に公開して欲しいですよね？問題ないから。
この公開の作業を自動でやってくれる仕掛けのことをCDと呼びます。
CDというのは、色んな手順が必要なんですよ。
この手順の中で、またミスが発生してサーバーが落ちてアクセスできないとかよくあるんですね。
なので、公開までの手順も全て自動化。
CI/CDを一からやろうとしたら無理です。
なので、便利なツールがございます。
CircleCI
CIと書いていますが、CDもできます。GitHubとも連携できます。
アーキテクチャー
犬小屋を作る場合は、専門的な知識は不要。
大きなビルを作る場合は、闇雲に作業しては壊れてしまう。
大きな開発に必要なのが、アーキテクチャー／設計原則です。
大きなアプリケーションになると必ずアーキテクチャーや設計原則がないと。
Aを直すとBにバグが発生。Bを直すとCにバグが発生など。
スパゲッティコードと言われることになります。
そうならないために、アーキテクチャー／設計原則を学ぶ必要があります。
アーキテクチャー
モノリシックアプリケーション
マイクロサービスアーキテクチャー
SOA
サーバーレスアーキテクチャー
モノリシックアプリケーション
モノリシック＝一枚岩
アプリケーションを１つの大きなプログラムとして作る。
このやり方に問題がるんじゃないか？と言われて出てきたのが
マイクロサービステクチャー
機能（業務）ごとにチームを分担して各機能で完結するようにプログラムを作る。
プログラム同士の会話は、APIを通じて会話をする。
そうするともしここに変更が欲しくなったとしても、APIのやり方さえ変わらなければ片方に影響はないという。
影響度の少ないプログラムができます。
サーバーレスアーキテクチャー
AWSなどのクラウド上のサービスでプログラムを作る。
ここまで聞いて皆さんは、マイクロサービスアーキテクチャーを使えば良いのでは？と思うかと思います。
ただですね、大きな弱点があります。
皆さんが開発する上では、使うべきではないと思っています。
さっき説明した通り、
機能Aと機能Bが分断されていてAPIで会話をするということをお伝えしました。
ただ、機能Aの仕様を決めるのは機能Aの人ですよね？
そうすると、機能Aの仕様を決めたとして、その後どうしても仕様を変更しないといけなくなったと。
それを機能Bの人に伝え忘れた場合どうなりますか？
全部バグになりますよね？
そういうリスクになるんですよ。
じゃあ
モノリシックアプリケーションの場合はどうなるかというと。
いつのプログラムの中で描かれるわけだから、プログラムの実行がそもそもできない状況になってコンパイルエラーと言うもので気づくことができるんですね。
プログラムを実行せずとも気づけると言うことで、モノリシックアプリケーションの方が硬いプログラムが作れると思います。
ただ、Googleのような大企業の場合、マイクロサービスアーキテクチャーの方が良いかと思います。
ただそうでなければ、モノリシックアプリケーションでプログラム実行前に問題に気づけるので良いかと思います。
設計原則
例えば、料理の例でいうと。シチューを作る場合
肉に味付けをつけておく
野菜の切り方の工夫
など原則が存在すると思います。
プログラムにもこのような原則があります。このことにより、修正が簡単になります。
今回紹介するのは４つになります。
SOLID
KISS
YAGNI
DRY
DRY
例えば、野菜を切ると言った場合。
初心者は、人参を切りたいので’人参を切る’というプログラムを書くんですよ。
その後に、玉ねぎを切りたいので、’玉ねぎを切る’TOいうプログラムWO書くと言った具合に別で書くんですね。
そうじゃなくて、できるプログラマーは。
初めは、人参を切るというプログラムを書くと思いますが。
その後、玉ねぎを切りたいとなった場合、’切る’ってプログラムを書くんですよ。
そこに’人参’なのか？’玉ねぎ’なのか？って渡してもらうプログラムを書くんですね。
そうすれば、コピペはないですよね？
コピペをしなくても汎用的なプログラムを作る。そうすれば、プログラムの量が少なくて済む。
プログラムを書かなくても、実現したいことがどんどん実現できる。
こういうことを、DRY原則と呼びます。
これを学んでくと、
コードがとても綺麗に、他人から見ても読みやすいことになります。
追加情報
検索エンジン
Googleは欲しい以上が一瞬で表示される。
これっていうのは、特別な仕掛けがあるわけで。
皆さんのWEBサービスももしかしたら、いっぱいデータが溜まった場合。
リレーショナルデータベースを使うだけでは、遅すぎて検索ができないという状況になるかもしれません。
その場合、検索エンジンを使う方法があります。
Elasticsearch
大量のデータの中から一瞬で検索結果を出してくれる。
コンテナ化
コンテナっていうのが、WEBの世界でもあります。
有名なものが、dockerというものです。
プログラムを動かす場合は、APサーバーであればアパッチが必要。
アパッチにはLinuxのOSが必要で
Linux OSの○○、△△をインストール
バージョンアップさせる
アパッチをインストールして
など色々やることがあるんですね。
これを毎回毎回やっていたら、それらの作業をまとめたものをdockerと呼びます。
dockerは、定義文としてファイルに書く。
”スタート”ってやると
全て自動的に設定しサーバーが出来上がる。
世の中で、今や必須のスキルとなっています。
作ったプログラムをどうやって公開するのか？
色々ともちろんやり方はあるんですが。
お金がかからず楽にできるということで、今回オススメを１つ紹介します。
heroku
herokuの良いのは、簡単にCDができるんですね。
GItHubにコミットしたら、herokuに自動的にデプロイされる仕組みをワンタップでできる。
しかも無料でできる。
プラグインを使えばデータベースが無料。
コメント