Når du starter et nytt prosjekt, hvordan har du tenkt til det, eller hvor lang tid tar det?
Pseudo? Flytskjemaer?
Forsøker du å tenke på alle klassene på forhånd?
TBH, jeg har tenkt aldri noe. Jeg får rett til det og tenke på løsninger som problemer oppstår. Mest fordi de få gangene jeg prøvde planlegger på forhånd, ville jeg alltid glemmer noe vesentlig, og dermed logikken i planlegging ville være feil.
Mye mindre enn jeg burde
Jeg har alltid dykke i, bli skitten og deretter innse at jeg har gjort et rot. Så gå tilbake og plan, og gjøre det riktig.
men rotete feil fase gir meg gode ideer som jeg ikke ville ha selv for gjennom en formell designprosessen.
Edit I hovedsak får i disse slags knuse tastaturet søl når du spiller med større / komplekse. Interessant å se hvor langt det blir før du innser at 'det er i hodet mitt, så det er ok' design er 100% feil.
Det kommer an på. De fleste tingene jeg skriver er ganske grei og en større konstruksjon blir bygget trinnvis og jeg merke til hva som fortsatt mangler og hva som er allerede fullført. Det var et par mer hårete ting som krevde omfattende skissering og tenkte å få rett, selv om jeg ennå ikke har kom over mange arkitektoniske problemer som krevde det (fortsatt ung og sånt). For det meste de var vanskelige regne ting.
På min internship i fjor, min manager ble positivt overrasket over at jeg brukte flytskjemaer for et problem. Han syntes det var en tapt kunst med studenter i disse dager. Jeg var ikke så positivt overrasket over at de ble betraktet datert.
Uansett, det kommer an på tidslinjen av prosjektet for meg, tidsfrister er det viktigste selvfølgelig.
Sannsynligvis ikke den beste teknikken ... men ... jeg har tenkt i kode .
Jeg ofte oppdage klasse / metoder / etc. at jeg trenger bare ved å gjøre det på denne måten. Med det sagt, jeg alltid anta at min planlegging kode ikke kommer til å bli den endelige løsningen.
I tillegg vil jeg skrive ned notater detaljering "viktige funksjoner" og "minor / ønske funksjoner".
Når du tar på et problem i alle størrelser, jeg har alltid tenkt på å skrive det minst to ganger.
Det hele avhenger av hvor store prosjektet det. Noen ganger kan det ta måneder å bare samle alle kravene og vet nøyaktig hva den trenger å gjøre.
Når det kommer ned til koding del, alt avhengig av hvor komplisert det er. Hvis det er ekstremt komplisert, testamenter jeg starte med å bare trekke ut hva jeg vil den skal gjøre. Da vil jeg skrive ut min pseudo-kode i kommentarer. Da vil jeg kode rundt disse kommentarene.
Men hvis det er enkel koding. Jeg vil vanligvis bare skrive ut hva som er på mitt sinn og teste den.
Vi bruker en svært smidig tilnærming som vi vil jobbe på store deler og selvfølgelig ting er alltid kommer til å dukke opp i kravene. Så vi vil imøtekomme for de som de kommer opp. Du kommer aldri til å fullt ut vite nøyaktig hva du ønsker å lage i begynnelsen av skapelsen syklus.
Det er min mening.
Mesteparten av tiden, jeg i det minste prøve å ha en overordnet diagram (selv bare i hodet mitt) om hvordan modulen / system skal fungere. Jeg liker å vite hva jeg skal gjøre før jeg gjør det. Det gjør programmeringen enklere og raskere (vi er generelt under stramme tidsfrister der jeg jobber). Hver gang jeg ikke, jeg kjører inn i problemer som generelt fører meg til å trekke ut kode og putting er et annet sted. Jeg skal innrømme, min prosess kom gjennom bitter erfaring, og jeg fikk egentlig veldig flinke til å bruke regex i koden sammen med globale finne og erstatte.
Noen andre brakt opp et godt poeng, noen ganger har du et virkelig stort system, og det blir vanskelig. Jeg prøver og bryte det ned i biter. Jeg skal jobbe med noe og få det fleshed ut, og jobbe med noe annet for en liten stund og se hvordan de samhandler. Selv med planlegging fremover, jeg savner ting og må refactor kode, men minst jeg ikke gjøre om alt siden jeg i det minste hadde en slags arbeidsplan.
Det avhenger av hvor kompleks problemet er at du prøver å løse. Hvis du tar på en stor programmering prosjekt, må du ha en viss grad av planlegging før du starter. Hvis du ikke gjør det, vil du få fryktelig vill i detaljer om ting som ikke helt kommunisere med de andre delene på kort tid.
Utgangspunktet, prøv å få et fugleperspektiv av problemene du må løse. Se om noen av problemene er små nok til at du kan løse dem og finne ut hva det trenger å kommunisere med resten av løsningen. Tenk på det som en black-box med en API til omverdenen.
Etter at du har alle blokker funnet ut, se om du trenger å dele problemet inn i mindre sub-problemer, eller at du har en detaljert nok visning av hele prosjektet som du kan starte med koden.
Min erfaring er at planlegging hjelper deg å unngå problemer i fremtiden, må du tenke mer på hvordan koden er ment å vokse i fremtiden hvis du trenger å legge til noe etc.
I de fleste tilfeller vil du spare tid du brukte på planlegging når du feilsøker eller utvide prosjektet. Også ha en grov layout av prosjektet betyr at det vil være lettere å få hjelp til å bygge de svarte-bokser du trenger, slik at du kan arbeide på den med flere mennesker enn bare deg selv.
Avhengig av kompleksiteten i prosjektet, jeg vanligvis starte med pad og papir, og skrive opp en spec, og noen pseudo-koden til kontrollflyt. Da kan jeg alltid se tilbake på at mens jeg koding. Det gjør det enklere og krever mindre refactoring fordi du ikke tror problemet gjennom.
Personlig kommer an på omfanget og kompleksiteten i prosjektet, hvor mange mennesker jeg jobber med på det, og de generelle forventningene om levering.
Det er ganske viktig å forstå de generelle forventningene til partene som skal bruke programvaren. Alle som er involvert i prosjektet skal ha en felles forståelse av hva som blir jobbet på - hvordan det kommuniseres går i mange retninger.
Altfor ofte, involverte parter i programvareutvikling ikke at kommunikasjon mellom partene er ofte den mest kritiske og undervurdert del av prosjektet - og den ledende årsaken til prosjekt uhell.
Etter opplevelsen av mye av uferdige prosjekter , pleier jeg å gjennomføre en forenklet versjon av mine forretningsprosesser i min personlige utviklingsmetodikk.
De vanligvis følger følgende struktur:
Jeg brygge litt kaffe og lage et par sandwicher.
Egentlig det avhenger av prosjektet. Jeg har jobbet med noen prosjekter i forsvarsindustrien som tok 2 år med detaljert planlegging før å skrive en eneste linje med kode, og jeg har satt oss ned og kvernet ut noen små verktøy fra bare noen forespørsler i en e-post fra en 3D eller tekstur artist på en enkelt sittende med en pose av kringler og en kopp Joe.
Å kunne utvikle flytdiagrammer, UML diagrammer, use-case ordbøker, og omfattende koding standarder før hånden er en fin måte å holde ting organisert, og er absolutt verdt å gjøre på større prosjekter, større lag, og virksomhetskritiske prosjekter. Men disse tingene tar tid, og er ofte overkill for mindre prosjekter.
Det eneste du egentlig trenger å sikre at du har tilstrekkelig forståelse av problemet domene. Hvis ikke, tilbringe tid foran for å forske på det før du gjør er alltid verdt tiden.
Da jeg var i "foss" måte å gjøre ting jeg ville skrive flere hundre siders dokumenter som viser alle detaljer som kan bli avdekket under forskning. For å komme til denne massive tome dokumentasjon ville jeg vanligvis
For de siste årene jeg har fulgt med Agile (SCRUM) og har tatt en helt annen tilnærming.
Jeg må si at Agile reduserer mengden av tidsbruk skrive dokumenter som henfaller så snart blekket drys. Produktet eieren får å se resultater i en mye raskere måte. Hvilket betyr at de kommer til å holde prosjektet går i riktig retning over tid - selv om at retningsendringer som vi utvikler.
Husk at det er en tid og et sted for begge måter å utvikle. Jeg ville ikke ønsker å bygge Jet programvare ved hjelp Agile!
Jeg er fortsatt på universitetet, og jeg har ennå ikke har erfaring med å skape storskala programvaresystemer, men ...
Det første som må gjøres er å regne ut hva som er ønsket. Så langt for meg, er dette normalt et oppdrag spesifikasjon, men i den virkelige verden innebærer det å snakke med klienten. Mye.
Da jobber jeg ut hvordan du gjør det som er nødvendig. For de relativt små programmer som jeg har jobbet med, jeg vanligvis form i mitt sinn en viss idé om hva programmet mitt kommer til å se ut som (hva de viktige delene av programmet er og hvordan de samhandler med hverandre). Dette kan innebære pigger hvis jeg har ingen anelse om hvordan en del av programmet vil fungere. Jeg tror ikke denne tilnærmingen (gjøre alt i mitt sinn) vil skalere veldig bra, men spørsmålet var å spørre hva vi faktisk gjør ...
Når jeg vet mer eller mindre hva jeg prøver å gjøre, jeg setter meg ned og skrive koden. Det er her jeg oppdager noen problemer i det jeg tenkte.
Jeg tror ikke jeg har alle brukt pseudokode for å utforme en algoritme. Jeg tror pseudo er for lavt nivå for å designe store biter av programmet.
Jeg har bare brukt en flytdiagram på en anledning til å hjelpe til med å utforme et program - da jeg lærte forsamlingen og var ganske ny i programmering (og det var nyttig). Den mytiske Man-Month sier følgende: ". Den detaljerte blow-by-blow flytskjema, derimot, er en foreldet plage, passer bare for å initiere nybegynnere til algoritmisk tenkning ... Jeg har aldri sett en erfaren programmerer som rutinemessig gjort detaljert flytdiagrammer før du begynner å skrive programmer."
IMO fem minutter av planlegging fremover = en time for koding ....
Så mange ganger vi må gå tilbake og revurdere hele situasjonen, fordi vi ikke planlegge noe.
Den viktigste delen bør være flytskjemaet.
De andre detaljer noen ganger kan bli tatt vare på på sparket.
Jeg tegner omfattende flytskjemaer og skrive pseudokode for de mer kompliserte funksjoner. Jeg føler meg som å tegne flytskjemaet tillater meg å refactor uten å innføre feil ved et uhell. Å gjøre en visuell diagram på papir som et flyt også hjelper meg med å finne ut om min logikk er faktisk riktig. Dette fungerer bare virkelig for små - middels prosjekter der de fleste av spesifikasjonene er kjent.
Med mer erfaring, behovet for å trekke omfattende flytskjemaer og skrive ut hele funksjonen pseudo-kode vil bli mer overflødig men før du kommer til det punktet at jeg sterkt du planlegger før du kode.
