4 ms·

+1000 to PRY, if something needs to possibly evolve separately dont force it into some shared abstraction, I think DRY probably causes the most bad code but we

+1000 to PRY, if something needs to possibly evolve separately dont force it into some shared abstraction, I think DRY probably causes the most bad code but we still keep doing it. Agree with mocks also, currently not even using them, just go with integration tests and set db back to known state between every test run, oh and wiremock for rest

margorczynski 2y ago
Yep, one of the basics I do now is a Docker compose with the DB, additionally it tests the migrations. There's little to no point in doing mocks if your logic is not really complicated where you would need to separate testing it from the integration test. I think a lot of people took "TDD" a bit too much to the heart and it ended up maligned where always more tests == better.
- coffeebeqn 2y ago
  People forget that software engineering is engineering sure, but also art and operations. Anything too dogmatic is going to have negatives and it’s kind of obnoxious when someone just quotes their “bible” when you’re trying to have an honest conversation. I know the book said so, but can we please just talk about the reality of our situation.
osigurdson 2y ago
One thing that annoys me to no end in our industry is lazy, unexamined phrase based development.
srid 2y ago
Related to PRY, see "rule of three" - which I think is a reasonable position between DRY and PRY. https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming) https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra... Rule of three ("Three strikes and you refactor") is a code refactoring rule of thumb to decide when similar pieces of code should be refactored to avoid duplication. It states that two instances of similar code do not require refactoring, but when similar code is used three times, it should be extracted into a new procedure.
coffeebeqn 2y ago
Bad abstractions have a heavy cost on readability and just your whole teams ability to reason about the program. If your “DRY” change PR removes 1 repeated piece of code but adds in 1 kind of nonsensical abstraction, 1 extra coupling between two pretty unrelated things that use that abstraction, 1 change to the input and output of the function, 1 test suite testing for two separate “things”, etc. it’s not sounding like such a clear positive contribution to the codebase. If we want to go by some of the old adages then a non-dogmatic reading of Single Responsibility - the abstraction should be about one thing - is pretty good in my book.
- 7bit 2y ago
  Django class based views come to mind. I feel the DRY principle made them an absolute mess if you a but more flexibility that what they bring by default. Or I'm just dumb.

margorczynski 2y ago

Yep, one of the basics I do now is a Docker compose with the DB, additionally it tests the migrations. There's little to no point in doing mocks if your logic is not really complicated where you would need to separate testing it from the integration test. I think a lot of people took "TDD" a bit too much to the heart and it ended up maligned where always more tests == better.

coffeebeqn 2y ago
People forget that software engineering is engineering sure, but also art and operations. Anything too dogmatic is going to have negatives and it’s kind of obnoxious when someone just quotes their “bible” when you’re trying to have an honest conversation. I know the book said so, but can we please just talk about the reality of our situation.

osigurdson 2y ago

One thing that annoys me to no end in our industry is lazy, unexamined phrase based development.

srid 2y ago

Related to PRY, see "rule of three" - which I think is a reasonable position between DRY and PRY. https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming) https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra... Rule of three ("Three strikes and you refactor") is a code refactoring rule of thumb to decide when similar pieces of code should be refactored to avoid duplication. It states that two instances of similar code do not require refactoring, but when similar code is used three times, it should be extracted into a new procedure.

coffeebeqn 2y ago

Bad abstractions have a heavy cost on readability and just your whole teams ability to reason about the program. If your “DRY” change PR removes 1 repeated piece of code but adds in 1 kind of nonsensical abstraction, 1 extra coupling between two pretty unrelated things that use that abstraction, 1 change to the input and output of the function, 1 test suite testing for two separate “things”, etc. it’s not sounding like such a clear positive contribution to the codebase. If we want to go by some of the old adages then a non-dogmatic reading of Single Responsibility - the abstraction should be about one thing - is pretty good in my book.

7bit 2y ago
Django class based views come to mind. I feel the DRY principle made them an absolute mess if you a but more flexibility that what they bring by default. Or I'm just dumb.