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

CPAN and XP

Expand Messages
  • Rob Nagler
    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. ... Not per se. It s a given,
    Message 1 of 4 , Jan 28, 2002
    • 0 Attachment
      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 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. XP requires
      the team agree on a coding style which is the anthesis of TIMTOWTDI.

      > So you get the CVS access to the sources of CPAN modules you need to
      > work with. e.g. your book is anti-XP then, as you don't let the readers
      > the CVS access :) Not sure whether XP applies to documentation, (which
      > is the case with the book).

      Readers are customers. Customers don't code. Customers write
      stories, and developers implement them. XP mandates a hardline
      between these two activities. OS development is tangential to the XP
      approach. I could see a collocated developing OS. I don't see very
      many OS projects applying XP practices. In particular, discussions in
      OS between users and developers are often centered on how to implement
      something (sending in patches, discussing architecture, what other
      packages are applicable, etc.). XP is about empowering customers to
      decide the "what" and the developer to decide "how".

      > I've heard here and there about XP, including chromatic's talk at OSC.
      > But I didn't have a chance to read more about it, just yet. So I'm
      > looking forward to getting educated while reading/reviewing your book.

      To me, it is a lot of stuff I've been already doing. It's nice that
      it is served up in a bite-sized meal. Certainly makes it easy to
      write about. :)

      Rob
    • marceusz@aol.com
      In a message dated 28-Jan-02 6:15:30 PM GMT Standard Time, nagler@bivio.biz ... Actually I don t find either of these to be particularly true. While it is true
      Message 2 of 4 , Jan 28, 2002
      • 0 Attachment
        In a message dated 28-Jan-02 6:15:30 PM GMT Standard Time, nagler@... writes:


        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.  XP requires
        the team agree on a coding style which is the anthesis of TIMTOWTDI.


        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.

        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.

        Isee "Code Style" however comming in with the other major audiance for code, the other developers. If the next poor schmuck is expecting to see $this_is_arg1 and instead gets $thisIsArg1 (or possibly @_[1]) this becomes much more a stylistic problem. The two statments are identical, just rely upon different syntactic differences. The team each need to be able to "write with one voice" so it appears that one coder developed the entire piece.

        This is my tuppence ... for what it's worth.
        -Chris

      • 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 3 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 4 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.