プログラムを書いていて、完成したと思ってテストをすると、いつも分岐が漏れていて作り直しが発生するという方は、ぜひ続きを読んでください。
分岐が漏れると、とある条件のデータが根こそぎ正しく処理できなくなります。エラーとなって気付けるバグであればよいですが、そうでない場合は正しく動いているように見えて、データが正しく登録できていなかったり、意図せずデータが消えていたりしてしまいます。
もちろん、設計のタイミングでこのような分岐の漏れをなくすことができていればベストです。しかし、100%設計書通りに作れるプロジェクトなどほとんどありません。分岐の漏れは普通にあります。
つまり、プログラマ側でも仕様が本当に正しいかどうかを考えながらコーディングを進めていく必要があります。
では、どうすれば分岐の漏れを減らすことができるのでしょうか？
考え方として2つ、コーディング術として1つ紹介します。
データの件数は何件あるのか？
- 1つのクエリで取得できるデータの件数
- 親データにひもづく子データの件数
考え方の1つ目は、データの件数についてです。データを取得、登録する場合、必ず件数をもとに分岐を考える必要があります。
- 0件の場合
- 1件しかない場合
- 2件以上ある場合
この3つの分岐が発生する可能性があります。データを考える際には必ずこの3つの可能性があるのかどうかを徹底的に検討することが大切です。
変数の型は何か？
- 文字列として考えられる値の形式は何か？
- 数値として考えられる値の形式は何か？
考え方の2つ目は、変数の型についてです。変数の特徴も確実に踏まえながら、常に分岐を考慮する必要があります。
- DBに登録できないような大きい値の可能性
- Nullの可能性
- 整数、小数、マイナスの有無
変数の型によって、生まれてくる分岐にも違いがあります。文字列なら何があるのか？数値ならどうか？これらを1つずつ整理してチェックリストにしておくことが大切です。
分岐の漏れを圧倒的に減らすコーディング術
最後にコーディング術についてです。
たとえば、以下のような仕様があるとします。
「管理者ユーザーであれば、契約解除の申請ボタンを表示する。」
この場合も1つの分岐ですが、
if(管理者ユーザ){
//契約解除の申請ボタンを表示
}
という書き方をしてしまうと、漏れが生じる可能性があります。
漏れていないと思われるかもしれませんが、最初にも伝えましたが仕様書は絶対ではありません。仕様書は間違っている前提でコーディングをする必要があります。
この前提を守るのであれば、ここの書き方は以下のようになるはずです。
if(管理者ユーザ){
//契約解除の申請ボタンを表示
}else{
//何か必要？
}
このelseを常に書く癖をつけておくことが、分岐の漏れを圧倒的に減らすコーディング術です。
不要になれば、後で消せばよいです。ただし、必ず一度は「○○ではなかったらどうなるのか？」を考えてから判断するそのきっかけを作ることです。
多くの分岐の漏れは、一度考えていれば防ぐことができたものばかりです。思いつかなかったから書かなかったというのがバグの原因ということです。そのため、考える機会を意図的に作るために、分岐を書くときは、漏れなくダブりなく分岐を一度書き並べることが必要です。
たったこれだけのことで、分岐の漏れを圧倒的に減らすことができます。ぜひ、コーディングを学び始めた段階から、癖づけておきましょう。
