Sådan planlægger du din applikation. Del 1. Daniel Frost ejer ActiveDeveloper.dk. Daniel er udvikler med fokus Microsofts produkter og frameworks og driver til dagligt sit eget konsulent firma som du kan finde på code101.dk. Daniel har bl.a. udviklet systemer og applikationer for Berlingske Tidende, Carlsberg og Microsoft.
Læs mere om Daniel Mellgaard Frost | Artiklen er sponsoreret af:
|
 Diskuter denne artikel i forummet. 
Efter flere henvendelser fra medlemmer, har jeg taget intiativet til at skrive en artikel serie omkring hvordan man kan planlægge sin applikation. Det er uanset om det er web, windows eller noget helt tredje.
Der er flere indgangsvinkler til et sådan emne, og mange vil nok mene noget anderledes end jeg selv, men uanset hvad så er planlægning vigtigt.
Det første trin jeg tager når jeg ved jeg skal udvikle en ny applikation er at snakke med de mennesker der har med projektet at gøre. Det kan være din kunde, din projektleder, din ven, men i den grad også dig selv. Det er vigtigt du forstår helt præcist hvad behovet er for den nye applikation, også selvom applikationen er til eget brug.
Dette er netop ovenstående trin de fleste ikke udøver og kommer derfor let til at udvikle en defekt, langsom, snørklet, bug-fyldt applikation.
Hvis nu din applikation var et forum ligsom det vi har på ActiveDeveloper.dk, kunne du spørge dig selv spørgsmål såsom:
Skal forummet vise en oversigt hvor forum beskederne er i en træstruktur?
Skal man logge ind for at oprete en besked?
Skal man kunne opdatere sine beskeder?
Skal man kunne slette sine beskeder?
Faktisk er kun 2 af de ovenstående spørgsmål virklig gældende i første omgang, og det er det nummer 1 og 2. Mere om det senere.
Når du har stillet dig selv disse spørgsmål, er det en meget god idé at få dem skrevet ned. Det gør jeg ihvertfald, fordi det er så let at glemme en feature, og det kan hurtigt blive kritisk hvis faeturen er fundamental for selve applikationen. Så find en blok papir og start med at lave nogle krudseduller og mock-ups af hvad du har tænkt dig.
Hvis applikationen ikke til dig selv, så sørg for at finde ud af, og dokumenter (jeg kan ikke stresse dette nok) hvad kunden, chefen eller din ven helt nøjagtigt skal bruge. Skriv det ned i en slags specifikation (teknisk og funktionel) og forklar med nemme sætninger hvad applikationen forventes at kunne.
F.eks kan din funktionelle forum specifikation indholde noget lignende:
Forum besked:
En forum besked kan kun oprettes hvis du er logget ind som bruger.
Det er nemt nok ik'?
Så vender vi lige tilbage til de 2 spørgsmål vi stillede os selv tidligere, og hvorfor kun de er vigtige. De 2 første.
Når du udvikler software er der en meget stor tendens til at ville udvikle noget helt vildt og voldsomt. Lad være med det til at starte med. Det er der flere årsager til.
Hold det så simpelt og nemt som muligt i første omgang. Vælg kun de absolut nødvendige ting til din applikation, ikke så få, så den ikke giver mening men heller ikke så mange så den bliver uoverskuelig. Det er et godt trick at lære sig selv, mest fordi du hurtigt vil finde ud af, at du faktisk levere noget og ikke kun udvikler på et uendeligt stykke software.
Det er bedre at levere noget mindre som virker end slet ikke at levere. Det bliver du, kunden og din chef kun gladere for og du kan sove trygt og varmt om natten :0)
Det første spørgsmål er vigtigt fordi det fortæller os lidt om hvordan vi skal lave vores data model.
Hvis noget skal være som en træstruktur ligsom herpå ActiveDeveloper.dk, så skal din data model kunne håndtere det man kan kalde parent-child i uendelighed. Parent-child betyder i uendelighed betyder sådan set bare at når du opretter et forum indlæg under et andet, så refere det nye indlæg til det øverste, og sådan kan det jo fortsætte. En anden løsningen kunne være at man bare hele tiden referede til det øverste indlæg uanset hvor mange indlæg der var i den pågældende trå, men så kunne vi ikke lave en træstruktur. Derfor er det vigtigt, faktisk både funtionelt og teknisk.
Hvis man skal være logget ind for at stille et spørgsmål i vores forum, skal man vel på en eller anden måde kunne oprette en bruger. Derfor er spørgsmål 2 vigtigt, og hvis svaret er ja så har det igen inflydelse på både den tekniske og funktionelle specifikation.
Spørgsmål 3 og 4 er overflødige fordi vi ikke behøver de 2 ting i vores første udgave af forummet, og sagtens kan leve uden. Det sparer os endda for noget tid og er med til at levere hurtigere.
Andre ting du skal have svar på inden den første line kode og designer den første database, er emner såsom fejl håndtering, platform og fleksibilitet.
Fejl håndtering er vigtigt fordi vi alle har forskellige måder hvorpå vi håndtere vores fejl. Der findes forskellige kategories af fejl. Direkte fejl i systemet. Fejl når en bruger indtaster invalid data i login felterne. Fejl når en side ikke findes. Alt sammen noget som udgør en del på brugervenligheds siden og som bør tænkes seriøst over.
Platform kan være vigtigt fordi at planlægge også, især hvis andre skal have adgang til systemet eller hvis en speciel funktionalitet skal bruges til applikationen. Det kunne f.eks være man valgte .NET 2.0 til sin applikation pga. sikkerheds mæssige hensyn. Det ville dog også betyde at man f.eks ikke kunne bruge LINQ på indersiden af applikationen. Database er også en platform, og der er stor forskel på om du vælger en MySQL database eller en MS SQL database.
F.eks kunne man vælge Access frem for MS SQL i version 1 fordi du så slipper for licens kroner, men du mister så måske også noget performance på lang sigt. I sådan situation ville jeg altid vælge Access og opgradere hvis det blev nødvendigt.
Hvis du tænker dig rigtig godt om inden du starter med at udvikle, så vil din applikation altid være fleksibel, og bliver du ved med at tænke dig godt om når du udvider den, mister den højst sandsynligt ikke sin fleksibilitet.
Det er dyrt at være meget fleksibel, men det er også dyrt ikke at være det, så derfor er det en balance gang mellem at planlægge og udvikle lidt ad gangen.
Nu har vi snakket lidt om hvordan du skal tænke dig om inden du starter med din udvikling. Næste gang skriver jeg en teknisk specifikation som en artikel så du kan se hvordan sådan en bliver til.
Code on  | Kommentarer fra vores community medlemmer |  |  |  |
Bliv medlem af vores communityDu skal være medlem af vores community for at kommentere siden.
 Klik her for at blive medlem (det er 100% gratis) |
Community: 
Afstemning
