4 ms·

In order for code to be maintainable it first has to be readable. The second example has poor readability. And that's even before we get to the issue that thi

by bborud 3y ago

In order for code to be maintainable it first has to be readable. The second example has poor readability. And that's even before we get to the issue that this approach has fallen out of favor exactly because it result in code that can be a pain in the neck to figure out. Please don't do this. This is the kind of legacy approach that I try to teach people working for me NOT to follow.

shortrounddev2 3y ago
> The second example has poor readability Only if you don't know C# or asp.net (or bootstrap). In which case: why would you be working for an organization which does? > And that's even before we get to the issue that this approach has fallen out of favor exactly because it result in code that can be a pain in the neck to figure out. This kind of structured approach has fallen out of favor because it's become more popular to hire javascript and react developers straight out of boot camp who have only been taught how to code one or two things. The argument that code needs to be inherently readable to someone with 3 weeks of experience is how you get hundreds of poorly written spaghetti code microservices written in node or typescript and not a language better suited for backend development. If you want your code base to constantly look like it was written by someone following their first javascript tutorial, then by all means continue using this top-level express JS crap > Please don't do this. This is the kind of legacy approach that I try to teach people working for me NOT to follow. You are setting yourself up for some bad tech debt in the future
- badrequest 3y ago
  > Only if you don't know C# or asp.net (or bootstrap). In which case: why would you be working for an organization which does? You've never taken a job working in a language you don't know yet? Anecdotally this is a common thing. In fact, my most recent job hired me to write C# with nothing but prior Go/Python experience. > This kind of structured approach has fallen out of favor because it's become more popular to hire javascript and react developers straight out of boot camp who have only been taught how to code one or two things. This comes across to me as needlessly bitter to folks with less experience than you.
  - shortrounddev2 3y ago
    > You've never taken a job working in a language you don't know yet? Anecdotally this is a common thing. In fact, my most recent job hired me to write C# with nothing but prior Go/Python experience. So then it shouldn't be a problem for you to learn a new skill based on a very common pattern with many examples in different languages > This comes across to me as needlessly bitter to folks with less experience than you. If those folks are forcing the business to make tech decisions based on their lack of experience, it makes life harder for others. If you are going to choose between "should we write our backend in C# or javascript", and the decision comes down to "well our bootcamp grads don't know C# and they don't have a background in software engineering, so getting them up to speed on C# will take months", then you're willingly choosing inferior tech to make up for subpar employees
    - bborud 3y ago
      You appear to think that there is One Way to write applications and that anyone who disagrees with you doesn't know what they are talking about or has never had any experience with them. Perhaps you should be open to the possibility that you're wrong in assuming that? Perhaps there are people who dislike these kinds of designs precisely because they have experience with them? (hint: I wrote my first IoC container/framework about 20 years ago)
      - shortrounddev2 3y ago
        > You appear to think that there is One Way to write applications and that anyone who disagrees with you doesn't know what they are talking about or has never had any experience with them. You are wrong in your perception
- nicoburns 3y ago
  I personally find that the second example has poor readability even if you are familiar with the framework/pattern. I've worked on codebases that use each of those patterns, and I greatly prefer those where all of the routes (and ideally the auth middleware too) are defined in a single top-level routes file. IMO it makes it much easier to get an overview of the overall functionality of the app, and to find the code which implements each route. It's also a lot more flexible if you ever need to support routes which do not fit the conventional pattern of the framework (perhaps for legacy reasons). You can of course still use dependency injection, etc with this central route registration model.
  - shortrounddev2 3y ago
    I can understand that view, but I like to have the controller class files themselves represent the site hierarchy. Rather than looking in a file for the appropriate route, I look through the filesystem to understand the routing. I expect FooController to map to /foo (or /api/foo or whatever). I worked on a django project which did all the routing in a single location and it frequently resulted in merge conflicts between multiple developers committing changes to the file about the same time
- bborud 3y ago
  > is how you get hundreds of poorly written spaghetti code So what you are saying is that the IoC / Decorator approach is the way to avoid spaghetti code? That's an interesting assertion. > You are setting yourself up for some bad tech debt in the future You mean like being saddled with a product that depends on a large framework that fewer and fewer people want to deal with? The way to avoid tech debt is to retain plasticity, keep more options open and not paint yourself into a corner where your choice of framework dictates how you structure entire systems. And, of course, to hire people based on talent and ability rather than a line on their CV that promises experience with a given framework.

