Övriga svårigheter

Egenskap för att hålla nyhetsparametern:

Nyhetsparameter.

Skapa ny model och använd Funktion Nyhet (Nyhetsparameter) Anropa index.php i Nyhet mappen.

} }

8.5.4 Övriga svårigheter

Fulhaxx-kommentarer

I flera filer fanns kod med kommentarer som började med Fulhaxx. Dessa kommentarer ger en indikation på att utvecklaren som skrev koden var införstådd med att lösningen inte är optimal. Under analysfasen identifieras sådana kommentarer och den kodsnutt som

kommenteras. För varje sådan kommentar behöver utvecklaren analysera kodsnutten och se hur samma funktionalitet kan bibehållas men med en optimerad lösning.

Mainmodellen

I figur 6 ses de sektioner som finns i main.php. De sektioner som finns i main.php är Sektioner, Toppnyhet, Nyheter_fulltext, Nyhetslista, Covers, Artiklar/Covers, Artiklar,

40

Resultat och Blogg. Den övergripande strukturen för sektionerna innebär att varje sektion har sin egen logik för att ta fram data och presentera denna. Filen main.php har en

databaskoppling genom att den är inkluderad i index.php som har en koppling mot databasen.

Sektionerna använder databaskopplingen för att göra MySQL-förfrågningar. Sektionerna i main.php använder sig inte av befintliga klasser eller funktioner.

Systemet bygger på över 200 filer. Varje fil innehåller sektioner. Varje sektion har både datalogik samt presentationslogik. Det skiljer sig från MVC som har dessa delar separerade.

Om systemet hade varit skrivet med klass-struktur så hade det underlättat analysprocessen och strukturen hade varit närmare MVC. Strukturen bygger på att olika filer inkluderas för olika delar av webbplatsen. Filerna delar inte gemensamma funktioner eller klasser. Det visar sig bland annat genom duplicerad kod. En nackdel i analysfasen är om utvecklaren behöver analysera samtliga filer för att identifiera vilka typer av objekt som används av systemet.

Denna analys utförs av utvecklaren och modelleras för att användas när systemet konverteras till MVC-arkitektur.

Figur 11. Den logik och presentation för sektioner som finns i main.php.

Main.php är bara en fil av hundratals filer i uppdragsgivarens system. Main.php valdes och det är den fil som laddas in när en besökare surfar till www.Fragbite.se. Presentationsmässigt motsvarar main.php en stor del av siten vilket ses i figur 4. I filen finns logik och presentation av nio olika sektioner. En av dessa sektioner är Nyhetlista (se fig 4). Varje gång en besökare klickar på en länk annan än Framsida så inkluderar index.php en annan fil på samma plats som main.php laddades in i. Exempelvis när en användare besöker

www.Fragbite.se/?userID=21031 så inkluderar index.php en fil som heter user.php som hämtar användarspecifika data från MySQL-databasen och sedan presenterar det med hjälp

41

utav HTML, CSS samt PHP. User.php är ansvarig för det som presenteras på sidan och den bakomliggande logiken. Varken klasser eller funktioner används för att hämta och presentera data. Databaskopplingen sker i en separat fil och återanvänds i andra filer i systemet. Det gör att samma sysslor i systemet utförs flera gånger men i olika filer. Det betyder att det finns duplicerad kod som Martin Fowler (Fowler 2000) kallar för stinkande kod. Ett exempel på duplicerad kod är det som beskrivs i 8.4.3. Över hela sidan och olika filer hämtas bilder tillhörande bland annat artiklar, nyheter och covers. Ett exempel på lösning för det problemet i pseudokod:

Den ovanstående koden beskriver en funktion som ligger i en egen klass. När denna lösning används skriver utvecklaren en kod som använder den ovanstående koden utan att upprepa dess innehåll vilket är tvärtemot vad duplicerad kod innebär. Exempel på hur utvecklaren i php-kod kan använda det ovanstående kodexemplet:

<?php

hämtaBild($nyhetsbild);

?>

där det i nuvarande systemet ser ut i pseudokod:

42

(nyhets-block med bild och text) om finns(parameter är GIF)

