If we're programmers and "devops" why does anyone bother with this sort of thing ? If ops team can, and does, recompile everything regularly then why not just have them as constants in the code, or in some cases just directly in the code ?

There is no excuse for added complexity and this is a bad one.

> If ops team can, and does, recompile everything regularly then why not just have them as constants in the code, or in some cases just directly in the code ?

Because the ops team does not recompile everything regularly, and sometimes needs to run a service with different config in an ad-hoc manner.

Also, aiming the code at being configured when being run yields better separation between code configuring the thing and code that runs it. If you can't see what profit comes from keeping configuration separate from code, I'm affraid you won't be able to gather configuration in one place easy to change.

Just call it a "configuration", not a "configuration context"!

"Context" means nothing, because you can't flip a bit without it being in some kind of context. What is an object? It's a piece of context which holds named properties.

(Particularly, when you're parsing a "context free" grammar, there is shitloads of context just to ironically spite you.)

I'd be more inclined to name it ServerOptions instead of ServerContext.