This was an interesting exercise in reviewing some of the "pearls" in various open source projects. It would be much more interesting and useful, though, if presenters would give a little bit more insight in the train of thought that goes into the code review process and maybe present some examples that can show audience some traits to avoid (and why -- performance, security, reliability etc.) and some other traits to acquire.
Would make it much more fruitful experience, so members of audience can leave the presentation having learned something instead of just looking at what stupid things other people have done. For that we all have enough humiliation reviewing our own code from some time ago :-)
On the positive side, I enjoyed seeing Sebastian Bergmann's phploc tool. It really showed at a glance the cost as well as the audaciousness of the CakePHP project to try and make up for PHP 4's lack of OOP.
80mg of memory to say Hello World is a lot, and I wouldn't start to use CakePHP until they support php 5.3+, especially after seeing this code review... but bravo to Nate for starting such an interesting project and on the success they've had.
On the downside, it was kind of like having Wayne Gretzky, Roger Federer & Babe Ruth on stage cherry picking to criticize, the worst games that high school players of their sport played...
Federer on how Rafa Nadal can improve = fascinating. But Wayne Gretzky on how a minor leaguer with bad technique sucks, not so much.
As Oleg was pretty much saying, I'd like to have seen this top notch team of coders take mediocre code or even good code and show how they would approach it to make it awesome code.
Picking apart examples is pretty easy but I agree that looking at the *process* and strategy behind a Code Review would be incredibly powerful. Further, when the trio were reworking group-provided live code, this is an even better presentation.
Comments
Comments are closed.
This was an interesting exercise in reviewing some of the "pearls" in various open source projects. It would be much more interesting and useful, though, if presenters would give a little bit more insight in the train of thought that goes into the code review process and maybe present some examples that can show audience some traits to avoid (and why -- performance, security, reliability etc.) and some other traits to acquire.
Would make it much more fruitful experience, so members of audience can leave the presentation having learned something instead of just looking at what stupid things other people have done. For that we all have enough humiliation reviewing our own code from some time ago :-)
On the positive side, I enjoyed seeing Sebastian Bergmann's phploc tool. It really showed at a glance the cost as well as the audaciousness of the CakePHP project to try and make up for PHP 4's lack of OOP.
80mg of memory to say Hello World is a lot, and I wouldn't start to use CakePHP until they support php 5.3+, especially after seeing this code review... but bravo to Nate for starting such an interesting project and on the success they've had.
On the downside, it was kind of like having Wayne Gretzky, Roger Federer & Babe Ruth on stage cherry picking to criticize, the worst games that high school players of their sport played...
Federer on how Rafa Nadal can improve = fascinating. But Wayne Gretzky on how a minor leaguer with bad technique sucks, not so much.
As Oleg was pretty much saying, I'd like to have seen this top notch team of coders take mediocre code or even good code and show how they would approach it to make it awesome code.
Picking apart examples is pretty easy but I agree that looking at the *process* and strategy behind a Code Review would be incredibly powerful. Further, when the trio were reworking group-provided live code, this is an even better presentation.