良いプログラムとは?
プログラム言語を学ぶとき、最初に文法や構文を習得していくことから始めます。最初のうちは、実際に動くプログラムを書くことが精一杯で、良いプログラムを書く余裕もなかなかありません。
プロとして仕事をするには、良いプログラムを書くという意識も必要です。
良いプログラムとは、そもそもどういうものか。どんなことに気を付ければ良いのか、ポイントをご紹介していきます。
正しく動くプログラム
ここでいう「正しく動く」とは「仕様どおりに動く」という意味です。プログラムの仕様とは、そのプログラムで網羅しなければならない内容のことです。
処理手順、処理内容、処理結果などが、それに該当します。 通常、仕様書(設計書)には、処理手順や処理内容が詳細に記述されています。
プログラミングの第一歩は、仕様どおりに動くプログラムを作成することです。
仕様どおりのプログラムを書くためには、どのようにすれば良いでしょうか。
仕様の理解
仕様どおりのプログラムを書くためには、まず、仕様を確実に理解することです。ユーザや設計者が求める要件を把握し、設計書の内容全てを漏れなく理解しましょう。
設計書をよく読むこと、ユーザもしくは設計者と十分にコミュニケーションをとることが必要です。
作業に着手する前に仕様を把握しておかなければ、不明確なことがあったとき都度確認する必要があり作業効率が悪くなります。
プログラミングの作業に入る前に、仕様を理解しておくことでミスや手戻りの作業を減らすことにも繋がります。
経験を積んでいくと、そのプログラムの業務的な背景を徐々に理解できるようになります。
仕様の不備や改善ポイントを発見したとき、適切に対処できるようになれば一人前のプログラマーと言えるでしょう。
技術と業務知識の習得
仕様の理解の他、仕様どおりにプログラムを書くためには、技術力と業務知識を身に付ける必要があります。自分が配属された(アサインと言います)システム開発案件(プロジェクトと言います)で求められる技術や業務知識は、その都度異なってきます。
例えば、汎用系システムの場合、プログラミング言語はCOBOLであったり、Web系システムの場合、プログラミング言語はJavaであったりします。
一方業務で言えば、銀行の外為業務だったり、製造業の生産管理業務であったりすることもあります。
プログラミングと言っても、様々な技術で様々な業務をシステム化するわけですから、プログラマーは大変な職種です。
良いプログラムを書くためには、高い技術力と豊富な業務知識が必要なので、日々の努力の積み重ねが大切です。
プログラムテストの実施
プログラム作業の後は、必ずプログラムテストを行います。プログラムが仕様どおりに処理されているかを、一つひとつ確認していく作業です。
見やすいプログラム
見やすいプログラムは、分かりやすく記述されているプログラムです。実際のプロジェクトはチームで行うため、他の人が見るという想定でプログラミングをしていく必要があります。
自分が作成したプログラムを後で修正する場合に、すぐに分かるように記述ができているでしょうか?
どのようにすれば、プログラムは見やすくなるのでしょうか。
コメントの記述
見やすいプログラムの要素として、コメントが適切に記述されていることが挙げられます。コメントとは、プログラムの中に記述する日本語注釈のようなもので、プログラムの要所要所で何の処理を行っているかを簡潔に記述します。
プログラムを追うことで、処理内容を把握できますが、日本語よりは理解するのに時間がかかります。
コメントがあるプログラムは、各処理の概要や要所の変数などが日本語で記述されているので、他の技術者が修正する場合にも分かりやすく、メンテナンス性の高いプログラムとなるのです。
インデントと改行
上級プログラマーなどの優秀なプログラマーが作成したプログラムは、どれもインデント(字下げのことで、左側文字の開始位置を一定の法則でずらすこと)や改行が施されていて、見た目も非常にきれいなものが多いです。これは一体何故でしょうか。インデントや改行を揃えて見やすく整えておくことで、プログラムの品質向上とメンテナンス性の向上に繋がるからです。
例えば、Javaで言うと、プログラムの中に括弧が多いので、きれいに書かないと始まりの括弧がどの終わりの括弧と組み合わせになっているかが分からなくなります。
数学と同じように、括弧の位置や括弧の対応にも意味があるので、間違ってしまうと思った処理結果が得られなくなってしまいます。
このようなことを未然に防ぐためにもインデントや改行を施し、間違わないように記述していくのです。
コメントと同様に見やすくしておけば、修正にかける時間も少なくできます。
プログラミング経験が浅いときはインデントや改行を入れずにプログラムを作成してしまいがちですが、最初から習慣にしておけば簡単に身につけられます。
変数名・メソッドなどの名称
変数やメソッドなどの名前を命名する場合、分かりやすいものにすることも重要です。後でプログラムを見直すときに、名前から内容が想像しやすいものにしておくことで間違いが起こりにくくなります。
無駄に長くなったり、意味不明な名前にならないようにしましょう。
プロジェクトによっては、変数名の付け方など命名規則が定義されていることもあります。
無駄のないプログラム構造
初心者には少しハードルが高く感じるかもしれませんが、プログラムの構造を複雑にし過ぎないことが重要です。同じ処理が何度も書かれているものや、無駄な変数を定義していると、不具合(バグと言います)が発生した場合、それを取り除くこと(デバッグと言います)に時間がかかったり、バグが出やすいプログラムになってしまいます。
作業に着手する前に処理構造を見定めてから始めると、バグが少なく無駄のないプログラムになります。
テストの重要性
プログラミングの工程が終わったら、テストを行って想定通りの動作をしているか確認します。テストをする前には、テストケースを考えてテスト仕様書を作成します。
テストケースを洗い出すときに大切なのが、仕様をきちんと理解できているかどうかです。
プログラムの品質を高めるためにも、テストは重要な工程になります。
テスト工程の種類
システム開発ではテストを段階的に行って、動作の確認を進めていきます。プログラムテスト
プログラムがプログラム設計書どおりに、正しく動いているかを確認します。システムは何人もの技術者が作成した、多くのプログラムによって構成されています。
プログラムテストは単体テストととも呼ばれ、その一つひとつのプログラムが、意図したとおりに動いているかを検証するものです。
実施にあたって、テストすべき項目(テストケースと言います)が記載されたプログラムテスト仕様書が必要になります。
テストケースはプログラム構造設計書に記述されている、全処理パターンが対象です。
すなわち、記述されたプログラムの全ルートをテストすることになります。
テスト実施には、データ(値)を与えないとテストができないケースが多くあります。
その場合、テストを実施するためのデータ(テストデータと言います)を事前に用意します。
例えば、オンラインショッピングのログイン画面プログラムテストの場合、最低限ユーザIDとパスワードをテストデータとして用意しておきます。
テスト仕様書とテストデータが作成できたら、テストを実施していきます。
作成したプログラミングに、バグが見つかるのは当たり前のことです。
経験を積んだプログラマーでも、1つもバグがないことはあり得ません。
テストを実施して1件もエラーがなかった場合、テストケースに漏れがないかを疑ってみましょう。
仕様をきちんと理解できていれば、テストケースやテストパターンの不備も見つけることができます。
テストの時点で見つかったバグは修正が可能なので、まずは恐れずにバグを見つけていきましょう。
結合テスト
結合テストは、プログラムテストの後に行われるテストで、いくつかのプログラムを組み合わせて、1つの機能として正しく動いているかを確認します。例えば、プログラム間のデータの受け渡しや、画面遷移が正しく行われているかなどを確認します。
システムテスト
システムテストは、結合テストの後に行われるテストで、全ての機能を組み合わせて1つのシステムとして正しく動いているかを確認します。ユーザの要件どおりに動いているか、機能間の連携はとれているか、性能(処理の速さなど)は問題ないかなどを確認します。
システムテストは新規システムの場合、本番環境を使用して行われることもありますが、本番環境に限りなく近いテスト環境で行われる場合もあります。
運用テスト
運用テストは、システムテストの後に行われるテストで、実際にユーザ自身が本番環境で本番データを使用して実施するテストです。当初のコンセプトどおりのシステムとして仕上がっているか、使い勝手はどうかなどを最終的にユーザ自身にチェックしてもらいます。
テストケース
次にテストケースの上げ方について説明します。テストケースが不足していると、テストが不十分になり品質の悪いシステムとなってしまいます。
逆に、テストケースが多すぎても、作業時間ばかりかかる非効率になります。
システム開発において、品質を担保するためにはテストケースの上げ方が重要なポイントです。
テストケースの考え方
上記の三角形の問題の解答のように、テストケースは「正常系」と「異常系」の2パターンで洗い出し、「異常系」の中でも「存在チェック」、「属性チェック」、「有効値・有効範囲チェック」などがあります。正常系:仕様どおりの入力データや操作によるテストケース
異常系:仕様どおりでない入力データや操作によるテストケース
特に異常ケースは、テストケースの漏れが発生することが多いので注意が必要です。
ディシジョンテーブル
ディシジョンテーブルとは入力データをプログラムが処理した結果、出力結果がどのようになるのかを一覧表にまとめたものです。全てのパターン(場合によってはロジックに差異のある主要パターンのみ)を網羅するテストケースを導き出すのにも非常に有用で、開発者が仕様に基づき整理分類しておきます。
文章だけではイメージしづらいと思いますので、下記仕様のディシジョンテーブルを作成してみることとします。
◆仕様(例)
このシステムは、ITスクールTech Fun.jpの「Android講座」の割引率を判定するものです。下記注意事項に従って割引種別にチェックをし、割引率判定ボタンを押すと割引率が判定結果欄に出力されます。※注意事項※
・割引種別の適用は最大3つ(4つ選択した場合はエラー)
・割引率は最大35%(35%を超えた場合は35%を適用)
・初回割引と再受講割引は同時併用不可(両方選択した場合はエラー)
画面イメージとディシジョンテーブルは以下の通りとなります。
◆ 画面イメージ
◆ ディシジョンテーブル
今回のテストケース数は、入力データであるチェックボックスの状態が2通り(チェック済み、未チェック)あり、それが合計4つあることから、2の4乗通りの16通りとなります。ディシジョンテーブルでは、入力データ、この例では「割引種別(IN)」の該当する箇所に「Y」を記入することで全てのパターンを洗い出すところから始めます。
そして、想定している処理結果を出力データ、この例では「割引率」(OUT)の該当する箇所に「Y」を入力します。
注意点としては入力データの全てのパターンを洗い出す際、業務仕様上あり得ない組み合わせが存在する場合があります。
上記の例では、「初回割引」と「再受講割引」が同一ケースに存在する場合です。
このような場合は、出力データの欄全てに「N/A」と記入します。
「N/A」とは「Not Applicable」の略で「該当なし」という意味です。
画面上では「初回割引と再受講割引の両方は選択できません」と言ったメッセージを表示する必要があるでしょう。
更に、仕様では3つ以上選択するとエラーとするように記述がありますので、4つ選択された場合も「N/A」となります。
「割引種別は3つ以内を選択してください」と言ったメッセージが必要となります。
但し、「初回割引」と「再受講割引」が同一ケースに存在し得ないというルールにも抵触していますので、この場合はどちらのメッセージを出すかは、仕様決定者に委ねられることになります。
プロジェクト成功の鍵とは?
プログラミングもテストも、システムの仕様を正しく理解していなければ作業が進められません。最初のうちは仕様書を読み解くのに時間が掛かりますが、丁寧に仕様書を読むことが結果的には作業を無駄なく進めることができます。
仕様書を読んで分からない部分は、設計者に質問してどのような意図があるのか確認していくことが大切です。
仕様を正しく理解していないと、折角作成したプログラミングの内容が無駄になってしまったり、テストを実施したときに仕様漏れが発覚し作業工数が増えることに繋がってしまいます。
チームメンバー全員が仕様やプロジェクト内のルールを理解し、コミュニケーションを取りやすい環境であることが、プロジェクト成功の鍵だと言えます。