Loading ...
Sorry, an error occurred while loading the content.

Re: [extremeperl] CPAN and XP

Expand Messages
  • Ed Grimm
    ... I d say it s a natural consequence of testing. Who finds bugs then releases the code? ... I disagree - modular programming is necessary for XP, but OO is
    Message 1 of 4 , Jan 28, 2002
    • 0 Attachment
      On Mon, 28 Jan 2002, Rob Nagler wrote:

      > Stas and I were having a conversation. I'm moving it here, because it
      > is exactly the type of stuff I need to understand better.
      >
      > Stas Bekman writes:
      >> Hmm, Isn't debug an essential part of the XP?
      >
      > Not per se. It's a given, like breathing. My focus in the book is on
      > things that aren't really covered in other Perl or XP books while
      > giving a little background. For example, I'll mention pair
      > programming, but it's covered ad nauseum elsewhere. While I did take
      > time to discuss pair testing which is only briefly touched on in most
      > XP books. In general, testing is really important in Perl, because of
      > its dynamism.

      I'd say it's a natural consequence of testing. Who finds bugs then
      releases the code?

      >> I think CPAN doesn't contradict XP, since most its users are non-XP'ers.
      >> Imagine the headache for the authors if they had to respond to the
      >> problems that are being in the progress of fixing.
      >
      > It's very tough to talk about CPAN modules and XP, because they don't
      > apply OO principles consistently. I consider consistency, OO and,
      > information hiding to be prerequisites for refactoring.

      I disagree - modular programming is necessary for XP, but OO is not.
      And, incidentally, just like it's possible to do C++ spaghetti code,
      it's also possible to do non-modular OO (though it likely requires a
      concerted effort...)

      And, incidentally, one can refactor any code - refactoring is simply the
      process of improving code without functional changes; normally code
      cleaing on steroids. The modularity is required by the unit tests -
      without modularity, you can't isolate the units to test them.

      > XP requires
      > the team agree on a coding style which is the anthesis of TIMTOWTDI.

      No contest - no project can thrive for long with an inconsistant style.

      Ed
    • Rob Nagler
      ... Excellent point. ... I like this. One of the points I try to make in the refactoring chapter is that every refactoring has and equally valid converse.
      Message 2 of 4 , Jan 29, 2002
      • 0 Attachment
        marceusz@a... wrote:
        > Actually I don't find either of these to be particularly true. While
        > it is true that XP works easier with the OO paradigm, One of the XP
        > books states explicitly that it's not required ... and there is
        > nothing in XP per-se that requires Objects be the results of your
        > code.

        Excellent point.

        > Second coding-style does not neccessarily equate identical solution ...
        > TIMTOWDI is the essence of Refactoring. Refactoring expands, and "codefies"
        > if you will the idea of TIMTOWDI ... if your code is icky you find another
        > less icky way to code it.

        I like this. One of the points I try to make in the refactoring
        chapter is that every refactoring has and equally valid converse.
        I'll try to work in TIMTOWDI in this chapter.

        > This is my tuppence ... for what it's worth.

        It's weight in gold, thanks.

        Rob
      Your message has been successfully submitted and would be delivered to recipients shortly.