Hur planerar och strukturerar ni ett större program?

[qx5]

Och du vet att behovet aldrig föreligger i framtiden?

[TomasL]

Ja

[Magnus_K]

Hade aldrig hört talas om enumerering innan med det ser verkligen stiligt ut. Det förstår jag att man vill använda sig av. Tack för det tipset.

Jag tänkte precis som qx5 angående den svenska kommenteringen men förstår er nu varför ni valt detta.

[TomasL]

Ja enumreringar är en bra sak, faktiskt.
Beträffande språk i kommentarer.
Tja, det är väl fullständigt valfritt.
För vår del, så lämnar aldrig källkoden "huset", typ.
Sannolikheten till att vi skulle börja använda oss av programmerare utanför "huset" är helt obefintlig. Följaktligen så behöver vi inte kommentera på engelska, då inga andra än anställda (och svenskatalande (därmed inte sagt att de behöver vara svenskar)) får se eller arbeta med koden.

Dock har jag konstaterat att doxygen i vissa lägen kan ha lite problem med andra språk Svenska, av någon anledning.

[sodjan]

Och med "andra språk" menar du, vadå?
Andra språk än svenska?

[TomasL]

Nä, Svenska, lite otydligt där, sorry.
Får editera det.

[qx5]

Sedan har ju svenska tecken en benägenhet att dra in 8-bit ascii, olika inkompatibla teckentabeller, eller utf med sekvenser som inte alla program hanterar rätt.

[TomasL]

Jo, det är förvisso så. dock hanterar våra editorer inte UTF, så det handlar bara om CP, vilket inte gillas av doxygen i vissa lägen, tyvärr.
Dock, det finns säkert en lösning, när tid infinner sig.

[MiaM]

En grej som i vissa fall kan kräva rätt mycket eftertanke är hur data lagras i programmet.

I vissa fall är det helt självklart, t.ex. ett program som styr hårdvara i form av någon state machine eller liknande, och som hanterar rätt begränsade mängder data.

