Klassediagrammer mm.

1)  Man bør tegne diagrammerne først og kode bagefter

2)  Det er meget forskelligt om der laves UML eller ej, forskelligt fra firma
    til firma og forskelligt fra projekt til projekt indenfor samme firma

3)  Efter min personlige opfattelse er UML diagrammer mest nyttige
    high level d.v.s klasse diagram med de vigtige klasser evt. med
    de vigtigste metoder og sekvens eller aktivitets diagrammer som viser
    det helt overordnede flow. Et klasse diagram med 20 klasser som i gennemsnit
    har 10 attributter og 10 metoder gør sig godt som Picasso maleri, men
    giver ikke meget overblik.

Med hensyn til de konkrete spørgsmål. Vise .NET klasser man arver fra ?
Afhænger af om det er vigtigt ! Jeg ville aldrig vise System.Object, men
System.Collection.CollectionBase ville jeg nok angive. Dependcies ? Afhænger
igen af om det er vigtigt for forståelsen.

Jeg mener et diagram som flg. er yderst brugbart, det er vel heller ikke det du mener med picasso?
http://robosim.user.cis.ksu.edu/tiki-index.php?page=Robot+UML+dependency+diagram

Men er en depency ikke vigtig for forståelsen?

Jeg har mest lyst til at tegne klassediagrammer og tilstands diagrammer først og derfra diskutere yderligere i detalje om den bagvedliggende kode.
Men alle kender vil til det lille hurtige stykke kode der bare lige skulle og vupti så var det pludselig noget helt andet. Derfor kommer man vel til at sidde og dokumentere bagefter. Vi har faktisk en fyr inde hos os der påstår dokumentering er overflødig når man bruger extremeprogramming *S*

Nej - det kan lige gå. Selvom jeg synes at det er ved at være tæt på grænsen
for hvor mange detaljer man kan læsse på.

---

Måske. Det afhænger vel lidt af problem stillingen og dem der skal bruge
diagrammet.

---

Hvorfor pokker skulle dokumentation være overflødigt med XP ?

Om ikke andet så kunne man jo dele det ind i mere beskrivende klynger...
Anyway... XP skulle være selvforklarende hmmm, altså noget med at fordi der havde siddet flere ind over så er dokumentation ikke nødvendig. Funktionsnavnene ville i sig selv være beskrivende for projektet :O) - Ja jeg er nu heller ikke enig i disse betragtninger, men ville bare lige høre din mening også.

Jeg lader lige spørgsmålet stå åbent lidt endnu, der kan være flere der har gode kommentarer.

Hygge og tak

Med XP så er der flere som har set koden - om ikke andet så de to der har skrevet
koden sammen.

Men:
  - hvad nu hvis de alle forlader firmaet ?
  - hvis nu hvis koden skal vedligeholdes af en anden afdeling eller eksterne konsulenter ?
  - hvad nu hvis nogen vil danne sig et overblik over systemet ?`
  + 717 andre tilfælde

Jamen vi er helt enige, jeg tror faktisk bare det er folks opfattelse af extrem der spiller ind og bliver misforstået.

Jeg fandt denne her artikel: http://www.agilemodeling.com/essays/agileModelingXP.htm
Kig evt. under 2.4 han begrunder den opfattelse ret fint :O)

Hos os er det meget forskelligt hvor meget og i hvor vide omfang der bliver dokumenteret. Det afhænger igen af projektet, tidspresset og projektdeltagerne.
Jeg forsøger dog som regel altid at lave noget dokumentation. For mit vedkomne afhænger det af hvor kompleks koden er.

Hvis det er kompleks kode laver jeg altid et klasse diagram der viser de mest avancerede klasser og deres afhængigheder. Jeg tegner næsten aldrig metodenavne på. Istedet laver jeg en tekstlig beskrivelse af konceptet som jeg lægger ved modellen.
Jeg beskriver kun det mest komplekse da det er trivielt og det spilder folks tid at beskrive Run(), Kill(), null constructor, ToString() osv osv.

Hvis koden ikke er kompleks laver som regel en kort beskrivelse af hvad koden gør og hvorfor. Dette lægges ved koden enten som word doc eller som en simpel .txt fil.

I begge tilfælde, og dette er langt det vigtigste mener jeg, laver jeg in-line kommentarer i koden. Bare et par få ord om _hvorfor_ koden gør som den gør kan hjælpe den næste der læser koden ekstremt meget. bemærk at det er vigtigt at beskrive _hvorfor_ koden er der og ikke _hvad_ koden udfører da enhver vil kunne læse sig frem til hvad den gør. Beskriv kun hvad koden gør hvis det er tunge rekursive kald eller lign.

Min overordnede mening om dokumentation er at der altid bør være kommentarer i kode.
Modeller, beskrivelser osv bør der være hvis koden er kompleks. Yderligere mener jeg at ethvert firma med respekt for sig selv bør have en standard for hvordan de dokumenterer deres kode.

Om der bliver brugt UML eller andet er for så vidt lige meget. selvfølgelig ville det at væer at foretrække at alle bruger UML, men i nogle tilfælde er det mere intuitivt at improvisere nogle tegninger.

Tid at få afsluttet spørgsmålet ?