Item 33: Use the Same Language in your Code as your Customers
If you've read the book Domain Driven Design (which I highly recommend), this is essentially its theses:
The names of entities found throughout your codebase should map directly to the names of things that your customers use.
A good litmus test to see if this is the case is to have an engineer that's less familiar with your project read over your code, then try to explain to someone who is familiar with the project from the business side of things what the portion of your code does, and see if the familiar person seems to be agreeing with what the less familiar person is saying. Using the same language as your customers in your code has a myriad of benefits, including:
- Easier alignment – It's much easier to ensure that you're building the right thing when what you talk about what your building is in the same language as what the customer already understands.
- Faster clarification on how certain business logic should work – The customer / stakeholder will be able to confirm or refute how something works if it sounds like something their used to working with in real life.
- Mapping ideas to code becomes much easier, since the things the customer will be asking for, and what that entails, will be apparent in your code.
Speaking the same language as your customer unifies your dev team and encapsulates knowledge and speeds up the SDLC.