Om man däremot t.ex. ska skriva en hel mailklient som exempel så behöver man besluta var/hur man lagrar själva mailens text, var man lagrar metadata (headrar), och i vilket format olika delar lagras. (I mailprogrammet vill man kanske ha viktiga headrar till varje mail lagrade separat på ett sätt som gör att det går snabbare att få upp lista över samtliga mail (eller samtliga i en mapp) o.s.v.

[ElectricNooB]

Lite nyfiken, vad räknas som ett större program (rader kod) för er? Jag antar att det beror lite på språket? Skulle även vara kul att se lite exempel på hur ni delar in i klasser metoder/funktioner!

[Magnus_K]

@MiaM: Helt klart relevanta punkter. Till detta borde också säkerhetsfunktioner m.m. komma.

@ElectricNooB: Det är jag också mycket nyfiken på!

[TomasL]

Indelningen i funktioner och moduler blir rätt naturlig, efter funktion.
Till exempel, låt os säga att du skall ha en Display och en serieport, då lägger man i regel allt som hanterar serieporten i en modul och allt som gäller displayen i en modul, modul är naturligtvis samma som c-filer.
Vidare delar du upp modulen i olika funktioner, till exempel: en funktion som initierar sereiporten, en funktion som skickar och en funktion som tar emot.
Däröver har man troligen en modul med hjälpfunktioner, till exempelvis CRC-beräkningar osv.

Vad ett stort program är, vet jag inte, vårt projekt ligger på någon halvmiljon rader, typ, kompilerat blir det kanske 150kWord, typ.

[kodar-holger]

Mycket klokskap har redan skrivits i den här tråden av Sodjan, Seniorlemuren med flera men tänkt fylla på med mina tankar.

Kravspec som skrevs i början av tråden är mycket viktigt. Om man inte vet vad programvara skall göra funkar det inte. Problemet är att oftast vet inte ens kunden vad programvaran skall göra! Ur denna vetskap har många metodiker RUP, Scrum med flera kommit. Men egentligen är det sunt förnuft. Man gör saker i mindre inkrement. Börjar med lite och bygger på i nära samarbete med kunden. Då är det inte så tungt att kasta bort något som visade sig fel som om man jobbat i tre år och måste börja om.

Utöver att kraven är viktiga för utvecklingen i sig är dom en förutsättning för verifiering. Alltså att i slutänden (på ett inkrement) visa att det blivit rätt.

Kravspecar kan bli väldigt stora, men dom är nästan alltid för små. Den programvara jag just nu underhåller hade när den skapades en formell kravspec på ca 100 sidor. Men till detta kom också ett koncept som förklarade hur det skulle användas på ytterligare ca 1000 sidor. Och dessa visade sig allt för klena, felaktiga och ibland motsägelsefulla. (Behöver jag säga att vi drog över budget med >>100%, men projektet överlevde)

Vad gäller nedbrytning så är jag numera starkt influerad av en metodik som heter schlaer-mellor. Fast det är egentligen också bara sunt förnuft.

Man börjar med att hitta större avgränsade "subject matters". Det är hyfsat viktigt att dessa är åtskilda. Exempel: flygtrafikledning. Du blandar inte in koncept som processorpinnar i koden som hanterar prioritering av landningar. Eller ens processorpinnar i protokollhantering mot andra system.

När man gjort sin grova design av systemet eller arkitektur som det ibland kallas, och som det finns för många definitioner av, får man oftast bryta ner kraven också. D.v.s. skriva nya krav på sina delar baserat på systemkrav. Om Kravet är viss reaktionstid på ett reglersystem kommer det att ställa nya krav på både hård och mjukvara. Glöm inte spåra!!!

UML och i synnerhet profilen xtUML har gett mig bättre struktur på saker. Så inom ett subject matter får man sen föröka få fram en klassmodell för hur saker hänger ihop. Detta är inte alltid så enkelt för en simpel programmerare utan vi får ta hjälp av domänexperter. Vem kan bättre förstå förhållandet mellan inflygningsrutter, landningsbanor, flighter och vad det nu är än en flygledare? xtUML har till skillnad från UML fördelen av att vara ett mycket begränsat subset vilket förhållandevis enkelt kan läras ut så att man får ett gemensamt språk.

Och när du väl byggt en klassmodell har man ju ytterligare en nedbrytning....

Vad gäller verktyg så är dessa ofta till hjälp, men ibland till mera stjälp. Min erfarenhet är att såna som introduceras av ett behov blir till hjälp, medan såna som kommer in för att någon bestämt att vi måste ha detta sällan blir det. Undantag finns dock åt båda håll.

Kravhanteringsverktyg brukar dyka upp i större projekt. Kan hjälpa med att hålla kravspårningen rätt vilket i många större projekt är viktigt. Beroende på vart programvaran skall användas brukar kunder vara olika kinkiga med detta. Det finns en standard som heter RTCA-DO178 som används flitigt inom både flyg, som den kommer från, och på andra ställen. På dom mest kritiskak nivåerna där finns krav på kravspårning till kodradsnivå! Du måste alltså kunna härleda varje programrad till ett krav på systemnivå. Lyckligtvis har jag sluppit detta än så länge.

Editorer är idag ganska bra. Redan LSEdit när jag började min professionella kodar-resa för 25 år sen var helt ok, men dagens IDEer med visual studio i spetsen springer cirklar runt den. Att kunna snabbt navigera till vart en variabel deklarerades, hitta referenser från flera filer et.c. är funktioner som är guld värda. I synnerhet i dåligt kommenterad programvara.

Kommentarer är väl det jag kommer att gagga om på hemmet när det är dags. Man kan (nästan) aldrig skriva för mycket kommentarer i kod. Och kommentarerna skall beskriva varför man gör saker, inte vad man gör. För det säger koden i sig.
A:=3; //Tilldela variabeln a siffran tre. Vad bra, det kunde jag ju inte se.
Jag har en programvara på knappt 500k rader som jag underhåller. (Bara gui-delen, en mycket större backend finns också.) Det finns delar där som jag inte rör trots att där finns felrapporter. Inte stort bara komplext, kanske ett par tusen rader, Men jag har inte lyckats tränga mig in i hur det fungerar trots variabel och funktionsnamn som säkert var helt uppenbara för den som gjorde koden. I historiken kan jag se att man löst tidigare problem genom att byta plats på rader men sen inte skrivit något om varför. Suck jag blir så trött.

Ibland blir det så att man upprepar kod som är nästan lika om och om igen. Då känns kommentering extra jobbig, och det blir lätt att man kopierar och ändra i koden men inte kommentererna. Räkna kommentarerna som en del av koden trots att inte kompilatorn tittar på den!

UML-verktyg finns hur många som helst. Vill man satsa på xtUML är alternativen få. Bridgepoint är gratis att ladda ner men saknar då kodgenereringsdelen som är dess verkliga styrka.

Ett verktyg få har nämnt är versionshanteringsverktyg. Under en intensiv utvecklingsfas kan dom kännas jobbiga men är guld värda i underhållsfas. Det går förmodligen inte en dag utan att jag går tillbaka i gamla versioner av källkod för att se när något infördes och tillsammans med vad. Är man flera i ett projekt är dom helt nödvändiga. Några namn ur minnet. Git, subversion, cvs. Fast vi använder något helt annat på jobbet som inte längre går att köpa. Och grejen är den att när man väl valt är det väldigt svårt att byta. Ingen leverantör är så intresserad av att förenkla flytt till någon annan, och grejen är ju att du vill ju faktiskt ha kvar historiken och kunna se vad som hände 45 versioner tidigare i den här filen.

Testning är också något viktigt. Framförallt visar det sig snart att regressionstestning är bra. Testa sin nyutvecklade funktion kan man ju göra för hand tills man ser att den uppfyller kraven, men om tre år är du inte intresserad av att testa allt om och om igen bara för att du ändrat lite här borta och det skall ju inte påverka något.... Så verktyg för regressionstest är nästan nödvändiga. Visst, testsviten blir ytterligare en börda att underhålla men jämfört med att handtesta... Squish använder vi.

Nu på slutet dök frågan upp vad en stor programvara är. Känns lite flytande men jag gissar på följande:
- När man inte längre av praktiska skäl kan hantera den ensam. T.ex. p.g.a. krav på utvecklingstid eller ren komplexitet.

Något specifikt antal kodrader lär inte gå att säga eftersom det beror på vem som gör den. Däremot är det nog ungefär lika oberoende av språk. 1000 rader assembler åstadkommer inte lika mycket som 1000 rader Ada, men är ungefär lika komplext att förstå.

När man blir flera i ett projekt tillkommer för övrigt ny komplexitet vilket gör att programvaruprojekt skalar väldigt dåligt med antal programmerare. En ökning från en till två kan göra att man blir mer än dubbelt så effektiv. Man har någon att diskutera med och man peppar varandra samtidigt som interfacehantering inte blir så svår.Men man kommer någonstans till en nivå där fler personer leder till minskad produktivitet. Been there, done that....

Ingen har sagt något om hur man tar betalt heller. Köpare vill ha fast pris. Går du till konsum vill du veta vad kotletterna kostar, inte att slaktaren tar 450 kronor i timmen. Jag ser fastpris på programvaruutvecling som ett riktigt kamikazeprojekt.

Kravarbete är helt omöjligt. För det första är det kundens ansvar men du som skall lida av dom sen. Måste göras på bok och räkning och i samarbete.

Programmering mot tydlig kravspec kan möjligen tidsuppskattas men som tidigare sagt, förmodligen vet inte kunde vad han vill ha. Så man hittar funktioner som är viktiga just nu, tidsuppskattar och ger fastpris på dessa. Kunden väljer och man gör ett jobb på kanske en månad. Inte mer.

Sen måste kunden avsätta tid och pengar för att se att det man fått motsvarar förväntningarna, och naturligtvis kraven. Är förväntningarna fel får kunden betala, uppfyller man inte kraven får man som programmerare leva på hullet en stund.

Det var nog vad jag hade på hjärtat just nu.

P.S
Liknelsen med noterna och orkestern haltar lite. Ingen vill lyssna på en orkester som spelar exakt som det står i noterna. Tack och lov för då hade vi väl bara en massa pling och plong och maskiner som spelade. Man kanske skulle kalla sån musik för techno...
D.S.

[ElectricNooB]

Tack för svaren till er båda! Mycket bra inlägg!

[Krille Krokodil]

xmUML ser intressant ut, vad kostar en licens för att kunna kompilera?

Har suttit och gjort det omvända i veckan, ritat flödesdiagram på kod jag skrivit, tillslut blev
det för komplicerat och rörigt så jag fick backa och strukturera upp det hela grafiskt.