What is called magic in software development?
Well maybe you are already familiar with the following gif image below.
When I first was introduced to this meme I totally understood what they meant with magic in programming or what at the time I could identify as magic code.
To understand what magic is let's look at some examples.
The first example is from Rails framework. Looks like there's not much going on in this code, right?
Taken from the same Ruby on Rails official website:
... note that the Post class inherits from ActiveRecord::Base. Active Record supplies a great deal of functionality to your Rails models for free, including basic database CRUD (Create, Read, Update, Destroy) operations, data validation, as well as sophisticated search support and the ability to relate multiple models to one another. Another important part of this file is attr_accessible. It specifies a whitelist of attributes that are allowed to be updated in bulk
Now, let's see this second example. It comes from Laravel framework.
In that small piece of code the application's route will automatically resolve the Service class and inject it into your route's handler. But how? Well, internally it is grabbing it from the framework's service container and thanks to dependency injection it is doing some configurations and injecting an instance of that class. Laravel does this also in controllers, event listeners, middlewares, queued jobs, etc.
As you can see there's quite some functionality hidden and available for us in those two code examples. They hide some configuration as well as conventions inherit by their respective application frameworks.
Magic is great as it offers all this functionality with a few lines of code. And at the same time magic is bad when used indiscriminately.
Why? Well, remember that as part of our software engineer responsibilities we need to do short and long term planning. First keep in mind that other developers might be working in the same codebase and they will need to be aware of these conventions and read documentation beforehand in order to understand what the code does or what it offers internally.
Also consider that your application might be migrated away from its original infrastructure depending on business or technology needs and being tied to a particular application framework makes it harder for decoupling.
Well this is the part where you need to decide how much magic is good in your software application and also how good or bad is to be tied to the chosen application framework and depend on it.
Remember that if your application framework blocks you from integrating your app with other services or makes it hard to decouple your modules to migrate them to microservices for other teams to work on it, or just slows you down in order to optimize the performance, security of your apps then I recommend you to plan ahead and spend a bit of time thinking about these implementation decisions and if using them won't slow you down later.
Your future self will thank you for it!
Top comments (0)