There are many well respected devs (software engineers, developers, app designers, twitter fam, etc.) that share experiences and posit on random thoughts. It may be true to them or may be true in a specific scenario that they may or may not have expounded on. For example, the pre-optimization thing. You know that makes my blood boil.
I almost slipped and made this about that…
There seems to be an opposite expectation on architecting a project. Or, as you might guess, OVER-architecting. Rarely do the trolls bark on this. I find this to be worse by an order of magnitude. 10 orders (that's a 100x right?). Rarely, and definitely with less vehemence, do people say: “Don't do an n-tier design! Wait until you need it. A data access layer is stupid! You no gud programmer!”
And yes, I get that architecting should be done up-front because refactoring code when you realize…wait 8-|
Here's an example.
//TBF/DISCLAIMER : I haven't seen this particular complaint anywhere, but I feel it captures the point. I looked at my code and I saw a blog post form and here we are.You're using Azure Key Vault in your environment. You may have multiple projects that use the same Key Vault (I have 23). The docs and “proper design" would dictate the following:
var kv = Configuration["KeyVaultNameOrUrl"]
ConfigurationBuilder builder = new ConfigurationBuilder();
builder.AddAzureKeyVault(new Uri(kv), new DefaultAzureCredential(new DefaultAzureCredentialOptions())Cool. (Ignore the fact I didn't set options on the credentials piece).
But now I must add ANOTHER config section to my projects locally (appSettings or local.settings) and I have to add it to deployed config. Which may or may not use KV.
That's the “right way” because someone said so (MS docs? Someone smart? I don't know.)
Instead of that, this is what I did. (just the URI piece is shown):
new Uri($"my-kv-url-is-hard-coded-{IsDevelopment.ToString("dev", "prod")}"),Yes, the unspeakable act of a hard-coded string. You can use a constants file, a const at the top, or whatever. The point is, I hard coded the name and change between dev and prod with a hosting variable. I could change the whole name, of course, but in my case mt KV URL changes with an appended prod/dev suffix.
What does this do for me, internet stranger? It allows this project to be cloned or deployed to a new environment and get to working (since settings are in KV - that's a win). I don't have to ensure I have to have another config setting to get my config settings. I guarantee many hours saved over the course of time. And less frustrating.
The fact is, this is one of those things that probably doesn't change a lot. And you probably don't want people having to manually manage settings locally (one of the KV Selling Points).
Also, if ONE DAY, I find I do need to change this to a config-based setting (e.g., so many environments that hard-coding is more work), then I can do it in one place - the same place. But I make that decision when it makes sense. Not up-front because the “would-be”s say so.
You can even pre-plan for the eventual (if you're super concerned) with:
var kv = $"my-kv-url-is-hard-coded-{IsDevelopment.ToString("dev", "prod")}" //IN CASE I NEED IT Configuration["KeyVaultNameOrUrl"]
ConfigurationBuilder builder = new ConfigurationBuilder();
builder.AddAzureKeyVault(new Uri(kv), new DefaultAzureCredential(new DefaultAzureCredentialOptions())Look at that, now I have planned for the eventual need and only have to delete and uncomment some code and I can move on. After adding all the required new config settings.
The Takeaway
Planning for the future and architecting (and knowing what to optimize) is hard. We don't always know. But don't be afraid do things that makes sense because it goes against the grain or the CURRENT pattern. Magic strings are dangerous and can lead to bugs. But, like everything we do as the cogs in the machine that make tech run, do what makes sense and know what you're out will be if it comes to that.
Do things when they make sense and spend time on better things (like optimizing!).