We’ve all been junior coders at some point and is prutty OK to have been hard-coding stuff directly into thesource code.
While hard-coding can be appropriate for
- small, one-time projects,
- single developer applications
- or quick prototypes,
It generally becomes less desirable as the complexity and scale of the project increase. Hard-coded values make it harder to modify or update the program without directly modifying the source code, which can be time-consuming and error-prone. It also limits the reusability of code and can lead to code duplication.
In contrast, using
- environment variables, or start-up arguments
- configuration files,
- or external data sources
allows for greater flexibility, modularity, and maintainability. By separating data from the code, you can change values or configurations without modifying the underlying logic. This promotes
- code testability – as some logic could be tested against a safe data set.
- having independence of dev and prod
- code reusability – makes it easier to adapt the program to different scenarios or environments.
That being said, programming is a continuous learning process, and there are situations where hard-coding may still be appropriate or expedient. It’s important to understand the trade-offs and choose the approach that best suits the specific requirements and constraints of each project.
Virtualization & Containerization
The way backends are started evolved from – running inside virtual machines – to running in sandboxed containers inside a host. This allows having practically identical environments in dev, test and production. Software like Docker helps learn this and if you’ve advanced – you may learn also Kubernetes. All this is a must today – for real world applications that minimize settings developer errors and developer OS – harded stuff.