コーディングのプロセス改善では単体テストとコードレビューも大切
ソフトの品質改善にはコーディングプロセスの改善が大切
ソフトの品質は最終的にソースコードの品質で決まります。テストや設計レビューの影に隠れてしまい注目される事が少ないのですが、ソースコードを作成するコーディングプロセスは実はソフトの品質を良くするためにとても大切です。では、コーディングプロセスを良くするには何をすれが良いのでしょうか？
コーディングプロセスの改善にも色々なポイトがあるのですが、この記事ではグータラ親父がコーディングプロセスの改善のために注意していた、コーディング規約、マスターツリー管理、単体テストの内容、コードレビュー の４つのポイントのうち後半の２つについて紹介していきます。これらののポイントに注意して、現状のコーディングプロセスで不足している所を見つけ出して改善していく事で、コーディングプロセスの品質を改善していく事ができます。
単体テストの内容が具体的に決まっているか
単体テストはテストプロセスなのに、なぜコーディングプロセスの改善の中で取り扱うのか疑問に感じた人もいるかと思います。単体テストの定義も他のテストと同じ様に開発組織によって様々の物があります。でも殆どの場合、単体テストはコーディングと一体の作業として、コーダが実施する事になっています。ですので、単体テストコーディングプロセスの１つとしてプロセス改善を進めるのがやり易いので、グータラ親父は単体テストはコーディングプロセスとして扱ってきました。
また、単体テストは個々のコーダーが実施する作業のために、実施する内容を具体的に決めて置かないと、テストの内容や実施範囲がコーダによってまちまちになってしまうという問題も起き易いです。この事も、単体テストをコーディングプロセスとしてちゃんと定義しておく必要がある理由の１つです。
では、単体テストの定義としてどんな事が決めてあればコーディングプロセスとして良いのでしょうか。幾つかの観点がありますが、グータラ親父は以下のような基本的な点が明確に定義されているかどうかに注意してコーディングプロセスの良し悪しを判断してきました。
(1) 単体テストはホワイトボックステストとして実施する事が明確になっている
単体テストは設計した通りにコードが出来ている事を確認する事が目的のテストです。ですので、基本的に内部の構造を知っている事を前提としたホワイトボックステストになります。この事は、わざわざ定義に書く前も無いとの考え方もあるのですが、念のために明記しておくほうが良いでしょう。
(2) 単体テストに使うテストデータの作成方針が決まっている
単体テストを実施する時には様々な種類のテストデータを使う事になります。そのテストデータをどんな方針で作成するのか、同値分割で良いのか、境界値分析を使うのか、境界値分析の場合のサンプリング点を何か所にするのか、等は決めておく必要があります。
(3) ローカルの管理データの状態は網羅的にテストするようになっている
プログラムコードの内部にローカルな制御変数や制御ステータスのように、プログラム実行の流れを制御する管理データを持っている場合には、それらの状態を網羅するテストを実施する事が必要です。グローバルな管理データであれば、単体テストの後に実施される結合テストやシステムテストで確認されますが、ローカルな管理データについては単体テストによるホワイトボックステストの段階で状態を網羅的にテストしておかないと、後のテストで網羅性を担保するのは難しいです。
(4) パスのカバレッジテストを実施する場合には網羅性の種類と目標の網羅率が決まっている
プログラムコードの実行制御が正しくできているいる事を確認するためには、テストで全てのコードの実行を確認したかどうかを判断するために、テストのパスカバレッジ（実行したドースコードの網羅率）を測ります。このカバレッジ（網羅率）には、C0/C1/C2 の種類があるので、どの種類のカバレッジを採用するのか、と、その採用したカバレッジで何％の網羅率を目指すのかを、明確にしておく必要があります。
C0/C1/C2 のカバレッジの概要は以下のようなものです
C0：命令網羅・・・全ての命令が実行された場合に網羅率100% とする
C1: 分岐網羅・・・全ての分岐命令で真/偽の判断が実行された場合に網羅率100%とする
C2：条件網羅・・・関連する分岐命令での全ての 真/偽 の組み合わせが事項された場合に網羅率100%とする
(5) 単体テストの記録をどんなレベルでどんな方法で取るかが決まっている
単体テストはコーディング作業と一体となって実施され、デバッグによりテスト対象のコードもどんどん変化していくので、テストの記録が取り難いという一面を持っています。とはいえ、単体テストが終わったかどうかを判断するためにも、何等かのテスト記録は必要です。あまり厳密なテスト記録の方法だと、コーディング・デバッグの作業効率が低下してしまうというデメリットもあるので、その開発プロジェクトに適したレベルでの単体テストの記録の要否と記録の方法が、予め決めてあるほうが良いでしょう。
(6) 単体テストの終了条件決が決まっている
何が出来たら単体テストを終了したとするのかの、テストの終了条件は単体テストでも必須です。一連のテストを実施してバグが見つからなくなる事を条件とするのか、バグが残っていても何等かの条件を満たしていれば単体テストを終了する事ができるのか。誰がどんな情報を元にして、単体テストの終了を判断すれば良いのかは、明確になっている必要があります。
コーダ―レビューの手順は具体的に決まっているか
コードレビューは直接ソースコードの問題点を見つけ出して修正するので、コードの品質を改善する色々な手法がある中でも効果の高い手法です。実際のコードレビューの方法はいろいろとあるのですが、そこはコードレビューというソフトウエア開発技術に関する事なので、ソフトエンジニアに任せておくので良いでしょう。
ではコーディングプロセスとしては何に注意するのが良いのかというと、コードレビューの具体的な実施方法や指摘事項の管理手順がちゃんと決まっているかどうかです。具体的には、以下のような項目がコードレビューの手順として決まっていれば、まずは安心です。
(1) コードレビューを実施する条件が明確になっている
まず一番最初に、どんなソースコードに対してコードレビューを実施するのかが決まっている必要があります。①新規に作成したコード ②既存の物に機能追加をしたコード ③既存の物の不具合修正をしたコード この３種類のコートに対して、原則として全てのコードをコードレビューの対象とするのか、複雑度とか影響範囲とか、何等かの制限条件を設けて重要なコードだけをコードレビューの対象とするのか、明確に決まっている必要があります。さらに、④今回は新規作成・修正はしていないが、今回の作成・修正したコードに影響を受けるコードについては、コードレビューの対象とするのかしないのか、決めてあるのが良いでしょう。
(2) コードレビューの実施時期が決まっている
コードレビューの実施の時期としては、①初版のコード作成時 ②コーダの単体テストの終了時 ③マスターツリーへの登録の直前 等が一般的です。 ただし、開発期間が短くてこれらの時期にコードレビューの時間を取れないような開発プロジェクトの場合には ④システムテストの後半 というタイミングでコードレビューを集中的に実施するという手を採用する場合もあります。バグ修正が一段落してコーダに時間的な余裕ができた時点で、集中的にコードレビューを行うという方法ですね。いずれにしても、どんなタイミングでコードレビューを実施するのかは、明確に決まっている事が大切です。
(3) コードレビューの実施方法が決まっている
コードレビューのやり方には大きく分けて２つあります。レビューを受ける人とレビューをする人が同じ画面を見ながら行うやり方と、レビューをする人が一人でコードを見て問題点を洗い出していく方法です。また、コードレビューをする時に、レビュ－をする人を一人に限定するのか、複数にするのかでも、レビューのやり方が変わってきます。どんな方法でコードレビューをやるのかは、明確に決めて置く必要があります。
(4) コードレビューで確認する観点が決まっている
コードレビューはソースコードに潜在する問題点を見付けて指摘する活動ですが、どんな観点でレビューをするのかによって、レビューで指摘される問題点も変わってきます。 主な観点には以下のような物がありますが、どれを重点的に見るのかは事前に決めて置くのが良いでしょう。 ①コードの表記を見る（コードがコーディング規約に従って表記されているか） ②コードの処理フローが設計と合っているかを見る ③コードのデータアクセスに問題が無いかを見る（排他制御や初期化の状況など） ④コードの効率性が妥当かを見る（必要な処理速度や処理性能を満たせる工夫がなされているか）⑤コードのエラーリターン処理が妥当かを見る（エラーリーターンの値が設計どおりか、デフォルトのエラー処理があるか など）
(5) コードレビューの指摘事項の記録の方法が決まっている
コードレビューでも他の設計レビューと同じように指摘された問題点の記録とそのトラッキングが大切です。指摘点をどんな方法で記録するのか、記録した指摘点は誰がどんな手順で対策を検討し、その対策（コードの修正）を行うのか。 対策の実施状況は誰がどんな方法で抜け漏れが無い事を確認するのか。コードレビュ－で見つかった潜在的な問題点が抜け漏れなく対策できる仕組みは決まっていないと困ります。
(6) コードレビューの完了条件が決まっている
コードレビューは１回実施したらそれで良いのか、決められた回数は実施するのか、指摘項目が無く鳴るまで繰り返し実施するのか、どんな状態になったらコードレビューが完了したと判断するのか、終了の条件は明確にしておく事が大切です。
コーディングプロセスの次はテスト設計プロセスです
コーディングプロセスが改善されたら次はテスト設計プロセスの改善です。テストはソフトの品質を保証する唯一の方法なので、テストの設計プロセスもしっかりとした品質の良い開発実務プロセスにしておく事が大切です。