nop has asked for the wisdom of the Perl Monks concerning the following question:
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: Extreme programming... in perl?
by chromatic (Archbishop) on Jan 09, 2001 at 09:29 UTC | |
I'm using Test::Unit (with props to our own clemburg) and doing the test-first, refactor mercilessly, write and complete stories approach with the Perl Rogue project. It's hard to gauge the whole XP thing with a single-man program, but it's promising so far. Writing unit tests before code is pretty different, but it's the only way I'd get good test coverage. The one thing I've noticed so far is that the combination of writing stories (to describe self-contained bits of functionality) and coding only as much as you need to pass the current test and complete the current story is improving code clarity and development speed. I don't have to plan for three or four different things at once. When I do come back to existing code, it's easier to make it more flexible (if necessary) because I have a specific and immediate goal in mind. It's also harder to break things without knowing it, because all of the previous unit tests that must pass before you're finished. This makes bugfixing easier, too, especially with multiple people on a project. A couple of weeks ago, I fixed a bug in Everything, creating another in the process. Darrick fixed the bug I created, recreating the bug I fixed. If I'd written a test to detect the bug I'd found, Darrick would have noticed it and come up with the correct solution immediately. (As he's a smart guy, he picked right up on it before I brought it up. But this could have been much worse.) Currently, I'm trying to introduce some XP principles into Jellybean development. Only time will tell how successful we are there. I'm not yet confident enough with Test::Unit to know how to write good tests for some of the hairier bits there. | [reply] [Watch: Dir/Any] |
by puck (Scribe) on Jan 10, 2001 at 01:54 UTC | |
I hope you will write up your experiences about applying XP to Perl in a couple of months time. I'm currently just starting to play with Smalltalk as this is the XP language. However, if we can apply the techniques to Perl easily (and it works) then this would be very cool. Cheers! (And I'm off to look at Test::Unit...) | [reply] [Watch: Dir/Any] |
Re: Extreme programming... in perl?
by dws (Chancellor) on Jan 09, 2001 at 12:15 UTC | |
Over the past year I've borrowed a few practices from Extreme Programming for my own (mostly solo) Perl projects, with mostly positive results. The practices I've adopted are: Writing tests cases first has a couple of benefits. First is that the test cases actually get done! My experience has almost always been that leaving test cases until the end means that they get squeezed out of the schedule, or overlooked in the mad rush forward. The second benefit is subtle: to write a test case you need to think about the objects you'll be testing, how they'll behave and interact, and how you can verify that they've behaving and interacting correctly. This is a very grounded approach. By approaching class design this way, rather than in some fanciful imaginative vacuum, you get testable classes, and method signatures that make sense to at least one client (the test case code). Next up comes implementation. "Do the simplest thing that can possibly work" says just that. Defer complexity until you actually discover (in some future story) that you need it, and do something simple (and correct) to implement the story in user story in front of you. If you're modifying existing classes, do the simplest correct thing you can think of to effect the modification. (Here's where having a body of test cases that cover prior stories really pays off. If you broke something, you get to find out right away, while it's still fresh in your head.) Refactoring means cleaning up the code. It's kind of like cleaning up the kitchen after cooking. Better to do it right away, so that you can start with a clean environment the next morning. More correctly, "refactoring" refers to a set of transformations you can do on code that maintain correctness. Discovering that you're performing the same operation in two different subroutines, and then extracting the operation into a new subroutine is one refactoring. (See Martin Fowler's excellent book "Refactoring: Improving the Design of Existing Code" for more info.) Here's where I force myself to find and resolve any #FIXME comments left in the code, and have second thoughts about using some neat-but-obscure trick picked up from PerlMonks. I've been using these practices for about a year now. The biggest problem I've had is fighting off the continual temptation to design ahead. On reflection, I have to admit that much of design ahead work I've done in years past has been wasted "premature generalization." I'd have been better off saving the code and investing that time elsewhere. But it is still soooo tempting to design reusable packages in my head before coding the parts that I actually need now. Along the way I built a simple yet quite effective test harness (applying the "do the simplest thing that could possibly work" dictum). It needs a bit of work to get it up to PerlMonks standards before I'll post it. And sometimes I take my Extreme Programming hat off for a round of Perl Golf. | [reply] [Watch: Dir/Any] [d/l] |
Re: Extreme programming... in perl?
by clemburg (Curate) on Jan 09, 2001 at 13:50 UTC | |
In my experience, the biggest problem is to persuade the organization you are working in to allow or even encourage pair programming. Most big organizations seem to feel pair programming is a waste of time (of course it is not!). In contrast, I feel that pair programming is responsible for the biggest change effects that Extreme Programming has to offer - better team work, more people "in the know", faster learning curve for everybody on the team, cleaner designs and code, less "quick and dirty" work, more fun. The other big thing about Extreme Programming is the emphasis on testing, obviously. But this has been there before - just read chapter 6 of The Practice of Programming by Brian W. Kernighan, or chapter 25 of Code Complete by Steve McConnell.
Christian Lemburg | [reply] [Watch: Dir/Any] |
Unit tests as Clue stick
by dws (Chancellor) on Jan 09, 2001 at 23:26 UTC | |
On a two hour layover between flights earlier this year I fired up the laptop to get in a bit of coding time, and to try out some ideas I'd had on the first leg of the trip. After about 20 minutes of typing, I fired off my test driver, which at the time would run through about 40 test scripts, reporting whether each passed, failed, or failed to run. (Each test script covered several tests; giving an effective coverage of about 120 tests.) 16 of the 40 tests failed. Pause... Think... Hm.. I hadn't eaten in a while, had just gotten off a bumpy flight, and was anxious about the weather on the next leg. Plus I'm sitting on the floor of the terminal in San Diego at one of the two available AC outlets, the place is packed with travelers, and kids are crying. Maybe this isn't the best time to be coding... If I keep going, I'm just going to add a bunch of bugs that I'll feel compelled to fix on the next flight, at altitude, where the air is a bit thinner and my brain won't be working as well. Back out the changes, shut down the laptop, and trundle off in search of food. | [reply] [Watch: Dir/Any] |
Re: Extreme programming... in perl?
by knight (Friar) on Jan 09, 2001 at 20:11 UTC | |
Amplifying on dws's comments above, once a project grows beyond a certain size, it's the fact that I have all of the unit tests as a regression test base that enables me to refactor effectively. Before becoming converted to writing the unit tests first, I'd always reach a point on a project where I knew that certain internal subsystems needed to be completely rewritten, but rewriting them was usually painful because it would take a lot of by-hand testing to try to make sure I hadn't broken anything. And even then, I'd often not discover that my laborious ad hoc testing still missed some end case until the code was in the field... With a good set of tests created incrementally during development, I can refactor and know that I haven't broken an interface. And if the tests are still missing an end-case and a bug slips through the cracks, well, another test gets created when the code gets fixed, and that's another situation that's guaranteed never to cause a problem in the future. This makes the whole development cycle more productive than I had ever imagined. Very powerful, and very addictive. | [reply] [Watch: Dir/Any] |
by cat2014 (Monk) on Jan 10, 2001 at 00:36 UTC | |
The only problems we've run into are that some folks type dvorak & some type qwerty- there are always pairs forming where only 1 person can actually type faster than 1 letter a minute on the keyboard being used. (; | [reply] [Watch: Dir/Any] |
by extremely (Priest) on Jan 10, 2001 at 02:48 UTC | |
-- | [reply] [Watch: Dir/Any] |
by cat2014 (Monk) on Jan 10, 2001 at 04:11 UTC | |
by tilly (Archbishop) on Jan 10, 2001 at 05:58 UTC | |
by Anonymous Monk on Feb 03, 2001 at 00:57 UTC | |
actually we had the same problem with keyboard layouts until I discovered a solution...if you're using Windows as your workstation (I'm sure you can do the same thing for Linux workstations, too, I just don't know how) you can go into the Control Panel and hit the Keyboard icon. From there you can add new layouts from the Input Locales tab. So add either Dvokak or Qwerty depending on what you don't have. Once you're done, at the bottom of the "Input Locales" is a hot key selection which allows you to switch layouts on the fly on a per-window basis. So my partner and I often switch and hit Left Alt+Shift to switch between layouts on our terminal windows. It makes pair programming much easier. | [reply] [Watch: Dir/Any] |
Re: Extreme programming... in perl?
by petemar1 (Pilgrim) on Feb 12, 2005 at 19:08 UTC | |
While I personally haven't used XP regarding Perl, ExtremePerl exists. | [reply] [Watch: Dir/Any] |