4 ms·

In one project, I had a new teammate ask me why almost our entire web backend is a single .js file mostly filled with SQL queries. He wanted to make it his pers

In one project, I had a new teammate ask me why almost our entire web backend is a single .js file mostly filled with SQL queries. He wanted to make it his personal project to refactor this into probably 20 different files, adding more layers between the handlers and the DB stuff, using a query builder, and also migrating to TS. When I asked him what's wrong with the current thing, he couldn't answer and gave up on this idea. That backend had decent integration tests, and it took less than 5 minutes to add a small new feature. Most prod code doing comparable things where I work is worse-tested, less reliable, and at least 10X more expensive in terms of SWE-time, so I think modern programming standards are actually nonsense even though I can play along with them.

giraffe_lady 2y ago
Yeah I think I got this from Sandi Metz a long time ago but it's been so valuable to me: "bad code that you never have to modify is good code." Now when business requirements change and you're constantly sending people into that 1600 line backend function or whatever, it's likely worth it to start doing some refactors. But otherwise if I don't have a good reason to be in there I pretend I don't see it.
- hot_gril 2y ago
  I agree with the quote, but this was code that we did modify frequently. It was still ok. 1600 line func is bad, but 1600 line file, well that's what editor splits are for. A lot of app backends don't do much other than shoving stuff into a DB and getting it back.
  - lelanthran 2y ago
    > I agree with the quote, but this was code that we did modify frequently. Could still be the best approach, if by "modify" you meant "added new queries to an array of strings".
    - hot_gril 2y ago
      We'd edit queries or add new HTTP endpoints. Some did a little more than query, maybe hit a cache or external service. There were a few shared helpers, not more than one layer deep though.

giraffe_lady 2y ago

Yeah I think I got this from Sandi Metz a long time ago but it's been so valuable to me: "bad code that you never have to modify is good code." Now when business requirements change and you're constantly sending people into that 1600 line backend function or whatever, it's likely worth it to start doing some refactors. But otherwise if I don't have a good reason to be in there I pretend I don't see it.

hot_gril 2y ago
I agree with the quote, but this was code that we did modify frequently. It was still ok. 1600 line func is bad, but 1600 line file, well that's what editor splits are for. A lot of app backends don't do much other than shoving stuff into a DB and getting it back.
- lelanthran 2y ago
  > I agree with the quote, but this was code that we did modify frequently. Could still be the best approach, if by "modify" you meant "added new queries to an array of strings".
  - hot_gril 2y ago
    We'd edit queries or add new HTTP endpoints. Some did a little more than query, maybe hit a cache or external service. There were a few shared helpers, not more than one layer deep though.