Hei freaks.

Jeg har lagt merke til etterhvert som utviklings oppdragene jeg påtar meg har begynt å bli større å større, så har også det å holde kontroll på all koden blitt vanskeligere. Jeg har pønsket en del på hvordan jeg skal løse dette problemet på en fornuftig måte, har prøvd å tegne flowchart over virkemåten til forskjellige funksjoner o.l. Men dette tar jo veldig mye lengere tid og gir ikkje noe bedre oversikt. Jeg har også prøvd å lage lister med funksjonsprototyper etterhvert som jeg utvikler dem, dette gir delvis bedre oversikt, men jeg bruker fortsatt en del tid på å finne ut hva jeg har gjort, ikkje gjort og hvordan jeg har gjort det.

Grunnen til at jeg lager denne tråden er fordi jeg har blitt spurt for noen måneder siden om å utvikle en programvare for et stort norsk selskap, jeg lovte jeg skulle gjøre det men måtte fullføre prosjektet jeg holdt på med. Nå er tiden kommer og fra å med mandag kommer jeg til å utvikle for dette selskapet og trenger noen gode råd rundt planleggingen. Jeg har tenkt å bruke mye tid på planleggingen, slik at jeg slipper å havne i situasjoner der jeg må sitte å leite igjennom titusenvis av linjer med kode for å finne ut hvordan jeg hadde tenkt det.

Noe av grunnen til denne manglende planleggingen er at jeg jobber som oftest alene, og ser for meg virkemåten i hodet, og begynner å kodeskrivingen nesten med engang. Men nå begynner kildekodene å bli såpass store at det er problematisk å huske hvordan man først tenkte seg det.

Selvsagt så forventer jeg ikkje at alle freakene skal kunne svare på dette spørsmålet, men håper de freakene som har erfaring innen større programmerings prosjekter har noen gode råd å komme med, eventuelt noe lesestoff på forskjellige planleggings teknikker som jeg kan lese løpet av helgen.

Takker for alle råd.

Gode søkeord kan være "software architecture". Skulle ønske jeg hadde noen gode bøker å anbefale, men ingen av dem jeg har er jeg spesielt godt fornøyd med.

En god funksjonsbeskrivelse er jo viktig å ha.
Har du den og følger den slavisk, så vil du alltid ha kontroll på hvilken funksjon de forskjellige delene skal ha.

Så, en funksjonsbeskrivelse med avsjekkingsruter kan kanskje være løsningen?

Bruk git og host koden enten på en privat repo, eller på en egen server med f.eks gitlab. Da kan du holde øye med koden og f.eks bruke git blame om du lurer på "I hvilken sammenheng gjorde jeg denne forandringen?".

Utover det tror jeg du må nesten holde et fokus med å dokumentere for mye enn for lite, evt samle opp ark eller notater med hvordan du har planlagt alt.

Jeg har ikke tenkt å gjøre noe annet enn å anbefale deg en bok. Det kommer til å være den viktigst boken du noensinne har skaffet deg:

http://www.amazon.com/The-Pragmatic-.../dp/020161622X

Man kommer langt med å lære seg de mer avanserte formene for objektorientering, vanlige design patterns, dependency injection osv. Det er utrolig hvor store og komplekse prosjekter man kan lage uten, men det blir veldig mye lettere med.

For bachelor oppgaven min har jeg så langt brukt en slags blanding av XP og FDD. Jeg har vært ekstremt nøye på å skrive unit tests, og prøvd å gjort det så skikkelig som mulig. Fra XP har jeg tatt user stories og acceptance tests veldig nytting, de har har hjulpet meg veldig med å visualisere hva som skal gjøres, hva som er gjort, hva som funker, og hvor lang tid det vil ta for meg å bli ferdig. Ta en titt på CRC kort, de har jeg skrevet på post it notes som jeg har hengt på veggen, fordelen over UML er at de er rask og enkel å lage, i tillegg er det lett å flytte de rundt. Martin Fowler har en rekke artikler om, alt dette. Et godt sted å starte kan være denne.

UML er så mangt. Dvs. det kan brukes til så mangt. Til å tegne ulike typer diagrammer. Å bruke verktøy til å generere statiske relasjonsdiagrammer over hvilke klasser du har i systemet, og hvilke avhengigheter du har mellom dem, er greit nok. Det kan du for eksempel gjøre for C#-prosjekter i Visual Studio (kjenner ikke verktøy for C/C++/PHP, men de finnes sikkert).

De diagrammene som har størst verdi er likevel ikke disse. Diagrammene som kan være lurt å tegne opp er de som viser flyten i de mest komplekse delene av systemet ditt. Flytdiagrammer og samhandlingsdiagrammer. Og disse må du nok satse på å gjøre og vedlikeholde manuelt.

Husk på at diagrammene ikke er et mål i seg selv. Det er den eksekverbare koden som er mest verdifull, og som forteller den absolutte sannheten om systemet. Diagrammer kan visualisere, dokumentere og kommunisere hva du lager, og hjelpe deg å tenke og vurdere om noe er riktig (før du implementerer). Men ofte er et ad-hoc diagram tegnet der og da det du trenger - et diagram som du kaster like etterpå når det har gjort nytten sin. Å holde dokumentasjon oppdatert er en kostnad. Men det er ofte verdt det når man dokumenterer "kjernen" i systemet - elementer som er viktige å forstå godt, og som endrer seg lite over tid.

Tja, jeg tror forøvrig du blander sammen dokumentasjon og dokumentasjon.

Når du snakker om klassediagram og automatisk generering av dokumentasjon snakker du om å beskrive hvordan koden virker. Det er selvfølgelig nyttig, fordi å lese kode tar tid, og kan dermed være verdt hvis man har satt det opp så det genereres uten spesielt mye arbeid. Med riktig verktøy kan dette tilogmed være pent (se javadoc). Primært er dette derimot et verktøy for bli kjent med kode, eller kunne jobbe opp mot annen kode.

Du kjenner derimot koden din i utgangspunktet (håper jeg), og er dermed i posisjon til å skrive gode diagram på et høyere abstraksjonsnivå. Dette vil avhengig av prosjektet du holder på med kunne beskrive arbeidsflyten til en typisk bruker, hvordan forskjellige deler av kodebasen din interagerer med hverandre, hvordan inndata prossesseres eller hvilken informasjon som hentes inn fra hvilke sensorer. Disse bør typisk beskrive grunnprosessene i programmet ditt, og skal hjelpe deg å holde styr på hvordan programmet som helhet fungerer. Disse skal også sørge for at eventuelle nye deler du lager passer riktig inn i hvordan du allerede har bestemt deg for at hovedlinjene skal være.

Disse skal i stor grad reflektere beslutninger som du gjør tidlig i prossessen og holder deg til, så de skal ha lang holdbarhetsdato. Om de ikke har det gjør du noe feil (eller eventuelt har en ubrukelig kunde).

Jeg er enig i det DumDiDum sier, men må legge til at du må forvente å gjøre feil på dette området. Man må gjette på hvilke deler som vil være stabile i et system, men uventede endringer kommer alltid. Så ikke bli lei deg når du har gjort en antagelse som viste seg å ikke være riktig - bare forsøk å lære av det til neste gang.

Jeg føler at jo mer jeg jobber med prosjekter jo bedre rutiner får jeg. Det tar ofte litt lenger tid å skulle dokumentere funksjoner, hvordan ting henger sammen, og hva som skal gjøres til en hver tid.
Anbefaler å bryte ned prosjektet i mindre deler, og heller ha "sub-prosjekter".

Dette tar som sagt litt ekstra tid, men det er ofte anbefalt i lengden