JavaScript:オブジェクト指向らしい記述をする

JavaScriptではオブジェクト指向がサポートされています。
JavaやC#に触れている方であればお馴染みだと思いますが、オブジェクト指向を用いることで規模が大きいプログラムを作る時の生産性が向上します。

以下では、インスタンス生成と、ポリモーフィズム(複数のサブクラスを同じように使う)を試してみます。
Node.jsを使用して実行します。
(ES2015以降の書き方となります)

【サンプルコード】

・test.js

【実行結果】


ちなみに、ES2015より前のバージョンではこの書き方はできません。
オブジェクト指向をプログラム言語で実現する上で、「クラスベース」と呼ばれる概念と「プロトタイプベース」と呼ばれる概念があるのですが、ES2015より前のバージョンでは「プロトタイプベース」と呼ばれる概念に基づく書き方をする必要があります。
JavaやC#は「クラスベース」と呼ばれる概念に基づく書き方をするので、JavaやC#の経験者にとってはとっつきにくいと思います。

なお、ES2015以降はクラスベースに基づく書き方が可能になっていますが、内部的にはプロトタイプベースに基づく処理をしています。
例えば、クラス名の型を調べると、”class”ではなく”function”になるのですが、これはプロトタイプベースの名残です。


いかがでしたでしょうか?

規模の大きいプロジェクトでは、一般的にオブジェクト指向で設計されています。
大抵の場合は何かしらのフレームワークが採用されており、classの存在を意識することはないかもしれません。
しかし、基本的にはそのフレームワークもオブジェクト指向で設計されているので、JavaScriptでもオブジェクト指向をサポートしていることは知っておいて損はないと思います。

Vue.jsインストール手順とHelloWorld(Windows、2020年12月)

Vue.jsとは、JavaScriptのGUIのフレームワークです。
MVVM(Model-View-ViewModel)を採用しており、画面(View)と内部状態(Model)を分離して画面の制約にとらわれないようにすることで、画面で入力された内容をリアルタイムに内部状態に反映させたり、内部状態の変化をリアルタイムに画面に出力したりすることができます。
この特徴により、画面をリッチにすることができます

今回は、WindowsOSのPCにインストールし、実行確認をする手順を掲載します。
実行確認の「Hello World」に関しては色々書き方がありますが、今回はMVVMの良さを実感できる書き方で「Hello World」を試します。

■前提

・OS

Windows8.1

・実施日

2020年12月30日

・Vue.jsのバージョン

2.6.12

■インストール手順

1.Vue.jsの公式サイトにアクセスする。

https://jp.vuejs.org/index.html

2.「はじめる」を左クリックする。

3.「インストール」を左クリックする。

4.「開発バージョン」を右クリックし「名前を付けてリンク先を保存」をクリック。

※FireFoxの場合。リンク先はjsファイルなので、ブラウザの機能でファイルとして保存する。

5.任意のフォルダにvue.jsを保存。

※今回は”C:\tmp”に保存。

■実行確認(Hello World)手順

1.”vue.js”を保存したフォルダに、”hello.html”という名前のファイルを作成する。

2.「hello.html」に下記を入力して保存。

3.「hello.html」をブラウザから開く。

※今回はChromeで開きます。

初期状態では以下のように何も表示されませんが

チェックボックスをチェックすると「Hello World!」と表示されます。
ボタンをクリックしてイベントを飛ばしたり、リロードしたりすることなく、画面で変更された内部状態をリアルタイムに画面上に反映することができています。


いかがでしたでしょうか。

今回はHelloWorldのみでしたが、これだけでもVue.jsの便利さを実感できたのではないかと思います。
Vue.jsは日本語の公式ドキュメントも充実しているため、その意味でもお勧めのフレームワークです。

ゴンペルツ曲線(信頼度成長曲線)とは

ゴンペルツ曲線(信頼度成長曲線)とは、テストで発見されるバグ数をグラフにしたものです。
横軸に時間、縦軸に累積バグ数をとる場合、下記のようなグラフになります。

テストを開始した直後は、テスト手順が確立していないため、バグはなかなか見つかりません。
テスト手順が確立した後は、時間が経つにつれて順調にバグが見つかります。
テストが終盤に近づくと、残っているテストケースはテスト困難なレアケースになるので、再びバグを見つけにくくなります。

具体的にいくつのバグが出るかは、プロジェクトの特性によって変化します。
現場毎に、プロジェクトの規模と発見されるバグ数の統計を取り、その統計を元にいくつのバグが出るのかを具体的な数値に落とし込みます。

もし、バグが大量に見つかる(aのケース)ようであれば、テスト開始時点の品質が悪い疑いがあります。
この場合、品質管理者は、バグの原因を確認し、前工程で見つけるべきバグが大量に見つかっていないかどうかを見る必要があります。
前工程で見つけるべきバグが大量に発見された場合は、バグの対応でテストの進捗が悪くなることを防ぐために、もう一度前工程に戻って品質強化を行う必要があります。

また、発見されるバグが少ない(bのケース)ようであれば、テストケースの作り込みが甘い疑いがあります。
この場合、品質管理者は、テストに使われているテストケースを確認し、テストの目的に照らし合わせてテストケースの網羅性が十分かを見る必要があります。
テストケースの網羅性が不十分な場合は、現在のテスト工程で見つけるべきバグが見つからないことにより次工程やリリース後に悪影響を及ぼすのを防ぐため、テストケースの修正を指示する必要があります。

品質管理者には成果物の一つ一つを細かく見る程の時間はないため、上記のような数値管理を行い、プロジェクトの状況を把握しようとします。
(人間の体に例えると、健康診断で数値を出し、疑わしい数値が出た場合に医師が検査を行う、という例えになります)
そのため、作業者としては、正直に数値を出すことで、品質管理者が適切に管理を行えるようにする必要があります。


あけましておめでとうございます!

昨年、何のためにバグ数を報告する必要があるのかと問われたので、今回の記事を執筆しました。
作業者目線では報告はうんざりするかもしれませんが、プロジェクトを円滑に進めるためだということを知っていれば、頑張って報告する気になれると思います。

実は昨年は適当に報告してしまっていた…という方、新年は是非報告も頑張ってみましょう!