People love acronyms. Developers are people. Not much we can do about it.
A lot of developer, acronyms are dedicated to reducing, simplifying and thinking twice about what we’re adding. And for good reason. As developers we tend to complicate things surprisingly often.
Test Driven Development is like exercising 3 times a week. Everyone should do it, Most of us don’t. And those us who do tell EVERYONE about it.
If we can’t fight them, let’s at least understand some of the most often used acronyms.
1. DRY – Don’t Repeat Yourself
DRY refers to code writing methodology. DRY usually refers to code duplication. If we write the same logic more than once, we should “DRY up our code.”
A common way to DRY up code is to wrap our duplicated logic with a function and replace all places it appears with function calls.
Example (with code repetition):
//flow A
let username = getUserName();
let email = getEmail();
let user = { username, email };
client.post(user).then(/*do stuff*/);
//flow B
let username = getUserName();
let email = getEmail();
let user = { username, email };
client.get(user).then(/*do stuff*/);
DRY Example:
function getUser(){
return {
user:getUserName();
password:getPassword();
}
}
//flow A
client.post(getUser()).then(/*do stuff*/ );
//flow B
client.get(getUser()).then(/*do stuff*/);
Good code is DRY code.
2. KISS – Keep It Simple Stupid
Keeping it simple surpsingly hard. Usually when someone tries to over-engineer a soluiton to a problem. For example an Architect suggests creating a Microservice framework for a simple website. The Engineer will then say: “Let’s KISS it and do something simpler”.
Another rule of thumb is whenever you think to yourself “Finally I’m going to use something from my Computer Science degree,” you should probably KISS it.
3. YAGNI – You Aren’t Gonna Need It
A step brother of KISS. Part of keeping it simple is not adding modules, frameworks and dependencies we don’t actually need.
Let’s Imagine you’re working on a simple prototype to show to a client.
You decide to develop it in React because you read a cool blog post about it. You then find yourself comparing flux implementations, and deciding to go with Redux. You also need webpack to process JSX for React, naturally.
You decide to setup a small nodejs server to serve your files. You add Socket.IO just in case you’ll need real-time notifications for whatever reason.
You finish your prototype, which is essentially turned out to be a glorified web page to show a concept for your product manager. You later find out your product manager took a screenshot of the page and put it on a slide.
We didn’t really need React + Redux + Socket.IO for a screenshot now did we?
4. TDD – Test Driven Development
Test Drive Development is the equivalent of eating all your veggies and exercising 3 times a week. Its good for you and everyone should be doing it.
TDD can be summed in 4 steps:
- Decide on the desired functionality
- Create the test for that functionality first. The test fails since no code exists yet.
- Write the code that implements the desired functionality. The test now passes.
- Repeat.
There are many studies that show this way of writing code is much more effiecient than the other way. Writing tests first ensures near 100% test code coverage. You’ll spend more time coding and less time debugging future errors.
But like excercising regularly and eating veggies, few of us actually do it. And those of us who do make sure EVERYONE knows about it. We get it Bob, TDD changed your life and everything now please stop talking.
5. SOLID Principles
You a can find a great article written by a pretty handsome guy right here.
6. BDUF – Big Design Up Front
This is a relic from the waterfall era before everyone became cool and Agile.
This acronym is here to remind us not get over carried with super complex architecture. We shouldn’t spend 3 months designing our application before even writing the first line of code. Start small and iterate.
BDUF is basically what happens when you don’t KISS and end up with a lot of stuff which YAGNI.
7. SOC – Separation of Concerns
Another something we need to keep reminder ourselves is to do just one thing. As developers we apparently want to “do all the things” with every function, class or object we create.
In Unix, this is referred to in the mantra “do one thing well”. It’s also the first SOLID Principle – “Single Responsibility Principle.”
Either way, it’s really important to remember that every construct you create will do just one thing.
There’s a reason there are so many different ways of reminding you to do just one thing. A lot of times you believe you’re doing just the one thing, but you then realize you can divide that one thing into several other smaller things.
Rule of thumb: If we can divide one thing into several other smaller things it is no longer considered a one thing.
Simple right? Don’t make a thing out of it 😃
What are your favorite developer acronyms?