DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’» is a community of 970,177 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

Create account Log in
Cover image for How to write code that will last 1000 years in just 3 steps? …or close to that
Mihai Blebea
Mihai Blebea

Posted on

How to write code that will last 1000 years in just 3 steps? …or close to that

Do you want your code to endure the test of time?

Some of you may say: YES. But the reality is that code is a living, breathing organism…

The code should be:

  • Flexible enough so you can replace aging parts with never modules as technology evolves and…
  • Scalable enough that you can add more features later down the road. Then why do we want to write code that will last a thousand years?

Exactly because of the 2 points above.

We need to write code that we will understand later, that we can extend with endless features and that we can pass on to other developers to carry on when we are long gone… from the company (not dead).

As a lead developer, I manage a highly motivated team composed of developers with different coding styles and every one of them wants to put a personal mark on the company’s product.

That means that each developer will code in a particular way, some using Promises instead of Async/Await or tabs instead of spaces… not that I encourage you to do that.

So because of that, I built a 3 step process to ensure that the code we are writing will be flexible and scalable enough to stand the test of time.

I will explain the whole process here, so you can apply it in your own coding and become a better developer.

Just stay with me for the next 3–5 minutes and you will master the art of writing quality code. Still, don’t forget to get off the tube if you get too focused on this article πŸ˜‚πŸ˜‚πŸ˜‚.

Step 1. Write code that a human will understand

Code is made to be understood by computers… or is it?

Tell me what this code does:

function parseData(result) {
  let items = result.data
  let response = items.forEach((obj)=> {
    return obj.filter((key)=> {
      return ['title', 'img'].includes(key)
    })
  })
  return response
}

How long did you take to figure it out?

Now multiply that with 30 different functions in a single file that makes no sense for any other developer who didn’t write this…

It can make any small task take 10x times longer, for no actual reason at all.

How about this next one?

function extractTitleImgFromPosts(blogPosts)
{
  return blogPosts.forEach((post)=> {
    return post.filter((part)=> {
      return ['title', 'img'].includes(part)
    })
  })
}

Oki, maybe I didn’t take the best example possible, but I think you get my point.

Conclusion:

Write code that you can understand later, so you can make even the most complicated tasks in the future seem like a walk in the park.

How to implement this step?

First, write the code keeping in mind that you must understand what you wrote when you will be asked to debug it.

Use clear names for variables and functions. Do not use β€œitem”, β€œpart”, β€œkey” or any letter to represent variables. Keep in mind that some functions need to be generic enough to be used in other contexts so don’t overdo it.

Then, create the PR and ask the guy who is reviewing your code to explain it to you in plain English… or whatever language you are using there πŸ˜‚πŸ˜‚πŸ˜‚.

If he takes a long time to do it, asks for your help or tries to pass the review to another team member, then you need to refactor your code to make it last in the future.

But this will take more time, right? Yes, could be the case, but think about how much time and unslept nights you will save in the future.

If you want to find out more and master this step, I recommend you google D.D.D’s β€œUbiquitous language”.

Want to read the full article?

Just jump to my Medium account and see the other 2 steps that will improve your code.

Click here: How to write code that will last 1000 years in just 3 steps?

Top comments (0)

In defense of the modern web

I expect I'll annoy everyone with this post: the anti-JavaScript crusaders, justly aghast at how much of the stuff we slather onto modern websites; the people arguing the web is a broken platform for interactive applications anyway and we should start over;

React users; the old guard with their artisanal JS and hand authored HTML; and Tom MacWright, someone I've admired from afar since I first became aware of his work on Mapbox many years ago. But I guess that's the price of having opinions.