The paramount concern for all software developers should always be striving towards a
well-structured, quality codebase or else risk ending up with inconsistent,
nonsensical code and constant requests against a database.
Modern computing power means many more calculations in a
shorter space of time, which has the unfortunate effect of inefficient data
access code not actually being shown up by the efficient code as it should be.
This becomes a compound issue with an ORM or an abstracted
model, where the code you write doesn’t explicitly point to the fact that the
method may select half the database, regardless of your requirement of it.
This may result in unintentionally inefficient code, but if
the code runs then why bother concerning yourself with the burden that has been
placed within the context of what you just wrote?
Efficient code, when it’s well written, thought out and
refactored or re-engineered appropriately, is more maintainable and therefore
less confusing to understand the intended implementation. It results in less
strain on the database, and the quicker an application can respond to the
user’s requests, the more trustworthy and useful it becomes.
This doesn’t mean go and denormalise all your databases; it
means take time to think about how you implement the interaction with the
database and strive to understand the implications of the code you write.
Consider the delay it might cause in growing or already large datasets, slower
connections, and the database developer who might be maintaining it in the
future.
This also allows for better scalability, regardless of
whether or not this was intended originally, bearing in mind that even a
little-used application will have a growing database over time. This may sound
like it will extend development time, but I firmly believe that the time is wisely
spent due to the clarity of the final product.
The evidence of this can be painfully felt when testing,
debugging, maintaining and expanding upon code that has not been crafted but
rather fired out, coding by coincidence.
If a development team or individual can take the time to
consider the words they weave and how the construction takes place, it will
directly benefit the individual and should exponentially benefit the team and
everyone who happens upon your code in the future.
Source: developer-tech
