Hur gör företag och andra personer när dom ska skriva program, stora projekt eller vill ha kontroll över programmen?

Någon som sitter med tips, trix, guider, artiklar, funderingar, ideer, standarder eller annat gött som skulle kunna hjälpa, så vore det fint att få se höra dom :)

Vet att att många företag(alla) har standarder för hur koden ska skrivas och komenteras, men hur går det till när proffsen planerar projekten?

Sitter själv med ett program jag ska skriva, men efter två försök som just har krashat på att det blivit för jobbigt att ha koll på vad som händer när man ändrar eller lägger till något.

Vet att det finns sevdokod och flödesschemor att göra för att hjälpa till. Vad ska man tänka på när man gör dom?

Alla tankar motages :) // R-mus

Ps. Ni behöver absolut inte vara profitionella programmerar för att ha tips om hur man lättast gör planeringar .Ds

Subrutin och åter igen subrutiner.
Så fort ett stort jobb ska göras mer än en gång använd subrutiner.
Lätta att ändra lägga till osv.
/Martinsson

Har inte programmerat speciellt mycket för varken fristående applikationer eller för saker som inte skall användas internt, så jag har väl kanske inte den största erfarenheten.

Min uppfattning är ändå att det första är en idé, som formuleras till ett problem. ("Vi får in massa felaktiga data... vi måste stoppa datat som är konstigt, vi får bygga nån sorts filter").

Sen beror det helt på situationen; är det tidspress, är det en engångsföreteelse, skall det användas utomlands?

Är förutsättningarna optimala så gör man kravspecifikation, ger alla inblandade en chans att kolla om den är bra, väljer den. Sen programmerar man enligt den modell som företaget har. För projekt som är någorlunda stora är modularitet nästan ett krav, för projekt som är större ändå är det objektorientering som gäller,

Hej

Är lite osäker på vad du menar när du säger du vill ha kontroll över programmen. Men med tanke på ditt inlägg så låter det som om det uppstått problem då du lägger till nya funktioner i ditt program. Jag har precis börjat använda mig av tester (nunit) och det är väldigt trevligt att använda och jag fundera på hur jag klarat mig utan dem innan. När du jobbar med nunit (finns till massa andra miljöer också) så skriver du ett test, eller flera, för en modul eller en klass i ditt projekt. Testet kontrollerar så att vissa saker stämmer i din modul, klass. Är allting korrekt så får testet ok, annars så står det att det inte är ok. Under tiden som du bygger din applikation så skriver du nya tester och till slut har du en hel massa tester som kontrollerar så allting fungerar som det är tänkt. Det fina med detta är att när du sedan vill ändra, lägga till eller ta bort en modul, klass eller funktion så kör du först dina tester för att se att allting fungerar som det gjorde innan. Sen skriver du ett par nya tester för de sakerna som du skall ändra och sen börjar du ändra i koden. När allting är klart så kan du lätt kontrollera, genom att köra alla tester, om något har förstörts.

Att använda tester har kanske inte så mycket med planeringen att göra utan det kanske mer är inriktat på själva utvecklingen av programmet. För planering av ett projekt så tycker jag att usecases, användarfall, är väldigt smidiga. Usecasen kan vara hur enkla eller hur komplicerade som man vill, men de bör beskriva hur användaren använder sig av systemet eller hur systemet pratar med ett annat system. Det finns massvis skrivet om usecase, om att de skall innehålla dit och datt, men mitt tips är att läsa allt som du hittar om dem och anpassa dem så att de passar dina behov. Det viktigaste med dessa är att du får ner vad systemet skall göra, och utifrån dessa så kan du skapa olika moduler. Varje modul kan sedan, om du vill, lösa ett visst usecase eller ha en mer komplex uppgift, såsom användarhantering. (Sök på usecase controller). När du sedan har dina usecase kan du utifrån dessa göra en grov uppskattning av projektets komplexitet och hur mycket tid som du kommer att behöva. Du kan då göra en grov tidsplanering.

Hur du sedan vill planera det andra arbetet beror mycket på vad du jobbar med för verktyg och vem du jobbar mot. Jobbar du i ett objektorienterat språk så tycker jag att en bra start är att skapa en liten kladd om hur klasstrukturen skall se ut och var de olika metoderna skall finnas, och sen börja med det ett usecase och sedan jobba sig ner. Allt eftersom som du märker att saker och ting blir för komplicerat för en klass så får du arbeta om den tills du når det resultat som du tycker är bra, kanske får du omarbeta dina usecase, divide and conquer. Men detta är svårt, tycker jag och det är nog bara erfarenhet som gäller för detta.

En bok som jag lärde/lär mig mycket av är Agile Software Development av Robert Martin, andra böcker som jag tycker är bra är tex Applying UML and Patterns, Larman

Jag vet inte om detta svarade på din fråga eller hjälpte dig med något.. Men det hade varit skoj med en liten diskussion om detta område…

/w

Lite intressanta länkar
http://www.agiledata.org/
http://www.xprogramming.com/xpmag/acsUsingNUnit.htm
http://www.agiledata.org/essays/tdd.html
http://www.nunit.org/