However presenter pointed out several important things. And separate thanks for mentioning that you're refactoring not because you have spare time to waste, but when you actually want to change the code and not satisfied with what you currently have (I believe this should be mentioned in every refactoring-related talks).
P.S. If this talk was offered as 3 hour hands-on tutorial, I'd definitely make more out of it (and Benjamin will finally have enough time to show everything he planned to).
There was some good tips for handling refactoring (when, why) but the amount of content was too much for the time allotted for the session. This would probably work better as a longer hands-on tutorial session.
Nice to a combination of refactoring and design patterns. Could have been better if the refactorings were done more structured. Maybe 45 minutes is just too short anyway.
One of the more interesting talks of the day. Finally some code rather than "here is an idea, I like it, bye". Benjamin obviously knows what he's talking about and I was glad to see he knows about the different factory design patterns :).
Would've been better if there was more time for the talk, but that's my only complaint.
the content and ideas in the talk are really good and very useful to beginner and people stuck in legacy.
The live coding format however leaves it hanging and loses the crowd. having steps prepared in advance or code in the slides may help focus more on the concepts and less in the writing and physics.
Clear and well structured presentation which made clear to me what refactoring is all about. It will help me with a big refactoring job ahead. To bad you could not use all the examples you prepared. I would have loved to see those as well. Thanks!
The point about making small changes was made pretty quickly and the live coding after that seemed unnecessary. This made the presentation as a whole slow and dry. A bit more focus on the patterns themselves could have made it more interesting.
I think this talk needs a split between live coding and some form of automated code examples. The live coding at the start is good, to get a real feel of the tiny steps needed to properly refactor (without tests). But once that point is driven home, a recording of "live coding" would suffice. That would guarantee that there are no typo's, no confusing backtracks and more importantly, more pace to reach the end of the material.
A very interesting presentation. Unfortunately the timing was a bit poor and at the end the speaker had to rush and skip over some of the more interesting examples.
Very nice talk, you could use a bit more time, 45minutes is maybe just not enough. Very nice hands on examples. A bit chaotic at moments but you got the general idea.
I don't think that live coding was such a big problem (it went quite well ;). However, I would have liked to see more. It's a great idea to only take very little steps, which is particularly helpful when you don't have tests (and you don't intend to write them). It's just nice to see all the little steps that are part of a true refactoring process. But many times I wished you would take somewhat bigger steps, in order to get to the next point.
Saw this one before and found out it mostly matched with what me and my colleagues do so. But I've never seen a better 'boring' talk than this one since I fully agree with the methodology. The people whom I recommended to go and see this talk were inspired. It actually is soo simple, but the thing is keep on doing it and do it in small steps. Good thing you keep pointing that out.
Comments
Comments are closed.
To be fair, It's a topic that is hard to make interesting and unfortunately my attention was lost @ 50% of the talk...
I for me it was interessting all the way
A bit too sketchy for my taste.
However presenter pointed out several important things. And separate thanks for mentioning that you're refactoring not because you have spare time to waste, but when you actually want to change the code and not satisfied with what you currently have (I believe this should be mentioned in every refactoring-related talks).
P.S. If this talk was offered as 3 hour hands-on tutorial, I'd definitely make more out of it (and Benjamin will finally have enough time to show everything he planned to).
interesting ! good patterns for refactoring. :)
PS : if you missed it, the link is -> http://qa.fo/dpc14
Dry but informative. :)
Nice talk with soms handson example
There was some good tips for handling refactoring (when, why) but the amount of content was too much for the time allotted for the session. This would probably work better as a longer hands-on tutorial session.
Interesting talk although I allready use the mentioned design patterns. For me the way (process) of refactoring was refreshing.
Nice to a combination of refactoring and design patterns. Could have been better if the refactorings were done more structured. Maybe 45 minutes is just too short anyway.
Good stuff but as others said... too much content for the short amount of time.
One of the more interesting talks of the day. Finally some code rather than "here is an idea, I like it, bye". Benjamin obviously knows what he's talking about and I was glad to see he knows about the different factory design patterns :).
Would've been better if there was more time for the talk, but that's my only complaint.
A bit dry, too little time. I think we skipped the most important example. But very informative. Fixing code in session was a good example to follow.
the content and ideas in the talk are really good and very useful to beginner and people stuck in legacy.
The live coding format however leaves it hanging and loses the crowd. having steps prepared in advance or code in the slides may help focus more on the concepts and less in the writing and physics.
Clear and well structured presentation which made clear to me what refactoring is all about. It will help me with a big refactoring job ahead. To bad you could not use all the examples you prepared. I would have loved to see those as well. Thanks!
Quite elementary. Pace was slow.
Quite elementary. Pace was slow.
quite basic, had expected a bit more. still nicely done.
The point about making small changes was made pretty quickly and the live coding after that seemed unnecessary. This made the presentation as a whole slow and dry. A bit more focus on the patterns themselves could have made it more interesting.
Interesting topic but presentation was mostly one very specific example.
I was expecting more from this presentation because I know speaker can deliver more content and perhaps timing needed more preparation.
I think this talk needs a split between live coding and some form of automated code examples. The live coding at the start is good, to get a real feel of the tiny steps needed to properly refactor (without tests). But once that point is driven home, a recording of "live coding" would suffice. That would guarantee that there are no typo's, no confusing backtracks and more importantly, more pace to reach the end of the material.
A very interesting presentation. Unfortunately the timing was a bit poor and at the end the speaker had to rush and skip over some of the more interesting examples.
Very nice talk, you could use a bit more time, 45minutes is maybe just not enough. Very nice hands on examples. A bit chaotic at moments but you got the general idea.
The live coding part was really great. I learned something new. That was one of the most interesting talks at the conference.
I don't think that live coding was such a big problem (it went quite well ;). However, I would have liked to see more. It's a great idea to only take very little steps, which is particularly helpful when you don't have tests (and you don't intend to write them). It's just nice to see all the little steps that are part of a true refactoring process. But many times I wished you would take somewhat bigger steps, in order to get to the next point.
Saw this one before and found out it mostly matched with what me and my colleagues do so. But I've never seen a better 'boring' talk than this one since I fully agree with the methodology. The people whom I recommended to go and see this talk were inspired. It actually is soo simple, but the thing is keep on doing it and do it in small steps. Good thing you keep pointing that out.
Well explained mini tutorial on how refactoring in small steps is a lot easier than refactoring in big steps.
Too bad Benjamin (again) didn't get to the end in time.
Overall a nice talk with good info, though I expected a bit more.