I'm old. I prefer a name that hints at the usefulness of a project.
Now get off my lawn!
Software component names should be whimsical and cryptic
301–310 of 339 posts
Re: Software component names should be whimsical and cryptic
#302Earlier quoted context omitted.
Tell me you don't version your APIs without telling me you don't version your APIs.
You version your APIs, but do you version your services ? Think of your new service as having a different deployment target, its own DB, and could be under a different repo altogether.
So? Have you heard of API Gateway and/or HTTP routing based on path prefix or header?
Re: Software component names should be whimsical and cryptic
#303Re: Software component names should be whimsical and cryptic
#304Earlier quoted context omitted.
> Whimsical project names fall within a well-understood and used convention. Boy, I wish! I 100% second TFA when I tell you: There are a lot of really really boring people out there that just don't get it. They think "Product Data Exporter" is the perfect project name.
Better be consistently boring than ever misleading
Better to be googlable than boring.
Re: Software component names should be whimsical and cryptic
#305Earlier quoted context omitted.
You version your APIs, but do you version your services ? Think of your new service as having a different deployment target, its own DB, and could be under a different repo altogether.
So? Have you heard of API Gateway and/or HTTP routing based on path prefix or header?
You're right about the external interface, but you still need to give a name to the actual service behind the URL.
From your point on versioning, I'd assume you'd actually call it UserProfileV2 ?
PS: to get back to the original point, you're still stuck with a "UserProfileV2" service that does a lot more than just user profiles, but that's not reflected in the name.
Re: Software component names should be whimsical and cryptic
#306For an external/public project? Sure! For a release code name (like Debian does), yeah why not. For internal service names? No. Not unless there's an obvious connection to its role (ie: TrafficCop handles DOS attempts, etc)
I'm working with some legacy code that followed this pattern for internal services. It's a nightmare. WTF is Bilbo, oh it handles 2fa? And what's Pippin again? And there's a dozen other examples, of course most of them are from LOTR. I literally have to maintain a mental mapping because there's no rhyme or reason to the choices.
That's actively anti-developer, anti empathy and I hate it. It's not cute, fun, helpful, professional. I can't think of a single redeeming quality. Maybe it's ok for a prototype you intend to throw away because it's so ridiculous you don't want to use that name with your boss, so it encourages non attachment.
If you really can't pin down a name that describes the thing you're making, maybe you don't know what you're making?
Also, we can rename and/or retractor things. And we should if their responsibilities change!
Edit: added distinction about internal vs external.
Re: Software component names should be whimsical and cryptic
#307Even in the planning phase, when you have a new project, giving it a name helps in general conversation. It also gives it an exciting mystique and makes it seem like you still give a shit about the job.
Re: Software component names should be whimsical and cryptic
#308Earlier quoted context omitted.
Tell me you don't version your APIs without telling me you don't version your APIs.
You version your APIs, but do you version your services ? Think of your new service as having a different deployment target, its own DB, and could be under a different repo altogether.
You def don't want a new DB and for it to be under new repo
Re: Software component names should be whimsical and cryptic
#309Earlier quoted context omitted.
Except as the article says, names tend to stick, scopes don't. This PaymentService grew into fraud detection. So the new hire will be even more confused. Asking "What does Picard do?" is natural, where a new hire might have trouble asking "What does the PaymentService do?"
As someone else mentioned in the replies, this sounds more of a problem of not having a top level design than a naming problem. You have bigger problems if your `PaymentService` morphs into the functionality of being a storage or user service.
I would not say top level design. Software is often born out of software. It's more like a woman keeping her children in her womb instead of giving birth to them.
Re: Software component names should be whimsical and cryptic
#310Earlier quoted context omitted.
They're hard to distinguish in the sense that a colleague might ask something like "hey can you publish a new version of css-script-min" and you accidentally publish a new version of "css-min" or "css-inline-min" or whatever instead.
That's such a minuscule problem compared to trying to figure out which of the insane names is the one you need.
A name is usually not enough to determine which library/framework is best for you. This is the _illusion of transparency_ that the author talks about. How would you rename React and Angular such that developers could tell at a glance which one to use? If it's going to require further investigation from the user's part, better to give the project an opaque name to make it clear that further investigation is necessary.