Have you ever been tasked with modifying code you’re not familiar with? Or integrating new features into an existing codebase? Reading through the code is a crucial step. However, understanding the underlying data can provide invaluable context and bolster your confidence that nothing was overlooked.
Learning about the data directly from the database can be immensely beneficial. However, even without direct database access, there are numerous other sources from which to glean insights. Here, we’ll delve into what to examine within the database and how these findings can influence your code. In my next post, I’ll explore alternative ways of understanding how the application functions.
Data Types
Look at the different data types used. Ensure that each column is formatted as the data type you expect (i.e. a numeric field isn’t reading as alphanumeric). If a ‘count’ or numeric field includes [1,’1′,’A’] then incremental and aggregate logic is different than when it’s an integer. Note any place where it seems a number field isn’t defined with a numeric data type.
A good example is ZIP Code. If the field is alphanumeric, the app probably supports non-U.S. addresses, as ZIP codes may include letters as well as numbers outside of the U.S. If your app allows purchase and shipping of goods, consider goods sent to soldiers overseas. Those shipments have different requirements (see “How Do I Address Military Mail“) and will add extra options to the list of U.S. States.
Min/Max
Running Min/Max on a field to see the decimal precision needed. This is important for currency fields, especially when round. (See “Stop Using Floating-Point Numbers to Store Money” by my coworker, Matt Soto for what to do. Search “Ariane 5 Rocket integer overflow bug” for what not to do and why.)
Nulls, Empty Strings, or Blanks
Even if a field is currently mandatory, it may not have always been required, so the data may not be as you expect. Investigate for nulls, empty strings, or blanks in the data. These may require additional logic to handle properly.
Title/Sentence/Upper/Lower Case
Is all the data upper or lower case? If the data is coming from a different system, a code may expect a specific case to function; adding new date without changing the case will cause things to fail. This is especially true for medical codes.
For example, you are expanding the list of forms the user can print. The form code is currently ALWAYS uppercase. If you allow the user to create a new form that is lower or title case, like “fte” or “Fte”, but upstream logic always assumes uppercase “FTE”, your new form may not display or may cause errors because the literal string won’t match. Ensure that the case aligns with the expected format to prevent potential errors.
Special Characters
Run a query that filters out alphanumeric characters; the remaining character set will be characters that may require special handling. This is especially true if the user can copy and paste data from Microsoft Word, or import csv files created in Excel, as Microsoft converts (or “auto corrects) quotation marks (to “smart quotes”), soft line breaks, em hyphen and fractions. When this data displays in the front end, it won’t be obvious that the data is any different and is causing errors.
Date/Time
Dates and time are a minefield for software bugs so pay special attention here. How are date and time stored? Is the date displayed from the server time? Or using the device time? (Also see Fix Client/Server Time Zone Mismatches with SvelteKit Progressive Enhancement by another coworker, Andrew Marmorstein.)
Are date calculations assuming server time? UTC format? For applications that aren’t focused only on the United States, be aware that the date format is YYYY/MM/DD instead of YYYY/DD/MM.
For example, a hospital visit on February 12, 2024 in Europe would get billed to your insurance company with the billing date of 2024/12/02. Since December 2024 is in the future, the claim will be denied.
More on Modifying Code in an Unfamiliar Codebase
Reviewing the database can unveil crucial insights about the application that may not be immediately apparent from scrutinizing specific code sections. Do you have any additional practices for reviewing the database and modifying code? Stay tuned for my next post, where I will explore further avenues for understanding how the software operates without direct database access.