31 svar · 1 043 visningar · startad av hebbarus · sida 2 av 2
Hej. Jag har börjat göra hemsidor med PHP nu igen och har bland annat gjort en förenings hemsida. Själva kodandet har gått bra men det som har brustit är själva planeringen. Hur ska man lägga upp ett större projekt? Ska man börja med sidnamn och beskrivning, därefter siddesign, databasstruktur, templates och kod eller? Mvh Daniel
Läs frågan i sin helhet →Det är sant det du säger, spango, men det kan även bero på att arbetet inte är tillräckligt planerat, eftersom man "upptäcker" nya saker både på datanivå och gränssnittsnivå. Planeringen innefattar ju "simulering" av gränssnittet i allra högsta grad, så då bör man upptäcka sådana saker.
Personligen föredrar jag att börja i dataänden (om vi bortser från all planering), det vill säga databasen och sedan utforma allting uppåt: databasstruktur > klasstruktur > affärslager > gränssnitt.
Pace skrev:
Det är sant det du säger, spango, men det kan även bero på att arbetet inte är tillräckligt planerat, eftersom man "upptäcker" nya saker både på datanivå och gränssnittsnivå. Planeringen innefattar ju "simulering" av gränssnittet i allra högsta grad, så då bör man upptäcka sådana saker.
Personligen föredrar jag att börja i dataänden (om vi bortser från all planering), det vill säga databasen och sedan utforma allting uppåt: databasstruktur > klasstruktur > affärslager > gränssnitt.
Klassstrukturen borde väl ligga före databasstrukturen?
Jag håller med spango, det är oftast på det sättet det blir. Men som duktig student så vet jag ju att det inte är sättet man _bör_ arbeta på.
Fast det viktiga är väl egentligen att man arbetar på ett sätt som funkar!
Pace skrev:
Det är sant det du säger, spango, men det kan även bero på att arbetet inte är tillräckligt planerat, eftersom man "upptäcker" nya saker både på datanivå och gränssnittsnivå. Planeringen innefattar ju "simulering" av gränssnittet i allra högsta grad, så då bör man upptäcka sådana saker.
Planering ger (teoretiskt sett) aldrig bättre resultat än användartester. Just webbprojekt brukar väl iofs vara tillräckligt triviala för att det inte ska dyka upp några större överraskningar, men det finns ju undantag. Kolla bara på GMail och deras "labels" i stället för mappstrukturer, ett genidrag, imho. Jag skulle nog gissa att det är ett resultat av rätt många användartester.
Pace skrev:
Personligen föredrar jag att börja i dataänden (om vi bortser från all planering), det vill säga databasen och sedan utforma allting uppåt: databasstruktur > klasstruktur > affärslager > gränssnitt.
Vad skiljer ett "affärslager" mot en klasstruktur i dina ögon?
Själv brukar jag inleda med UI och klasstruktur, och när man väl kommit en bit på den vägen börjar man koda och testa för att se om det går att göra som man tänkt. Visst kan man väl upptäcka sånt genom att planera, men å andra sidan, varför skulle det vara bättre att upptäcka sådant efter några timmars svettande vid en whiteboard i stället för efter några timmars svettande vid ett tangentbord? ;) I min erfarenhet ökar nyttan av varje timme modellerande logaritmiskt - till sist står man bara och idisslar och har tråkigt (och en uttråkad utvecklare är inte särskilt produktiv).
Databasstrukturen är i mina ögon mest en restprodukt, ett nödvändigt ont, som kommer överlägset sist. Vill man ha fram en fungerande prototyp är det den delen som spelar absolut minst roll. När man väl fått fram en prototyp får man antagligen revidera rätt mycket av sina idéer. Och sen fortsätter man. Jag menade i mitt första inlägg egentligen inte att man ska göra allt samtidigt, men om lott.
Jag är helt och hållet för ett strukturerat arbetssätt, men "strukturerat" är inte synonymt med "stelt/sjukt trist" :birp
Planering ger (teoretiskt sett) aldrig bättre resultat än användartester. Just webbprojekt brukar väl iofs vara tillräckligt triviala för att det inte ska dyka upp några större överraskningar, men det finns ju undantag. Kolla bara på GMail och deras "labels" i stället för mappstrukturer, ett genidrag, imho. Jag skulle nog gissa att det är ett resultat av rätt många användartester.
I planeringen ingår användarfall och i design planeringen med klassstruktur en prototyp på designen utav gui/sidor ingår användartester.
spango skrev:
Kolla bara på GMail och deras "labels" i stället för mappstrukturer, ett genidrag, imho. Jag skulle nog gissa att det är ett resultat av rätt många användartester.
Jag har ingen aning om vad det är så du får gärna berätta.
spango skrev:
Vad skiljer ett "affärslager" mot en klasstruktur i dina ögon?
Kanske lite vagt beskrivet, men jag syftade på helheten i arkitekturen, och med affärslagret själva programmeringen.
Och jag säger inte att det är rätt eller fel, jag skrev bara att jag personligen brukar göra så. ;) Databasen är i mina system nästan det viktigaste.
Nickemannen skrev:
I planeringen ingår användarfall och i design planeringen med klassstruktur en prototyp på designen utav gui/sidor ingår användartester.
Ja, precis. Och förr eller senare innebär prototyperna kodning, vilket slutar med att man alltså kodar samtidigt som man planerar. Logiskt, va? :) Merparten av koden bör väl iofs slängas innan man sätter systemet i produktion men det är en annan sak. Inga system blir så bra som de man skriver två gånger.
Nej det kanske blir bra genom att skriva två gånger och jag håller med om att man måste "prova" rent programmeringsteknikst vissa saker för att få inblick i komplexiteten. Men man kan inte heller bara sätta sig ner och börja koda... Analys går före kodning vilket inte säger att man kan kombinera dem. Allt beror på storlek på projektet och tid/pengar :)
En prototyp behöver inte betyda att det finns programmerade funktioner.
En prototyp räcker det att man har ett gui som man testar olika personer på. Och eftersom man redan har planerat vilka funktioner som finns och vad som händer var behövs det ju inte finnas några programmerade funktioner. I dessa test så dyker det ju fram att man kanske behöver nya funktioner eller att gamla behöver skrotas eller ändras. Har man då programmerat dessa så har man ju tappat mycket tid.
Självklart så måste man ju sätta sig in i komplexiteten lite när man planerar funktionerna.
/r Som sagt tid är pengar och man hinner inte skriva system 2 gånger om man skall vara med och konkurera.
Jo, jag vet vad du menar. Men min poäng är att kodningen i många fall kan tjäna som analys, eller iaf bidra till analysen. Det är klart att man måste ha en aning om vad man ska göra innan man börjar hacka, men att modellera och teoretisera och tro att man har en perfekt kravspec och att koden bara behöver skrivas är vanskligt.
Kravspecen och designspecen är något som kan ändras under projektets gång ja. Men den ändras oftast/förhoppningsvis inte när implementationen har startats eller under implementationen.
Designspecen ändras ju hela tiden tills prototypen blir bra.
Koden är väl ingen direkt bra analys?
Analysen gör du ju när du interjuvar kunden och frågar vad han vill ha och sedan tar fram kraven på applikationen.
