01. juni 2006 - 17:03Der er
18 kommentarer og 1 løsning
Struktureret programmerings teknik
Jeg har for lang tiden siden gået på et af Niels Brocks kurser om programmering. Det var den gang Turbo Pascal for dos var oppe i tiden.
Der lærte vi bl.a at man skulle sætte sig ned og skrive på et stykke papir, på dansk, linje for linje hvad programmet skulle gøre inden man overhovedet satte sig foran PC'en. F.eks: sådan her 1. Indtast første tal i feltet A 2. Instast andet tal i feltet B 3. Læg felt A og B sammmen 4. Udskriv resultat af A og B.
Jeg har desværre glemt teknikken og søger derfor nogle steder på nettet hvor man lærer denne teknik eller andre smartere metoder til at programmere.
Er der nogen af jer der kender nogle gode steder hvor disse teknikker står beskrevet ?
PS. Programmering sproget er ikke det væsentlige her.
Det er nok ikke lige noget som der ligefrem findes en tutotorial på, og det kan iøvrigt variere fra person til person.
Der er aldrig nogen som ved deres fulde fem ville sætte sig ned og skrive komplet pseudo kode for et bare nogenlunde stort program. Normalt ser man det kun for algoritmer, og andre små programstumper som kan siges at kunne stå alene.
Der findes mange forskellige teknikker - og forskellige former for logik-charts - så hvad I præcist har brugt, er ikke til at sige.
Ingen programmør ved sine fulde fem ville nogen sinde sætte sig til at lave en større applikation uden først at dokumentere den. At det så ofte sker alligevel, skyldes nok, at ikke mindst 'web-sprogene' er så let tilgængelige, at mange, der ikke har lært at kode, koder alligevel. I det klientel er 'cowboy-kodning' til gengæld nok normen :)
At kode en større applikation uden først at dokumentere den, svarer til at bygge et højhus uden arbejdstegning. Selv et hønse- eller legehus uden arbejdstegning er svært at få op at stå ;o)
Visio i Office-pakken understøtter en lang række forskellige notations metoder/tekniker. Hvis du har den, kan det være, der er noget, du kan genkende :)
> Ingen programmør ved sine fulde fem ville nogen sinde sætte sig til at lave en større applikation uden først at dokumentere den.
Enig, men at designe (hvilket er noget andet end at dokumentere) programmet via pseudo kode er ikke lige den bedste fremgangsmåde. Man vil sædvanligvis designe mindre kodestrumper (algoritmer) på denne måde, men det overordnede overblik fås snare via klassediagrammer, tilstandsdiagrammer, kontekstdiagrammer, uses cases og andre tilsvarende UML-teknikker.
Visual Studio 2005 har i øvrigt klasse-diagrammering indbygget. Det hjælper selvfølgeligt ikke så meget hvis man ikke arbejder i .Net i det aktielle tilfælde.
> Der lærte vi bl.a at man skulle sætte sig ned og skrive på et stykke papir, på dansk, linje for linje hvad programmet skulle gøre inden man overhovedet satte sig foran PC'en.
- som jeg brokkede mig over.
Man kommer ikke uden om at lave et ordentligt design før at man begynder at kode. Der er mange værktøjer og teknikker til dette, og pseudo kode har absolut sin berettigelse. Med at skrive et helt program i pseudo kode... Nej.
Jeg har allerede nævnt klassediagrammer, tilstandsdiagrammer, kontekstdiagrammer og use cases. Dette er blot nogen af de diagramerrings-teknikker som indgår i UML (Unified Modeling Language). Uheldigvis egner Eksperten sig ikke ligefrem til at give eksempler på dette, men du finder (igen) en masse eksempler ved at Google.
UML har fokus på Objekt Orienteret programmering, og dette dækker langt de fleste programeringssporg som er i brug i dag (med nogle enkelte væsentlige undtagelser). Uanset hvad, så er det dog teknikker som kan benyttes også når det ikke er OOP.
1. sæt resultat = tal / 2 2. sæt resultat = (resultat + tal / resultat) / 2 3. test om resultat*resultat er tæt på tal 4. hvis ikke så gå til punkt 2
pseudo kode -----------
resultat = tal / 2 loop resultat = (resultat + tal / resultat) / 2 until tal-EPS < resultat*resultat < tal+EPS
Det ligner ikke hinanden.
Det samme kunne også vises med god gammel flowcharting med nogle rektangler og nogle romber md pile imellem.
UML er beregnet til objekt orienteret A/D/P og en algoritme som denne her er meget lidt objektorienteret. Men skulle man bruge UML så kunne man bruge et activity diagram til det.
----------
Der skal absolut laves en masse papir (dog evt. på elektronisk form) inden man starter på at kode et større projekt. Men kun en meget lille del af det er egentlig design.
Mængden af design dokumenter varierer naturligvis mellem forskellige virksomheder og projekter: - ingenting - nogle få overordnede beskrivelser før start og så noget mere detaljeret som dokumentation bagefter - detaljerede beskrivelser inden man starter
Min erfaring er at det ikke kan betale sig at lave for detaljeret design inden man starter. Fordi så kommer koden alligevel ikke til at ligne designet og så skal den alligevel laves om.
Medmindre man bruger MDA, så skal design docs ikke vise alt det koden viser, men give overblik. Kernen i overblik er ikke at medtage unødvendige detaljer.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
