Page 3 of 3

Posted: Fri Oct 19, 2007 3:44 am
by Maugrim_The_Reaper
B/TDD
Jenk is leaking BDD ;)
Everah wrote:Ok, I am lost a little bit then. Don't we all want high efficiency, bullet proof code that not only works, but works well and securely? If the only review of the code is not even a code review but a test result review, how does that ensure the state of your code? Or am I looking at this the wrong way?
I wouldn't suggest dropping Code Review - but it's progressively of less value as the experience of the developer goes up. I think Kieran (finally ;)) got it right. Most developers don't know everything (nor even close) so code review offers a learning experience if done correctly. Pair programming is basically one continual code review exercise which is what makes it so effective.

At the same time - reviewing test cases or behavioural specs is really important. What's the point of pretty code with really ugly tests which cover nothing? This is even more important where B/TDD is not applied - test writing after the fact is quite a bit more difficult and it's easy to cop out and take the easy route of testing only what you can, and doing some quick or badly designed integration testing for the rest.
CoderGoblin wrote:I have looked at TDD and realise its usefulness but still cannot get my head around it (especially mocking database requirements which seem to make up the bulk of things I do). When I started coding I seem to remember being taught that 80% of code is input/output with 20% actual processing. TDD is great for that 20% but I remain unconvinced of it's place for the rest.
Depends on what you want to do with TDD - design or test? I had this argument with arborint before ;). TDD is focused on helping you design a system - not test it in all meaningful ways. After applying TDD there is a whole world of testing methods you still need to apply for similar reasons you explained. For example i/o is where a testing method like FIT (e.g. PHPFIT) and acceptance testing (Selenium/WebTest) can help - especially since you should use real world data for testing - not made up stuff or mocks which are "good enough" for TDD by itself (since it's designing not testing in depth).

An example I could use is a financial accounts system. Designing it might be very easy applying TDD or BDD, but afterwards you are not going to leave it at that. I would personally write the report damning you to hell ;). You'll have even more tests to add beyond what TDD provided. Maybe using FIT (which is pretty cool for testing against real data) or DBUnit (or PHP's clone of it).

