4 ms·

> If you split functionality out of one service, you end up with the old service's name implying it does both. If you change what a class does you need to chan

> If you split functionality out of one service, you end up with the old service's name implying it does both. If you change what a class does you need to change the name, if you change what a method does you need to change the name, same for services. If it's too hard to change service names, that's your problem. > When you make a rewrite... Internal changes in a service must be transparent to consumers. If consumers are aware that you are doing internal work then you are doing something wrong. Codenames is the equivalent to call your variable John.

dasil003 4y ago
This completely fails to recognize the cost of change at different layers of abstraction. A service is an external facing entity that other teams need to interface with, it would cause an insane amount of churn to try to make changing service names as easy as changing internal class names, let alone local variables.
- hourago 4y ago
  > it would cause an insane amount of churn to try to make changing service names as easy as changing internal class names It's easier to change your service name that a class name or method in a popular library used by millions of developers, and it is done because it's the only thing that makes sense. Can you imagine that your framework class to store data was named "Mercury" and the one to manage HTTP connections "Saturn"? Nobody would use such a thing. Good descriptive names help to use software properly. If you cannot change a service name because it's too costly, review your development process.
  - afiori 4y ago
    It is easier to change a class name of a public library than the name of the public library. One is a breaking change, one is an official fork.
stevebmark 4y ago
I really like the comparison to variables/classes because it shows how poorly descriptive service names work. Services contain hundreds to millions of variables, classes, and lots of features, layers, etc. Comparing a service name to a variable shows why it's a poor idea to try to name your service descriptively, it contains so much and will change over time. And refactoring classes is easy, renaming services is much harder.
- hourago 4y ago
  Maybe your services are just too big? I have seen classes with tens of thousands of lines, it was not good. Too big services are equally error prone and hard to work with.
thaumasiotes 4y ago
> Codenames is the equivalent to call your variable John. Imagine that you have a singleton object floating around your system, every single function written anywhere in the system must interact with that object heavily, and as a consequence everyone is familiar with what the object does and where it's defined. What problems do you think might arise if that object were named "John"?
- hourago 4y ago
  That each new developer needs to learn that name. That it's difficult to understand what is that variable scope: does this new functionality fit in John or not. That most people know John but what happens with that other one that is rarely used named Jack and you find in in the code, and Anna and Maria? It would be the same for the computer running the code, the problem is for the developers trying to understand how to use it, how to expand it, etc.
  - thaumasiotes 4y ago
    Let me rephrase: what problems might arise that wouldn't be just as bad if a name other than John was picked? Everything you list is potentially a problem, but not a problem that got worse when we named the system John.

dasil003 4y ago

This completely fails to recognize the cost of change at different layers of abstraction. A service is an external facing entity that other teams need to interface with, it would cause an insane amount of churn to try to make changing service names as easy as changing internal class names, let alone local variables.

hourago 4y ago
> it would cause an insane amount of churn to try to make changing service names as easy as changing internal class names It's easier to change your service name that a class name or method in a popular library used by millions of developers, and it is done because it's the only thing that makes sense. Can you imagine that your framework class to store data was named "Mercury" and the one to manage HTTP connections "Saturn"? Nobody would use such a thing. Good descriptive names help to use software properly. If you cannot change a service name because it's too costly, review your development process.
- afiori 4y ago
  It is easier to change a class name of a public library than the name of the public library. One is a breaking change, one is an official fork.

stevebmark 4y ago

I really like the comparison to variables/classes because it shows how poorly descriptive service names work. Services contain hundreds to millions of variables, classes, and lots of features, layers, etc. Comparing a service name to a variable shows why it's a poor idea to try to name your service descriptively, it contains so much and will change over time. And refactoring classes is easy, renaming services is much harder.

hourago 4y ago
Maybe your services are just too big? I have seen classes with tens of thousands of lines, it was not good. Too big services are equally error prone and hard to work with.

thaumasiotes 4y ago

> Codenames is the equivalent to call your variable John. Imagine that you have a singleton object floating around your system, every single function written anywhere in the system must interact with that object heavily, and as a consequence everyone is familiar with what the object does and where it's defined. What problems do you think might arise if that object were named "John"?

hourago 4y ago
That each new developer needs to learn that name. That it's difficult to understand what is that variable scope: does this new functionality fit in John or not. That most people know John but what happens with that other one that is rarely used named Jack and you find in in the code, and Anna and Maria? It would be the same for the computer running the code, the problem is for the developers trying to understand how to use it, how to expand it, etc.
- thaumasiotes 4y ago
  Let me rephrase: what problems might arise that wouldn't be just as bad if a name other than John was picked? Everything you list is potentially a problem, but not a problem that got worse when we named the system John.