Nice to see someone who's talking about refactoring legacy to actually start from a really ancient example and gradually introducing modern practices. You should get rid of using the mysql extension though :) FYI: You have a very hangover-friendly way of taking :) Very nice talk!
A good talk with a realistic real-world example. No immediate jumping to design pattern refactoring.
Some slide composition would have helped to keep track of the topic. The Dependencies / Action / Response would have been clearer if it was all on screen at once, maybe as a flow chart. And side-by-side code comparisons would have had more of an impact instead of jumping back and forth.
The round up and the end was good, letting the audience know what to look at in the future to carry on.
A good talk although I felt it might have been clearer titled. Especially as the physical programmes had no hint as to content; Ideally the word refactoring should have featured in the title.
Enjoyable, but not quite what I expected. I did expect refactoring, but with the "into 2014", I expected more "in previous versions of PHP you were probably doing X, but since PHP 5.5 (or 5.6), you should be probably using Y"
As commented, I've found it it very hard not (!) to refactor existing code at times where a tight schedule was used as an argument to forbid it by management.
I fully agree with Robert C. Martin, Martin Fowler, and the like, who suggest to refactor along the way while you're reading code, given you intend to work on it.
Boy-scouting rules!
However, you can easily refactor yourself into a corner where no one is willing to review or merge your PR if the culture on a team / project doesn't allow for it.
Some important principles (no new functionality) and good tips along the way. Steadily delivered - I actually think you could go a bit faster and further. And book tips always appreciated!
Slightly misleading title, but the content of the talk was valuable, the example was well thought out, and the presented refactoring philosophy has given me things to think about.
Pretty good talk that gives a clear overview of how you could go about refactoring legacy code and why and when you would do that. But that was not what I expected form the title.
I did find the talk a bit slow at times and I think speeding it up a bit would also help in presenting it just a little bit better.
A well structured talk that was presented well, but I agree with some of the others that a mention of refactoring in the title or description would have been useful.
Must admit ive been of the mentality it needs a rewrite this talk has given me some tips on progressive re-factoring the book linked at the end of the talk has been purchased!
As a "Refactoring 101", it was a great talk, delivered very well, demonstrating good practice for refactoring. The idea of boy scouting is my new favourite way of telling people to not make things worse when they're working with old code. For that talk you get 5 stars.
The problem is that the talk given didn't match the abstract or the talk title. In terms of the talk title, there was nothing in this talk to help bring your application into 2004, let alone 2014. The principles are sound, but I've seen code like the example this started with 10 years ago, and refactored it in the style shown just a couple of years later.
The abstract mentions "This includes eradicating singletons and reducing the dependencies of our unit tests (no need to connect to a DB any more!)". I was particularly interested in this talk because we have a very large test suite that does connect to the database, and it takes minutes to run. But there was no mention of this refactoring, or unit tests, other than it being essential to write tests before you start refactoring.
Oh and in pedantry corner: "Thank you" is two words.
I really enjoyed this talk, a great real world example of a script we all have on a server somewhere that we keep skipping around.
some great tips on how to go about re factoring code without getting stuck in the rewrite/never deploy cycle we have all gotten a foot stuck in at one time or another.
A great talk, which gave some useful ideas and advice regarding refactoring and handling legacy code, however, it was not quite what I expected from the title alone.
Raised some good points (especially refactoring versus re-coding), and the example-driven talk made the content much clearer. My only real comment is that I was expecting the scope to be broader than just refactoring (although important in its own right).
The content was very good as a refactoring talk. I'm not sure the talk title was most suitable though and Michael could perhaps take fewer pauses and try keep the momentum going, especially as it's a Sunday morning slot.
Comments
Comments are closed.
A clear concise well presented talk.
Example led which clearly helped to reinforce and show how to easily and effectively improve your application.
Mentioned the books for further reading and investigation is always useful.
Nice to see someone who's talking about refactoring legacy to actually start from a really ancient example and gradually introducing modern practices. You should get rid of using the mysql extension though :) FYI: You have a very hangover-friendly way of taking :) Very nice talk!
A good talk with a realistic real-world example. No immediate jumping to design pattern refactoring.
Some slide composition would have helped to keep track of the topic. The Dependencies / Action / Response would have been clearer if it was all on screen at once, maybe as a flow chart. And side-by-side code comparisons would have had more of an impact instead of jumping back and forth.
The round up and the end was good, letting the audience know what to look at in the future to carry on.
A good talk although I felt it might have been clearer titled. Especially as the physical programmes had no hint as to content; Ideally the word refactoring should have featured in the title.
Enjoyable, but not quite what I expected. I did expect refactoring, but with the "into 2014", I expected more "in previous versions of PHP you were probably doing X, but since PHP 5.5 (or 5.6), you should be probably using Y"
As commented, I've found it it very hard not (!) to refactor existing code at times where a tight schedule was used as an argument to forbid it by management.
I fully agree with Robert C. Martin, Martin Fowler, and the like, who suggest to refactor along the way while you're reading code, given you intend to work on it.
Boy-scouting rules!
However, you can easily refactor yourself into a corner where no one is willing to review or merge your PR if the culture on a team / project doesn't allow for it.
Probably time to move on, then.
I'm a fan of Michaels talk and maybe was hoping for something a little different but was good nevertheless.
Wasn't sure whether to expect refactoring or language features. The content was good and thank you for the book references, very useful
Some important principles (no new functionality) and good tips along the way. Steadily delivered - I actually think you could go a bit faster and further. And book tips always appreciated!
Slightly misleading title, but the content of the talk was valuable, the example was well thought out, and the presented refactoring philosophy has given me things to think about.
Pretty good talk that gives a clear overview of how you could go about refactoring legacy code and why and when you would do that. But that was not what I expected form the title.
I did find the talk a bit slow at times and I think speeding it up a bit would also help in presenting it just a little bit better.
A well structured talk that was presented well, but I agree with some of the others that a mention of refactoring in the title or description would have been useful.
Good talk.
Must admit ive been of the mentality it needs a rewrite this talk has given me some tips on progressive re-factoring the book linked at the end of the talk has been purchased!
The second talk I've heard Mike give. I enjoy his presentation style and find he's a clear communicator.
The downside of this was the title, it felt misleading. Still, I enjoyed the content and delivery.
This is a tough one to rate.
As a "Refactoring 101", it was a great talk, delivered very well, demonstrating good practice for refactoring. The idea of boy scouting is my new favourite way of telling people to not make things worse when they're working with old code. For that talk you get 5 stars.
The problem is that the talk given didn't match the abstract or the talk title. In terms of the talk title, there was nothing in this talk to help bring your application into 2004, let alone 2014. The principles are sound, but I've seen code like the example this started with 10 years ago, and refactored it in the style shown just a couple of years later.
The abstract mentions "This includes eradicating singletons and reducing the dependencies of our unit tests (no need to connect to a DB any more!)". I was particularly interested in this talk because we have a very large test suite that does connect to the database, and it takes minutes to run. But there was no mention of this refactoring, or unit tests, other than it being essential to write tests before you start refactoring.
Oh and in pedantry corner: "Thank you" is two words.
I really enjoyed this talk, a great real world example of a script we all have on a server somewhere that we keep skipping around.
some great tips on how to go about re factoring code without getting stuck in the rewrite/never deploy cycle we have all gotten a foot stuck in at one time or another.
A great talk, which gave some useful ideas and advice regarding refactoring and handling legacy code, however, it was not quite what I expected from the title alone.
Raised some good points (especially refactoring versus re-coding), and the example-driven talk made the content much clearer. My only real comment is that I was expecting the scope to be broader than just refactoring (although important in its own right).
The content was very good as a refactoring talk. I'm not sure the talk title was most suitable though and Michael could perhaps take fewer pauses and try keep the momentum going, especially as it's a Sunday morning slot.