3 ms·

Assuming you only maintain a single API, why is domain logic in http controllers so bad? - you have twice as many signatures to maintain, which will become in

Assuming you only maintain a single API, why is domain logic in http controllers so bad? - you have twice as many signatures to maintain, which will become inconsistent with each other - introducing a new layer when you eventually need it, isn't more work than maintaining it now - Unlike other IO, REST frameworks are easy to test in memory

sanderjd 3y ago
Yeah I think it's really a good example of what I'm talking about. This is exactly the kind of thing that burns everyone eventually after they've done the job long enough, but which requires spilling a bunch of ink to describe why, which won't even work, because you just haven't been burned by it yet. And that's fine, this is just what accumulating experience is about. (And to make it worse, everyone's accumulated experience is different.)
- SebastianKra 3y ago
  If you find a way to share what I should watch out for, I'd appreciate it :)
  - sanderjd 3y ago
    I mean, this particular thing is covered in various books and other kinds of "best practice" documentation. There isn't a particular reason why I, as a random commenter on HN, would be able to make a more convincing case for it. But it's also reasonable to question the stuff it says in books and best practices documentation - nobody wants to cargo cult everything, and a lot of what's been written is not right in my view - so to some extent I feel like people just have to get burned by things in order to internalize why certain advice is good. I don't find that answer satisfying, but I've been on both sides of it over and over again throughout my career, and this is as far as I've gotten toward a conclusion.
- vorpalhex 3y ago
  This is the poor sort of experience that leads to arbitrary rules without understanding. It is always about the comprehension of the end, not the form. These don't always burn everyone. Sometimes these are the right thing. They may not be the right thing at your shop, but the world of software is not just your little software. Long method names can lead to better, more readable testing and code. They can also be easier to mistype or be harder for non-native English speakers. Combining routing and logic can be very fast and easy, but can lead to hard to debug issues with sprawling projects. But not all projects are sprawling. If you think you are experienced and also buy deeply into any fixed rules, then the first claim is false.
  - SebastianKra 3y ago
    This cannot be understated. I still remember the Java class where my teacher just couldn't explain to me the reason for getters and setters. It took me multiple years before I finally understood why they used to be so important. In my last year of university, I had a course, that primarily and uncritically discussed GOF Design Patterns without even mentioning how they relate to the improvements in programming languages since then.
    - sanderjd 3y ago
      Yep. But there are a few separate things: 1. I can't explain this because I have no idea why it is a thing and have just cargo culted it. 2. I came to this view through hard-won personal experience, but I don't really remember exactly the underlying situation. 3. I have good reasons for this, which I could explain, but I'm not going to invest the time in that, because it would be time consuming and I've had this same discussion a bunch of times before and I know I'm unlikely to sway you until you just get burned yourself. Unfortunately these are largely indistinguishable, leading many people to conclude that it's always #1.
      - SebastianKra 3y ago
        #3 I can begrudgingly accept. #1 and #2 are indistinguishable, even to yourself. If you don't remember the conditions that made you chose a solution, how can you be sure that they still apply now? I believe, as you get older, you tend to rely on these assumptions more and more, which is why it's us youngsters' job to question them. Ideally, both sides learn something :)

sanderjd 3y ago

Yeah I think it's really a good example of what I'm talking about. This is exactly the kind of thing that burns everyone eventually after they've done the job long enough, but which requires spilling a bunch of ink to describe why, which won't even work, because you just haven't been burned by it yet. And that's fine, this is just what accumulating experience is about. (And to make it worse, everyone's accumulated experience is different.)

SebastianKra 3y ago
If you find a way to share what I should watch out for, I'd appreciate it :)
- sanderjd 3y ago
  I mean, this particular thing is covered in various books and other kinds of "best practice" documentation. There isn't a particular reason why I, as a random commenter on HN, would be able to make a more convincing case for it. But it's also reasonable to question the stuff it says in books and best practices documentation - nobody wants to cargo cult everything, and a lot of what's been written is not right in my view - so to some extent I feel like people just have to get burned by things in order to internalize why certain advice is good. I don't find that answer satisfying, but I've been on both sides of it over and over again throughout my career, and this is as far as I've gotten toward a conclusion.
vorpalhex 3y ago
This is the poor sort of experience that leads to arbitrary rules without understanding. It is always about the comprehension of the end, not the form. These don't always burn everyone. Sometimes these are the right thing. They may not be the right thing at your shop, but the world of software is not just your little software. Long method names can lead to better, more readable testing and code. They can also be easier to mistype or be harder for non-native English speakers. Combining routing and logic can be very fast and easy, but can lead to hard to debug issues with sprawling projects. But not all projects are sprawling. If you think you are experienced and also buy deeply into any fixed rules, then the first claim is false.
- SebastianKra 3y ago
  This cannot be understated. I still remember the Java class where my teacher just couldn't explain to me the reason for getters and setters. It took me multiple years before I finally understood why they used to be so important. In my last year of university, I had a course, that primarily and uncritically discussed GOF Design Patterns without even mentioning how they relate to the improvements in programming languages since then.
  - sanderjd 3y ago
    Yep. But there are a few separate things: 1. I can't explain this because I have no idea why it is a thing and have just cargo culted it. 2. I came to this view through hard-won personal experience, but I don't really remember exactly the underlying situation. 3. I have good reasons for this, which I could explain, but I'm not going to invest the time in that, because it would be time consuming and I've had this same discussion a bunch of times before and I know I'm unlikely to sway you until you just get burned yourself. Unfortunately these are largely indistinguishable, leading many people to conclude that it's always #1.
    - SebastianKra 3y ago
      #3 I can begrudgingly accept. #1 and #2 are indistinguishable, even to yourself. If you don't remember the conditions that made you chose a solution, how can you be sure that they still apply now? I believe, as you get older, you tend to rely on these assumptions more and more, which is why it's us youngsters' job to question them. Ideally, both sides learn something :)