NYCPHP Meetup

[Matthew Terenzio]

It is not only Extreme Programming which employs iterative development 
and refactoring. I'll quote from Craig Larman's "Applying UML and 
Patterns", which uses the Unified Process to exemplify quality 
Object-Oriented Analysis and Design:

". . .there is neither a rush to code, nor a long drawn out design step 
that attempts to perfect all details of the design before programming. 
A "liitle" forethought regarding the design with visual modeling using 
rough and fast UML drawings is done; perhaps a half or full day. . .The 
result of eachiteration is an executable but incomplete system. . .
"


On Jul 21, 2004, at 9:50 PM, Tim Gales wrote:

>  Adam Maccabee Trachtenberg writes
>> On Wed, 21 Jul 2004, Tim Gales wrote:
>>
>>> Ah yes, the old we'll refactor it later ('packed into a lib
>> later') --
>>> very similar to we'll document that later.
>>
>> XP is a software engineering methodology that removes
>> dependencies in your code and places them upon your developers.
>>
>> The only reason you're allowed (required) to write the
>> simplest code possible is that you're required to refactor it
>> mercilessly. Failing to do the second invalidates the first.
>
> If I understand refactoring, it means to rearrange your classes and
> methods so that common code is more easily inherited from or delegated
> to with the goal removing duplicated code (or code which expressed
> another way -- but with identical meaning -- would be a duplicate).
>
> I am under the impression that the goal is to achieve some sort of
> 'ne plus ultra' state with no (or very little) duplication of code so
> that you can enhance a routine in just one place (since it is not
> duplicated anywhere else -- or hardly anywhere else).
>
> Mixed in with the methodology is also a concept of delivering
> working pieces of code early. And from what I can make of the
> reasoning behind this is that once users use the working
> pieces, they may change their mind about what they want the
> final system to do.
>
> And so it would seem that one of the lines of reasoning which
> argues for this way of doing things is that you can avoid wasting
> time creating a 'wrong' design initially -- and you should (to some
> degree) discover what the design is, and the design may be changing
> along the way, from building working parts of the system.
>
> In theory I guess this could work. But it strikes me that if the
> deadline for delivering the system overtakes you, you might run
> the risk of delivering a system into production without much of a
> coherent design -- though you would have avoided an initially
> wrong design.
>
> The result would be an awkward system where developers
> would have to memorize the places where pockets of code must updated
> together -- of course this is  something which can happen anyway when
> you do things the 'old fashioned' way.
>
> I will be the first to admit that I don't fully comprehend this method.
> But it just strikes me as fraught with danger -- maybe that's why it
> is called 'Extreme'
>
> T. Gales & Associates
> 'Helping People Connect with Technology'
>
> http://www.tgaconnect.com
>
> _______________________________________________
> talk mailing list
> talk at lists.nyphp.org
> http://lists.nyphp.org/mailman/listinfo/talk