はじめに
これは私の経験則ですが、プログラムで業務ロジックを実装する際は、要件通りの条件判定を記述するべきです。
たとえ、従属的に求まる条件で代替できるとしても、原則としてそれを使用するべきではありません。
具体的に何が言いたいのか、なぜそう言えるのか、ということについて、この記事では具体例を挙げて説明していきます。
条件判定記述の具体例
例えば、「商品区分が”1″の場合だけ、特別な処理をしたい」という要件があるとします。
また、実装上は「商品区分が”1″の場合は、商品コードの2桁目が”1″になる」という従属条件も存在するとします。
この場合、実装方針としては、以下の２つが考えられます。
- 方針１：商品区分が”1″であるかどうかを見る（要件通りに条件判定を記述）
- 方針２：商品コードの2桁目が”1″であるかどうかを見る（従属的に求まる条件を代替的に使用）
そして、この場合は、できる限り方針１で実装するべきです。
そう言える理由は以下の２つです。
- 理由１：可読性を損なわないようにするため
- 理由２：将来の変更に弱くなりにくくなるため（保守性の確保）
理由１については、新たな実装者を向かい入れることを考えるとわかりやすいと思います。
「商品区分が”1″の場合は、商品コードの2桁目が”1″になる」という従属条件を知っていれば何がしたいのかコードを見て推測できますが、そうでないとコードからは何がしたいのか推測できなくなるので、可読性が損なわれやすくなります。
理由２については、従属条件には例外がつきものということを意識する必要があります。
例えば、ある時点では「商品区分が”1″の場合は、商品コードの2桁目が”1″になる」が成り立っていたとしても、商品コードの採番が進むにつれて「取り扱う商品が多くなってきたので、商品コードの2桁目が”A”の場合も商品区分”1″として取り扱う」という例外が発生する可能性があります。
この際に実装の改修が発生してしまいますし、改修が漏れた場合は「商品コードの2桁目が”A”の場合に、特別な処理が行われなくなる」という不具合が発生してしまいます。
従属的な条件を使用する状況
従属的に求まる条件で代用する場合は、可読性・保守性以外の観点で止むに止まれぬ事情がある場合に限るべきです。
例えば、「納期に間に合わせるため」というのは、止むに止まれぬ事情の一つとして考えられます。
具体的には、「要件通りに実装するためには商品区分を見る必要があるが、商品区分を管理しているマスタデータにアクセスする方法がなく、新たにアクセスできるように設定変更する時間もない」というような状況です。
しかし、止むに止まれず従属的に求まる条件で代替する場合は、可読性や保守性をできる限り損なわないようにする工夫をするべきです。
例えば、本来の意図をコメントに残すというのは、可読性を損なわないようにする上で重要です。
コメントだけでなく、要件定義書や設計書のようなドキュメントにも、そのような実装に至った経緯を記述する方が良いでしょう。
「要件通りの条件指定に直す」というバックログを作って管理する、というのも将来的に保守性を確保する上では良い工夫です。
あとがき
プログラムは動けば良いというものではなく、可読性や保守性を考えながら記述する必要があります。
このようなことを考えながらプログラミングするためには、単にプログラミング言語の文法を覚えるだけではなく、ロジックの組み方やそれをテストする手法を実践的に学ぶ必要がありますし、株式会社サイゼントの研修やプログラミングスクールではそこまで教えるようにしています。
株式会社サイゼントでは、即戦力のJavaプログラマーを育てるための書籍「絶対にJavaプログラマーになりたい人へ」をKindleで販売しています。
同じく、Spring Frameworkについてきめ細かく解説した別冊も販売中です。
また、上記の書籍をテキストとして用いたプログラミングスクール「サイゼントアカデミー」も開校しています。
このスクールは、受託開発事業・SES事業である弊社が、新入社員向けの研修で培ったノウハウを詰め込んだものです。
ご興味がある方は、上記画像から個別ページにアクセスしてみてください！
コメント