Check Your Data
It's simple to avoid, but it is surprising how often developers will make the mistake of implementing new functionality without first verifying that it will work with data that already inhabit the database.
For example, your organization might need to update an existing Siebel implementation. One of the new requirements is to evaluate a Contact's Date of Birth, calculating the Contact's age and only allowing certain functionality for Contacts that are older than a limit.
To do this, you might create a calculated field that tests the Date of Birth so that the field's value is TRUE if the Contact is too young. If the field's value is FALSE, the restricted functionality is allowed.
You know that you have to handle NULL, because your calculated field won't return either TRUE or FALSE if the Date of Birth is NULL. But the business requirement calls for making Date of Birth a required field, and you can assume that no new Contacts will be created without a Date of Birth. Unfortunately existing data might contain NULL values that will break this functionality, and a NULL value in a required field can cause more problems, even in screens and views unrelated to the new age restriction.
Some configurators forget to thoroughly test their new functionality against the data already existing in the database. This situation might not be caught in the test cycle if only a small percentage of records have NULL values. But a situation like this can cause big problems if it is not caught before the new functionality is deployed.
The best practice is to carefully test to be sure that new functionality works with old data.
For example, your organization might need to update an existing Siebel implementation. One of the new requirements is to evaluate a Contact's Date of Birth, calculating the Contact's age and only allowing certain functionality for Contacts that are older than a limit.
To do this, you might create a calculated field that tests the Date of Birth so that the field's value is TRUE if the Contact is too young. If the field's value is FALSE, the restricted functionality is allowed.
You know that you have to handle NULL, because your calculated field won't return either TRUE or FALSE if the Date of Birth is NULL. But the business requirement calls for making Date of Birth a required field, and you can assume that no new Contacts will be created without a Date of Birth. Unfortunately existing data might contain NULL values that will break this functionality, and a NULL value in a required field can cause more problems, even in screens and views unrelated to the new age restriction.
Some configurators forget to thoroughly test their new functionality against the data already existing in the database. This situation might not be caught in the test cycle if only a small percentage of records have NULL values. But a situation like this can cause big problems if it is not caught before the new functionality is deployed.
The best practice is to carefully test to be sure that new functionality works with old data.
תגובות
הוסף רשומת תגובה