3 ms·

It enables such designs, by making it easy for someone to add more crap into your ball of mud. Not everyone on your team is as smart or experienced as you. Wh

by cle 10y ago

It enables such designs, by making it easy for someone to add more crap into your ball of mud. Not everyone on your team is as smart or experienced as you. When their back is against the wall with a deadline...just throw some more beans in there, who cares how they're wired together, it's all handled by Spring! Well, you care when you have an unexpected complex circular dependency or you need to refactor and you suddenly discover how complex your dependency graph has unintentionally become. By "decoupling" and "modularization", I'm not talking about at a code-level by using interfaces. In my opinion, that kind of decoupling and modularization isn't very important, especially when it comes to application glue--because the glue (Spring) is what decides the backing impl's of all those interfaces. That's where the important dependencies lie, and that's where your big ball of mud accretes.

ivan_gammel 10y ago
It is not a tool problem. Programming tools always address two problems: coding performance and coding quality. But the design, the architecture is not something that could be fixed by a tool. Frameworks may add or remove some constraints, but there's always enough space for the side effects of human creativity. People always break or misuse the tools, creating the balls of mud. It's not a problem with these tools, it's a problem with organization of development process, with competencies of decision makers, with inadequate constraints and unclear requirements. It's easy to blame the tool, throw away the ball of mud and start from scratch with fancy new tech. But in the end you'll get the same ball of mud, because you have ignored the root causes.
kazagistar 10y ago
> When their back is against the wall with a deadline...just throw some more beans in there, who cares how they're wired together, it's all handled by Spring! I just came across a controller in our code that had over 50 spring injected services. Our entire code base is only like 5 years old. The problem is that this is my first job out of college... even if I know things are messed up, I don't really have an example of an application like this that is actually done right.
- qw 10y ago
  I prefer controllers to have only one service. A controller should do as little as possible. Its responsibility is just to pass data from the request to the service. The same should apply to repositories unless it is absolutely necessary. It should ideally just know enough to manage itself A service may reference other services if it needs to coordinate actions. We need to be careful not to make huge services that contains too much logic though I have found that this pattern makes it not only easier to structure the application, but also much easier to make mocked tests.

by cle 10y ago

ivan_gammel 10y ago

It is not a tool problem. Programming tools always address two problems: coding performance and coding quality. But the design, the architecture is not something that could be fixed by a tool. Frameworks may add or remove some constraints, but there's always enough space for the side effects of human creativity. People always break or misuse the tools, creating the balls of mud. It's not a problem with these tools, it's a problem with organization of development process, with competencies of decision makers, with inadequate constraints and unclear requirements. It's easy to blame the tool, throw away the ball of mud and start from scratch with fancy new tech. But in the end you'll get the same ball of mud, because you have ignored the root causes.

kazagistar 10y ago

> When their back is against the wall with a deadline...just throw some more beans in there, who cares how they're wired together, it's all handled by Spring! I just came across a controller in our code that had over 50 spring injected services. Our entire code base is only like 5 years old. The problem is that this is my first job out of college... even if I know things are messed up, I don't really have an example of an application like this that is actually done right.

qw 10y ago
I prefer controllers to have only one service. A controller should do as little as possible. Its responsibility is just to pass data from the request to the service. The same should apply to repositories unless it is absolutely necessary. It should ideally just know enough to manage itself A service may reference other services if it needs to coordinate actions. We need to be careful not to make huge services that contains too much logic though I have found that this pattern makes it not only easier to structure the application, but also much easier to make mocked tests.