Pogledajte određenu poruku
Staro 28. 02. 2006.   #17
Milos Vukotic
Knowledge base
Wrote a book
 
Avatar Milos Vukotic
 
Datum učlanjenja: 07.06.2005
Lokacija: Neđe ođe...
Poruke: 1.197
Hvala: 339
688 "Hvala" u 178 poruka
Milos Vukotic je pravi dragi kamenMilos Vukotic je pravi dragi kamenMilos Vukotic je pravi dragi kamenMilos Vukotic je pravi dragi kamenMilos Vukotic je pravi dragi kamenMilos Vukotic je pravi dragi kamenMilos Vukotic je pravi dragi kamen
Default

Ilija, jednostavno se ne slazem
XP tj. extreme programming metode po kojima se prvo pisu testovi, zatim pravi cijeli program u uproscenoj varijanti su sasvim ok, ali bez dizajna se ne moze. Ne kazem ni ja da uml-ovati sve do detalja poput Help->About, ali blueprint je neophodan. Ja obicno skrabam na papiru, kruzim i krizam, ali mi je mnogo lakse kodirati kad znam kuda idem
Evo ti citat iz knjige "Code complete" od Steve McConnell-a:

Citat:
The image of “building” software is more useful than that of “writing” or“growing” software. It’s compatible with the idea of software accretion and provides more detailed guidance. Building software implies various stages of planning, preparation, and execution that vary in kind and degree depending on what’s being built.
When you explore the metaphor, you find many other parallels.

Building a 4-foot tower requires a steady hand, a level surface, and 10 undamaged beer cans. Building a tower 100 times that size doesn’t merely require 100 times as many beer cans. It requires a different kind of planning and construction altogether.

If you’re building a simple structure—a doghouse, say—you can drive to the lumber store and buy some wood and nails. By the end of the afternoon, you’ll have a new house for Fido. If you forget to provide for a door or make some other mistake, it’s not a big problem; you can fix it or even start over from the beginning. All you’ve wasted is part of an afternoon.
This loose approach is appropriate for small software projects too, If you use the wrong design for 1000 lines of code, you can refactor or start over completely without losing much. If you’re building a house, the building process is a more complicated, and so are the consequences of poor design. First you have to decide what kind of house you want to build—analogous in software development to problem definition. Then you and an architect have to come up with a general design and get it approved. This is similar to software architectural design. You draw detailed blueprints and hire a contractor. This is similar to detailed software design. You prepare the building site, lay a foundation, frame the house, put siding and a roof on it, and plumb and wire it. This is similar to software construction. When most of the house is done, the landscapers and painters come in to make the best of your property and the home you’ve built. This is similar to software optimization.
...
Greater complexity and size imply greater consequences in both activities. In building a house, materials are somewhat expensive, but the main expense is labor. Ripping out a wall and moving it six inches is expensive not because you waste a lot of nails but because you have to pay the people for the extra time it takes to move the wall. You have to make the design as good as possible so that you don’t waste time fixing mistakes that could have been avoided. In building a software product, materials are even less expensive, but labor costs just as much. Changing a report format is just as expensive as moving a wall in a house because the main cost component in both cases is people’s time.
__________________
Чак Норис може да си ги врзе врвките на чевлите со стапалата.
Milos Vukotic je offline   Odgovorite uz citat