(artikel-block med bild och text) om finns(parameter är GIF)

En korrigering av kodraden skriv(GIFFEL) behövs men måste på grund av den strukturen som koden har ändras två gånger enligt ovanstående kodexempel. När ett system innehåller över 200 filer där mängden duplicerad kod är långt större än ovanstående exempel så blir

43

processen krävande då alla filer måste analyseras för att finna alla förekomster av duplicerad kod. Med all duplicerad kod identifierad kan utvecklaren börja skriva lämplig kod för att bibehålla samma funktionalitet. Ur ett vidareutvecklingsperspektiv så är det bättre eftersom att eventuella förändringar av funktionens beteende endast behöver ske på ett ställe. Enligt exemplet ovan så finns koden för att hämta rätt bild på flera ställen än ett. På en webbplats som Fragbite behöver bilder hämtas till ett antal olika ställen och filer. Det betyder att det blir många upprepningar av kod när man endast ser till bildhanteringen. Bildhanteringen är en liten del funktionsmässigt i systemet. Denna problematik kring duplicerad kod gäller alla kodsnuttar som behandlar data på något sätt.

I det stora systemsammanhanget är sektionerna och main.php en liten beståndsdel. Det är en av över 200 filer som finns i en av de 20 mappar som upptäcktes under analysfasen. Med samma förekomst av stinkande kod i samtliga filer så innebär det att analysfasen blir jobbig för utvecklaren. Det eftersom att det blir mer komplicerat när det är fler aspekter av koden som behövs has åtanke under analysen.

Re-engineeringprocessens helhet

Som Chikofsky & Cross (1990) beskriver re-engineering så innebär det ” undersökning och förändring av ett system för att rekonstruera det i en ny form”. Undersökning/analysfasen av re-engineering är en av tre stora faser i hela processen. Denna fas motsvarar de fyra första stegen av de elva steg som re-engineeringprocessen består av enligt Briden (2000). Dessa steg måste utföras för att att kunna gå vidare till den fas där kod förändras och systemet

rekonstrueras. Om det som i Fragbites fall finns kod som inte använder klasser eller objekt så kommer klassmodeller att saknas direkt utifrån den kod som finns. Det betyder att det saknas motsvarande delar för att direkt kunna använda modeller som sedan kan användas för att strukturera om till MVC.

Att tänka på vid re-engineering mot MVC-arkitektur

Hela processen blir mer omständlig när antalet filer ökar och där filerna saknar samverkan med andra filer. Det betyder att inga klasser, objekt eller funktioner används. Det vill säga den typ av system och filer som Fragbite.se har.

 Först måste utvecklaren analysera alla filer för att kunna uppskatta det som behövs göras.

 Utvecklaren måste även tänka på att hitta oklarheter i koden som denne behöver rådfråga en insatt person om eller som kommer kräva extra mycket tid.

 Eventuella buggar som hittas i systemet ska antecknas och stämmas av med arbetsgivaren.

 Identifiering av duplicerad kod. Alla förekomster som hittas antecknas. Den duplicerade koden bryts ut till en klass som innehåller metoden för att utföra samma funktionalitet.

 Utvecklaren måste hitta vilken typ av data som behandlas i alla olika filer för att kunna dela upp dessa i olika objekt beroende på vilken data det är. Dessa objekt säger sedan vilka models som kommer behövas i MVC-strukturen.

44

 Genom att analysera alla filer och hitta de olika presentationerna av olika objekt kan utvecklaren se vilka views som behövs och därmed tillhörande controllers.

 De krav som ställs på re-engineeringprocessen är väldigt viktiga att ha i åtanke när utvecklaren ska skriva om koden.

 I bakhuvudet måste utvecklaren vara medveten om hur den önskade MVC-arkitekturen ska se ut när re-engineeringprocessen är färdig och systemet ska dokumenteras.

På grund av att det kan finnas mycket duplicerad kod så är det viktigt att utvecklaren

identifierar all duplicerad kod som finns i hela systemet. Modellerna kan innehålla duplicerad kod som delas med många andra filer i ett stort system och därför bör utvecklaren anteckna var denne kommer behöva ersätta den duplicerade koden med en ny lösning.