Don't focus too much on the solutions the presenter demonstrated but on the problems and he did a great job on that. I worked on a legacy project that suffered from the same problems demonstrated here and it was hell to refactor the code to a point to make it testable and easier to maintain as requirements grew larger. These are things every programmer should be aware of.
I found this to be a very interesting talk, even though I didn't like most of the final refactored code in the presentation. One thing I'd like to point out, though, is that the class (that IMHO really shouldn't be a class) didn't make testing better. You are testing internals, implementation details just for the sake of testing it. If you stopped one step before, would have been better (though again, at least I learned about the __bool__ function, so thanks for that).
I think the presentations you pointed to are really great! It's a bit strange that you'd mention them and then do a presentation that contains far more "write some classes" advice than I would consider idiomatic in Python. I found the advice about writing a class and defining a __bool__ really hacky, not pythonic and not "obvious" (not idiomatic will always imply "not obvious to the reader"). I'm also not convinced it's a good idea in terms of testing. You're testing the internals of the class, i.e. reimplementing the logic inside of the tests: why would I care that "November" is not an "ary" month, when all I want to know is if oysters are good to eat during that month?
i liked presentation, gives me more to learn and what others do... especially if you are learning, but not everything is or should become a class like others have said... but i think if your objects eventually become repeated code, classes will help out amazingly.
Good talk @brettorama , though I agree with other commenters that refactoring from functions to classes is probably a bad idea and a Java-ism that does not belong in Python land. You linked to the talk that people should stop using classes, so I will forgive you for that, though :) I have a comment on the tombstones you suggest at the end of your talk; it is not the *only* way to safeguard against setting pet.age = 5. Rather than sprinkle your code with superfluous tombstone properties, you could just add __slots__ = 'name', 'animal' to the Pet class.
That's only a temporary state. The backwards compatibility code lets you move everything over to the new and simpler usage. Then you remove all of the backwards compatibility and have a simpler design overall.
There are a bunch of reasons. If multiple people are working on the same codebase at the same time, you can get merge conflicts if you try to change everything all at the same time. When you're working alone, by doing backwards compatibility you have more of a chance to incrementally test each phase of a big change, instead of just crossing your fingers that it'll all work at the end.
I don't know, I doubt. Making such non-trivial backwards compatible changes makes the code more complex -- more probability for errors. But if you have tests, changing all the the code at once can more robust. While I agree that for a public API this can be a good approach. Anyway thanks for the talk.
Ah sorry. To be clear: I agree that this is overkill for many cases. There are other refactorings that you just do all at once. I wanted to show what it takes when things are more complex.
There is a small caveat to refactoring that is hardly mentioned: If refactoring MUST break the old functions, version! Refactoring, most times, leads to a completely new version. This way, you don't lose (a lot of) backward compatibility and can move forward to better software.
Sorry, but I don't think writing OystersGood class and TomatoesGood class is good design when simple functions suffices. Plus I find it hard to treat OystersGood(month=1) as a tangible object.
Can't we all just stop using these nonsense code examples with animals, cars, etc.? Would be way easier to follow along if people instead used real world scenarios such as a game, webshop, discussion board or what not.
The reason for using animals and cars is because it's generic. If you use real world code you would spend more time explaining the code witch is a waste of time.
@@tectubedk If presenter put more thought to it, they should be able to come up with examples that are closer to their audiences everyday experiences. Even if you sacrifice a bit in intuitive understanding and have to explain the example a bit, I often find it to be really really interesting to see an actual code example where some idea just discussed has been used to solve a real problem. In rapid fire talks which just give ideas one after another, it might be hard for presenter to do this, so I don't mind if someone just goes the easy route and uses person class or something to give really simplistic example, but I certainly do prefer one over the other if given a choice.
Omg. I've stopped watching at 12 min when functions bacame classes. Dude, never ever design your code this way. You should never have facilities that exist only because of tests.
hello, could you please elaborate? I always thought it is better to refactore code so that it is more testable (but I agree on the fact that theses classes are weird)
I don't think it's that weird. It's actually very cool, because by converting the function into a class, you can suddenly explicitly test the internal state that you don't have direct access to with the function. For example, in his example, he could explicitly test for "r" and "ary" just by accessing them directly as attributes of the class, which was impossible for him to do with the original function.
Martin Fowler fanboys should go back to Java and stop messing up good Python code with their practices that only make sense in Java. They already destroyed PHP years ago, and now found a new target.
oh boy, the one thing I learned by this video is that you should write things right on first attempt. refactoring is long boring stuff you better don't do.
![BLACK BAG - Official Trailer [HD] - Only in Theaters March 14](http://i.ytimg.com/vi/Du0Xp8WX_7I/mqdefault.jpg)
Don't focus too much on the solutions the presenter demonstrated but on the problems and he did a great job on that. I worked on a legacy project that suffered from the same problems demonstrated here and it was hell to refactor the code to a point to make it testable and easier to maintain as requirements grew larger. These are things every programmer should be aware of.
thank you Brett Slatkin, I have learned a lot from your book Effective python
I found this to be a very interesting talk, even though I didn't like most of the final refactored code in the presentation. One thing I'd like to point out, though, is that the class (that IMHO really shouldn't be a class) didn't make testing better. You are testing internals, implementation details just for the sake of testing it. If you stopped one step before, would have been better (though again, at least I learned about the __bool__ function, so thanks for that).
I think the presentations you pointed to are really great!
It's a bit strange that you'd mention them and then do a presentation that contains far more "write some classes" advice than I would consider idiomatic in Python.
I found the advice about writing a class and defining a __bool__ really hacky, not pythonic and not "obvious" (not idiomatic will always imply "not obvious to the reader").
I'm also not convinced it's a good idea in terms of testing. You're testing the internals of the class, i.e. reimplementing the logic inside of the tests: why would I care that "November" is not an "ary" month, when all I want to know is if oysters are good to eat during that month?
i liked presentation, gives me more to learn and what others do... especially if you are learning, but not everything is or should become a class like others have said... but i think if your objects eventually become repeated code, classes will help out amazingly.
Have a question. How is refactoring the class to include an animal as part of its __init__, superior to inheritance?
Good talk @brettorama , though I agree with other commenters that refactoring from functions to classes is probably a bad idea and a Java-ism that does not belong in Python land. You linked to the talk that people should stop using classes, so I will forgive you for that, though :)
I have a comment on the tombstones you suggest at the end of your talk; it is not the *only* way to safeguard against setting pet.age = 5. Rather than sprinkle your code with superfluous tombstone properties, you could just add __slots__ = 'name', 'animal' to the Pet class.
The example made the code after refactoring more complex with all this backwards compatibility stuff.
That's only a temporary state. The backwards compatibility code lets you move everything over to the new and simpler usage. Then you remove all of the backwards compatibility and have a simpler design overall.
Why not changing all the code at once, including the callers?
There are a bunch of reasons. If multiple people are working on the same codebase at the same time, you can get merge conflicts if you try to change everything all at the same time. When you're working alone, by doing backwards compatibility you have more of a chance to incrementally test each phase of a big change, instead of just crossing your fingers that it'll all work at the end.
I don't know, I doubt. Making such non-trivial backwards compatible changes makes the code more complex -- more probability for errors. But if you have tests, changing all the the code at once can more robust. While I agree that for a public API this can be a good approach. Anyway thanks for the talk.
Ah sorry. To be clear: I agree that this is overkill for many cases. There are other refactorings that you just do all at once. I wanted to show what it takes when things are more complex.
Great tips! Thank you for sharing
great talk!
I have to admit the comment section is more interesting and also more to my liking.
Exellent talking on rewriting python code~
I never saw Python 2, please give some idea how These things are best done in the Pythob-3 context
There is a small caveat to refactoring that is hardly mentioned: If refactoring MUST break the old functions, version! Refactoring, most times, leads to a completely new version. This way, you don't lose (a lot of) backward compatibility and can move forward to better software.
Sorry, but I don't think writing OystersGood class and TomatoesGood class is good design when simple functions suffices. Plus I find it hard to treat OystersGood(month=1) as a tangible object.
This is awesome. Really helped.
But the age belongs to the pet. Gila does not have age like it does scales, but Geraldo the Gila does have an age.
If we are talking about readability he sholdnt use .format() ?
i think the same , looks cleaner than %s
f-strings bro))
2016 bro.
Glitch in Matrix
Portland Oregon definitely reminds me of DAYS GONE 🤠
Can't we all just stop using these nonsense code examples with animals, cars, etc.? Would be way easier to follow along if people instead used real world scenarios such as a game, webshop, discussion board or what not.
+1
The reason for using animals and cars is because it's generic. If you use real world code you would spend more time explaining the code witch is a waste of time.
@@tectubedk If presenter put more thought to it, they should be able to come up with examples that are closer to their audiences everyday experiences. Even if you sacrifice a bit in intuitive understanding and have to explain the example a bit, I often find it to be really really interesting to see an actual code example where some idea just discussed has been used to solve a real problem.
In rapid fire talks which just give ideas one after another, it might be hard for presenter to do this, so I don't mind if someone just goes the easy route and uses person class or something to give really simplistic example, but I certainly do prefer one over the other if given a choice.
By the end of the talk .... The only word that came to my mind was, OVERKILL
yeah it kind of is. however these are great tips when working on a huge codebase. it’s hard to convey that in a short talk
Thanks!
Why don't you just use lru_cache?
I don't have tests. I figured tests was more of an advanced topic than refactoring but I guess not? :P
Omg. I've stopped watching at 12 min when functions bacame classes. Dude, never ever design your code this way. You should never have facilities that exist only because of tests.
hello, could you please elaborate?
I always thought it is better to refactore code so that it is more testable (but I agree on the fact that theses classes are weird)
I don't think it's that weird. It's actually very cool, because by converting the function into a class, you can suddenly explicitly test the internal state that you don't have direct access to with the function. For example, in his example, he could explicitly test for "r" and "ary" just by accessing them directly as attributes of the class, which was impossible for him to do with the original function.
Martin Fowler fanboys should go back to Java and stop messing up good Python code with their practices that only make sense in Java.
They already destroyed PHP years ago, and now found a new target.
oh boy, the one thing I learned by this video is that you should write things right on first attempt. refactoring is long boring stuff you better don't do.