Simplicity Reduces Complexity — Is It Applicable to Coding As Well?
Here’s how you can make your code more simple.
Most of you, have been already working with Scrum methodology, where one of the key aspects is the sentence from the title. Agile methodologies are here to simplify the processes. But what about the code base?
We have nice and tidy, constantly improved processes, and so do business representatives expect similar experiences, with another feature delivery.
Years go by, time flies, and the repository is still growing.
Are we really ready to be agile with our codebase? We might have heard about YAGNI or KISS principles or even about Clean Code, but do we really know what it means to our application?
Or maybe, we think or have been told:
Well, this is nice example, but in the real world data structures are much more complex and I need to comply with the API schema. Features contain tons of requirements, which I need to implement. It is, what it is!
— or even worse —
This is [you can paste your company name] way! You can use simplicity in your side project!
The truth is, requirements are already complex. This is written in stone in our job descriptions. There is no easy project, where quality doesn’t matter. It might not matter until it does and then you’re fried!
One of the biggest issues within the projects, I’ve observed during my entire career is overthinking, adding code that is not needed at the time or just commenting out code (left for dead).
I’ve intentionally mentioned quality and named some basic principles like Clean Code, KISS and YAGNI as using these are the signs of high-quality code. Not limiting ourselves to only those, but these are pretty important for that matter.
As a junior developer, I always wanted to write complex code and be proud of implementing the solution in a way that I could only understand. That was great! I am a developer, after all! This is not an easy job and so is the solution to a problem. But after a while, I’d already forgotten what I had in mind.
If I only knew it then! The solution could have been much simpler and I didn’t have a problem understanding what I had in mind at the time.
There is a pretty common saying:
Junior developer writes code that only he/she understands. Regular developer writes code that he/she understands and the senior does too. Senior developer writes code that all three sections of devs are perfectly capable of understanding at a glance!
If the senior developer's code would have been complex, no one would understand it. But if a junior writes it, it has to be SIMPLE.
And this is the whole point. The code has to be simple. Easy enough for developers at any level to understand it. Even the most complex requirement, the most complex data structure can be sliced and diced (Atomic design!) into reusable pieces.
💡 This is exactly the approach an open-source tool such as Bit enables. With Bit you can pack atomic units of your code into packages and use them across multiple projects with a simple
bit import your.username/your-codecommand, reducing code duplication and minimizing boilerplate. Bit also comes with a complete toolkit that lets you test, document, version, and track changes to your components over time, making it easier to manage dependencies and ensure compatibility across your applications.
Learn more here:
In fact, data structures might be complex. You might have been assigned to a project, which will reuse the old API and you need to consume it. This shouldn’t stop you from data adaptation. Don’t use data as is, adapt it to your application needs. If your data can be abstracted into separate entities, then do not hesitate!
Here’s an example of how you can approach the data simplification:
Below is an example of plan JSON object representation for some specific order:
After deeper analysis, you might start wondering, why on earth some information is being repeated. The first repetition, which should have been discussed is the necessity of responsible and creator data duplication.
This is an ideal example of mixing multiple different entities into one god object (Trust me! Originally it was even worse! This order already contained a couple of items where the entity hidden under the responsible attribute was repeated 23 times!).
You might ask: “why should I treat it as separate entity?”, which is extremely important question, in order to simplify this object.
The response is even simpler! This object has its own id, which means, it can be uniquely identified. What is more, we will not be updating this information going forward, which also makes sense because how the hell do we want to do it in 23 places at once? How do want to keep everything in sync?
Sounds like an ideal candidate for a dictionary-like API endpoint, which should follow the Rest API naming convention:
https://restfulapi.net/resource-naming/ — documentation to help!
Example Endpoint URI:
- http://some-api-endpoint/clients -> to fetch list of clients
(might be good idea to introduce pagination query parameters to optimize)
— http://some-api-endpoint/clients/${id} -> to fetch specific client
The same technique can be applied to other order attributes, which contain their own unique identifier, like:
["type", "chargingModel", "shipTo", "purchasingPlant", ...]All we need to keep within the original object is the reference, an id which we could use to successfully identify and retrieve the entire entity from external resources.
After this exercise, our plain JSON order representation should look like this:
Looks much cleaner right? We can go even further and question having two similar attributes referring to the same (or similar) value. Is it really crucial to keep both _type and type attributes? let’s keep one for now! _type attribute, you’re not following JavaScript naming convention, bye!
We could possibly flatten the order structure entirely and extract deliveryInfo into the main order object. If you need to use the data within the simple form, you’re all set!
Now you can implement your object adaptation and start thinking of some data management system to store these dictionaries in an efficient way (will get into it a little bit deeper in a different article) to only fetch it once in the application usage lifetime (refreshing/closing the browser).
Just remember everything unpacked has to be packed up again. We’ve implemented IN operation adaptation, now it’s time to put it all back in place for OUT operation.
Once you deal with adaptation, you can start thinking of contract renegotiation, to match a simplified approach.
You can use the same technique when defining data contracts between Backend and Fronted implementation. The benefits you get are obvious:
- following Rest API ideology of having stateless, on-demand endpoints
- smaller responses JSON objects — less time needed to fetch
- reusability — you can use dictionaries endpoint in other contexts/part of your application
Take whatever API provides days are over! Become the driver of your API definition and actively contribute during interfaces design. Remember, that your application is relying on this. Whatever you decide to follow, will stay with you until next API interface change, but will it ever happen again?
Build Apps with reusable components, just like Lego
Bit’s open-source tool help 250,000+ devs to build apps with components.
Turn any UI, feature, or page into a reusable component — and share it across your applications. It’s easier to collaborate and build faster.
Split apps into components to make app development easier, and enjoy the best experience for the workflows you want:
