DEV Community

Cover image for How to build a scalable code system

Posted on • Updated on

How to build a scalable code system


What I’ve learned from writing a lot of crapy code is get a grasp of how to write a scalable code. Before I realized this, I had tried to google “how to write clean code” stuffs like that. The suggestions were helpful but somehow some of those didn’t stick with me. Now I consider “scalable” more than “clean”. There’re both important stuff indeed. Maybe those words are describing the same goal in different aspect. What worked for me was focusing on scalable part.

I’d like to share three points that I’ve learned regards on scalable code.

1. Draw abstract blueprint before you type

If you want to write a scalable code, you certainly need to have a abstract blueprint of your system. It might be tempting to write directly, but If you write first before having that blueprint, the rest of code will be more and more nonsense. Because you do not have an understanding how the code that you’re writing will affect in the whole system. In contrast, if you have a blueprint, you’ll know where this code will be placed and how it should works. Thus, you can write a part of code that will fit in the system you imagined before. The first way is like spontaneous trip without a destination, and the second is predictable journey to the destination.

It’s worth noting that it should be abstract, not pixel perfect. Remember the plan or requirements always can change.

2. Imagine How would you like to add a feature later

If you can easily add a feature, you also can remove or edit easily as well. So when I draw my blueprint, I imagine me adding a new feature. What a new feature would be? How would I place my new feature in my current blueprint etc. This activity helps you to build your code and structure your system in more scalable way. Just like User Experience, you need to think backward. It’s not a good idea that you need to force your user to use exactly what you want them to use. You, the developer and service provider should start from user’s point of view. Replace “user” with “other developers” or “future you”.

3. Make it switchable

Imagine your code system is a machine that make bicycles. Your factory is receiving orders from many bicycle brands. Each brand have different styles and detail. How would you design your machine?

For you to make it a profitable business, you will be like to have a super scalable machine, since your customer will change in times so you don’t throw your specific machine away. You need to reuse your machine in any brand’s bicycle.
A switchable comes in handy in this circumstance. Inside a machine, there’s a switches. If you edit your one and only one configuration file, the switches point according to your configurations. The only thing you need to do to make different bicycle is just edit one file. How’s that sounds?

Your code will be have an ability to make any bicycles.


Of course, there’re so much lessons that I have not learned yet. I hope that these lessons that I’ve learned so far will help you if you’ve not consider these yet.
Also, if you want to know more lessons like this, I recommend the book “Clean Architecture”. It helped me a lot.


Buy Me A Coffee

Top comments (0)