July 10, 2013
Believe it or not, one of the biggest challenges that programmers face when building an application is what to name variables in the application. The subtleties of language sometimes make naming code constructs quite difficult. Frequently, conversations with other engineers about what to name something end up resulting in a myriad of terms that don’t quite fit. They pick the one that fits best and move on. Sound familiar? This can end up coming back to bite them when a programmer (maybe even the person who named it in the first place) comes along and tries to understand what was trying to be expressed.
Domain-driven design (DDD), introduced by Eric Evans in his book of the same title, is a natural extension to object-oriented programming that emphasizes the domain of the project. Outlining DDD in detail would take an entire series of blog posts, so this will focus on one tenet that is useful even in projects that don’t employ DDD--the ubiquitous language.
The vocabulary in many software projects starts out consistent with the language of the organization. As a programmer, it is natural to name code constructs after the real-world objects they represent. However, this can become complicated as the project gets bigger or personnel changes occur. Objects across the application start to look and act differently. Reading the code becomes more of a chore than a pleasure.
By making a concerted, organization-wide effort to use a consistent language, the latter scenario can be mitigated. This sounds easy, but in practice it requires some discipline. Team members must use domain language intentionally.
For example, the word “job” in an HR application could mean several different things. Is it talking about a position that needs to be filled? A task that needs to be completed by an employee? This particular word is overloaded, especially in the HR industry. To make code look and act coherent, programmers need to be specific about what kind of job they’re talking about. This gets rid of the internal translation that many programmers make when talking with product owners. It goes something like this: “The product owner just mentioned an applicant applying to a job... In our code base that means populating the job opening column on the job application database table.” That kind of internal translation is burdensome at best, and causes confusing, buggy code at worst. Having a ubiquitous language improves the coherence of the code base and keeps everyone on the same page.
So programmers, next time you’re having trouble naming something, try something simple — talk to someone non-technical in the organization. They will probably surprise you with a few good ideas about what you should call what you’re trying to create.