by bborud 3y ago

shortrounddev2 3y ago

> The second example has poor readability Only if you don't know C# or asp.net (or bootstrap). In which case: why would you be working for an organization which does? > And that's even before we get to the issue that this approach has fallen out of favor exactly because it result in code that can be a pain in the neck to figure out. This kind of structured approach has fallen out of favor because it's become more popular to hire javascript and react developers straight out of boot camp who have only been taught how to code one or two things. The argument that code needs to be inherently readable to someone with 3 weeks of experience is how you get hundreds of poorly written spaghetti code microservices written in node or typescript and not a language better suited for backend development. If you want your code base to constantly look like it was written by someone following their first javascript tutorial, then by all means continue using this top-level express JS crap > Please don't do this. This is the kind of legacy approach that I try to teach people working for me NOT to follow. You are setting yourself up for some bad tech debt in the future

badrequest 3y ago
> Only if you don't know C# or asp.net (or bootstrap). In which case: why would you be working for an organization which does? You've never taken a job working in a language you don't know yet? Anecdotally this is a common thing. In fact, my most recent job hired me to write C# with nothing but prior Go/Python experience. > This kind of structured approach has fallen out of favor because it's become more popular to hire javascript and react developers straight out of boot camp who have only been taught how to code one or two things. This comes across to me as needlessly bitter to folks with less experience than you.
- shortrounddev2 3y ago
  > You've never taken a job working in a language you don't know yet? Anecdotally this is a common thing. In fact, my most recent job hired me to write C# with nothing but prior Go/Python experience. So then it shouldn't be a problem for you to learn a new skill based on a very common pattern with many examples in different languages > This comes across to me as needlessly bitter to folks with less experience than you. If those folks are forcing the business to make tech decisions based on their lack of experience, it makes life harder for others. If you are going to choose between "should we write our backend in C# or javascript", and the decision comes down to "well our bootcamp grads don't know C# and they don't have a background in software engineering, so getting them up to speed on C# will take months", then you're willingly choosing inferior tech to make up for subpar employees
  - bborud 3y ago
    You appear to think that there is One Way to write applications and that anyone who disagrees with you doesn't know what they are talking about or has never had any experience with them. Perhaps you should be open to the possibility that you're wrong in assuming that? Perhaps there are people who dislike these kinds of designs precisely because they have experience with them? (hint: I wrote my first IoC container/framework about 20 years ago)
    - shortrounddev2 3y ago
      > You appear to think that there is One Way to write applications and that anyone who disagrees with you doesn't know what they are talking about or has never had any experience with them. You are wrong in your perception
nicoburns 3y ago
I personally find that the second example has poor readability even if you are familiar with the framework/pattern. I've worked on codebases that use each of those patterns, and I greatly prefer those where all of the routes (and ideally the auth middleware too) are defined in a single top-level routes file. IMO it makes it much easier to get an overview of the overall functionality of the app, and to find the code which implements each route. It's also a lot more flexible if you ever need to support routes which do not fit the conventional pattern of the framework (perhaps for legacy reasons). You can of course still use dependency injection, etc with this central route registration model.
- shortrounddev2 3y ago
  I can understand that view, but I like to have the controller class files themselves represent the site hierarchy. Rather than looking in a file for the appropriate route, I look through the filesystem to understand the routing. I expect FooController to map to /foo (or /api/foo or whatever). I worked on a django project which did all the routing in a single location and it frequently resulted in merge conflicts between multiple developers committing changes to the file about the same time
bborud 3y ago
> is how you get hundreds of poorly written spaghetti code So what you are saying is that the IoC / Decorator approach is the way to avoid spaghetti code? That's an interesting assertion. > You are setting yourself up for some bad tech debt in the future You mean like being saddled with a product that depends on a large framework that fewer and fewer people want to deal with? The way to avoid tech debt is to retain plasticity, keep more options open and not paint yourself into a corner where your choice of framework dictates how you structure entire systems. And, of course, to hire people based on talent and ability rather than a line on their CV that promises experience with a given framework.