Posted: Fri Oct 19, 2007 4:19 am
by Jenk
I'd not long been reading up on BDD again - and watching Dave Astel's Google tech talk on the subject (http://video.google.com/videoplay?docid ... 0081075324 - a worth while watch)

Pair Programming is good, it's been a while since I was in a workshop that did pair programming, but it is much more beneficial than reviewing; more time efficient because code is reviewed as it is written, and is also more time efficient because you have two people working on the same area who can bounce ideas off each other without interrupting. :)

Posted: Fri Oct 19, 2007 8:56 am
by Luke
We have an application like that. Unfortunately the programmer who had no foresight was me... I designed the application before I understood a lot of things about PHP, OOP, good practices, design patterns, unit testing, etc.

This application uses the Zend Framework. I wrote a fresh bootstrap file, a new application controller, and began using some libraries I wrote to make working with the Zend Framework a little easier (so basically a fresh install of the Zend Framework). I then wrote a plugin called MC2_Controller_Plugin_Legacy. Anything that I wanted to "phase out" of the application or eventually rewrite, is instantiated / configured / initiated in that plugin. I also have a directory called "legacy" which holds all of the controllers, models, and views I plan on phasing out / rewriting as well. Little by little I rewrite the legacy code with new code. It's working out pretty well. :)

Re: How to transition from bad code to good code.

Posted: Fri Oct 19, 2007 10:54 am
by RobertGonzalez
jamesmm wrote:I've recently started work at a new company. There are about 5 developers ranging in skill level, and I have about 10 years general programming experience, with 5+ years PHP and OO design.

The current code base on our application is not in a good state. It was inherited from a single 'programmer' who produced it with no forethought or knowledge of programming or design good practice.

...

The issue at hand is that the code base is bad, and I don't know how much thought has been put into improving it by the current team or by my manager....
I think my perspective is off a bit then. This conversation started out with a question of porting bad code to good code. It veered a little bit into TDD and Agile Methodologies and Pair Programming and code reviews and the what not. This is a very good discussion and one that seasoned or experienced developers can certainly relate to.

I supposed I am looking at this through the eyes of a seasoned developer (me) working side by side with a group of script kiddies that have used several Google-found tutorials to implement stuff on company sites that have become mission critical apps. These things were here before I got here and include crap from PHP 3 and PHP 4 using absolutely no OOP design principles (in fact, very little programming principles at all). I can honestly say in this case, tell the script kiddies to prepare unit tests or adopt Agile methodologies would be like explaining Calculus to a moose. I think that is why I wasn't following the discussion from the appropriate angle.

And I think that is why I am such a big proponent of code reviews. At least where I work. The coders that are trying to put code into production at the moment have very little experience developing real applications for real use in real production environments using real application development methods. If any of you would have seen the code I saw when I came on board, you would have, I suspect, requested that all code that goes into production be reviewed prior to being tested (in a production test environment) prior to being put into production.

Again, I think my questions were coming from a completely different perspective than most of the contributors to this thread. I apologize if I derailed anything.

Posted: Fri Oct 19, 2007 11:35 am
by Jenk
Quite Everah, but what I was attempting to show is that B/TDD can assist in transforming legacy code, and can make for effective reviewing - not entirely on their own, I agree, especially in legacy situations a proper review is warranted, but the gem is that in the future, you will be able to check, whenever you like, that the code is still functional because it would just take the simple running of a test case to see if it has broken or not.

B/TDD is a great tool for converting massive "HOLY POOP THAT'S A LOT OF WORK! Where do I begin?!" projects, into "Hey, that's a nice list of actions for me to do!" and is also great for keeping the developer focused on only the segment of code they are working on.

I'm sure we all know of pre-optimisation woes, be it our own that have come back to bite us, or having to look at/fix someone elses. Which was also my point about the ideal person who refactors is not aware of the change request. They are only given the revised test case and told to make the code pass without knowing why the test case has changed, so that they are not influenced to make those "convenient" short-cuts or extensions based on only the current change that make life difficult further down the road. :)

Posted: Fri Oct 19, 2007 11:37 am
by Christopher
Kieran Huggins wrote:The original question was "why still do code review if unit tests ensure everything will work anyway". I was arguing for keeping code review on the grounds that it also helps developers learn skills and techniques from each other in a peer environment, hopefully making better developers in the process.
Again, I think unit tests are to support refactoring, because without them changing code is dangerous. Fearless refactoring is at the core of Agile. And I think first goal of code review is to improve code. Developers improve by designing more and coding more ... and being exposed to new problems and ideas -- certainly code review can contribute to that, but so do many other things.

Posted: Fri Oct 19, 2007 12:47 pm
by Jenk
arborint wrote:Again, I think unit tests are to support refactoring, *snip*
(Just adding this to avoid any misunderstanding :)) That is not their sole purpose, they are a fantastic design tool as well as refactoring tool. They are also (obviously) great testing tools, without them automated testing would (I dare say) be impossible. We are aiming to have a machine sat in the corner running tests autonomously ad to alert us when a failure pops up, so we can intervene immediately and identify which change broke the tests.

Posted: Fri Oct 19, 2007 1:20 pm
by Christopher
I agree .. and there are other reasons such as tests being documentation. Those are all happy side-effects as far as the programmer is concerned. But I still say from point of view of the programmer actually coding that units tests are mainly to support refactoring. You can build and refactor code without them, but with them as support the programmer is a different beast.

Posted: Fri Oct 19, 2007 6:01 pm
by Kieran Huggins
I don't disagree, arborint, except that I think the first goal of code review is to produce better coders, by helping them produce better code.

I know it looks like semantics, but I believe there's an important nuance there worth noticing. We're basically in full agreement 8)

Posted: Fri Oct 19, 2007 6:43 pm
by Christopher
I am very sure we agree in principle. We do disagree on the semantics and nuance. ;) I say the direct goal of code review is to produce better code; the long term byproduct is exposure to better design and code. That may produce better coders.