Hörnstenar för flexibilitet

Vi vill alla ha flexibla system som är lätta att bygga ut och modifiera i framtiden. För att uppnå detta måste vi utveckla system som har egenskaperna hög modularitet, högt sammanhang och låg koppling. Detta är grundprincipen för att ett program eller system skall vara flexibelt.

Med flexibilitet menas att ett system lätt skall kunna modifieras. Om ett system har låg modularitet, lågt sammanhang och hög koppling är det inte flexibelt. Att ändra i en funktion kommer att innebära att ändringar måste göras i andra funktioner som i sin tur innebär att ändringar måste göras osv. Ju mer kod som ändras desto mer sannolikt är det att fel tillförs systemet. Ett flexibelt system består av hög modularitet, högt sammanhang och låg koppling. Om ett system inte är flexibelt är det troligt att man helt enkelt struntar i att göra förändringar i koden. Framtida idéer om förändringar kan gå förlorade.

Hög modularitet

När ett program designas eller kodas skall programmet delas in i ett antal mindre moduler. Om ett program innehåller många moduler säger man att det har hög modularitet. IBM rekommenderar en modulstorlek på mindre än 50 rader kod. En direkt fördel med att begränsa antalet rader är att koden ryms på ett enda A4-ark och ryms på bildskärmen. En annan fördel är relaterad till människans minne. När kod läses skall läsaren lätt kunna plocka ut de viktigaste bitarna ur koden och lägga dem till korttidsminnet.

Högt sammanhang

Varje modul bör designas så att den innehåller en central idé eller ett syfte. Komponenterna som bygger upp denna modul skall endast utföra handlingar som är relevant för att uppfylla modulens syfte. Detta koncept kallas för sammanhang. Det är önskvärt att ha ett högt sammanhang. Idealet är att varje modul i ett system uträttar en, och endast en, definierad funktion inom systemet.

Det finns vissa tumregler för att upptäcka om en funktion/modul har ett högt sammanhang. En regel är att försöka beskriva med en mening vad funktionens uppgift är. Om meningen är enkel och innehåller ett substantiv och ett verb har funktionen ett högt sammanhang. Meningen ”beräkna checksumman och uppdatera PDUn” har lägre sammanhang än meningen ”beräkna checksumman”.

Låg koppling

Koppling är ett mått på växelverkan mellan funktioner eller moduler. Det är önskvärt att ett system har så låg koppling som möjligt. Anledningen är att hög koppling kommer att bidra till att det skapas många vägar som gör det möjligt för ett fel att ”vandra” genom systemet. Om en modul har låg koppling finns det mindre risk att ett fel i en modul sprids vidare till övriga moduler.

Låg koppling kan åstadkommas på många olika sätt, bl a genom att inte låta många variabler skickas mellan funktioner och genom att undvika användning av globala variabler.

Tumregler

Kod skall skrivas så att den blir enkel och läsbar. Enkel kod är motsatsen till komplex kod. Om det tar lång tid att sätta sig in i källkoden, om den är svår att testa eller om det är svårt att modifiera koden, då är koden komplex. Läsbarheten refererar till hur lätt det är att läsa källkoden.

Designerns mål skall vara att designa ett system som har modularitet, högt sammanhang och låg koppling. För att nå dessa mål kan följande enkla tumregler följas:

  1. Kortare är enklare
  2. Färre beslut är enklare
  3. Nästlad logik bör undvikas

Tumregel 1: Kortare är enklare

Ju mindre kod att läsa desto mindre komplex är koden. Det finns studier gjorda för att ta fram faktorer som relaterar till komplexiteten i mjukvaran. Faktorerna är till exempel antalet operatorer och operander i en modul, antalet beslut, loopar mm.
Den mest kraftfulla faktorn att mäta komplexitet är att undersöka hur lång koden är (antalet rader). Ju längre kod ju mer komplex är också koden.

Generellt gäller tumregeln att kortare är enklare, men det finns undantag: om läsbarheten blir sämre på grund av att koden är för kort gäller inte tumregeln.

Tumregel 2: Färre beslut är enklare

Ju fler beslut som en funktion eller modul innehåller desto mer komplex är den. Varje beslut resulterar i minst två olika vägar som kan tas under exekveringen. I bilden nedan visas tre av alla möjliga beslut som ett program kan innehålla. Om det finns många vägar genom programmet ökar risken för fel.

Tumregel 3: Nästlad logik bör undvikas

Allt för mycket nästling i koden är ett tecken på att programmet är komplext. Även om programmeraren använder sig av indragningar i koden så kan det vara mycket svårt att sortera ut de olika nivåerna av if…else:ar. Som riktlinje brukar anges att modulkonstruktioner inte bör nästlas mer än tre eller fyra nivåer djup. Ibland är det möjligt att använda en serie av if-else:ar istället för att nästla dem. if-satser bör ha maximalt nästlingsdjup 3 och maximal längd 7.

 

Scroll to top