Cygni | 08-459 93 30 | info@cygni.se | cygni.se | stacktrace.se

Om Cygni

Javakonsultbolaget Cygni grundades i mars 2006. Sedan dess har bolaget växt med god lönsamhet och mycket hög kundnöjdhet. Idag är Cygni 25 anställda och sysselsätter även ett antal under-konsulter.

Cygni är specialister på att utveckla avancerade Java- och Java EE-applikationer. Samtliga Cygnis konsulter är utvecklare och/eller systemarkitekter med lång erfarenhet från projekt i en mängd olika branscher och teknik-domäner.

Den genomsnittlige Cygnikonsulten är 35 år och har 12 års professionell erfarenhet av avancerad systemutveckling. De flesta av Cygnis konsulter är civilingenjörer, vanligtvis från D-linjen på KTH. En Cygnikonsult är van att snabbt sätta sig in i kundens verksamhet, oavsett bransch, och därmed möjliggöra en snabb och effektiv systemutveckling i linje med den övergripande kravbilden.

Cygni | 08-459 93 30 | info@cygni.se | cygni.se | stacktrace.se

ByggverktygDet finns en flora av byggverktyg på marknaden varav de flesta av dessa verktyg är open source-alternativ.

Rudimentära verktyg såsom make och egenhackade bat-filer har ersatts av mer sofistikerade verktyg som exempelvis Ant och Maven.

Ett byggverktyg används för att man på ett kontrollerat sätt ska kunna bygga ihop det system eller den produkt man ut-vecklar. Det är viktigt att byggverktyget är deterministiskt det vill säga att resultatet som produceras blir lika varje gång. Dessutom är det viktigt att det finns möjlighet att plugga in olika rapporter och andra features via så kallad plugin-arkitektur.

Omoderna verktyg:

● Make

● Bat-filer / Shell scripts

● IDE

Moderna verktyg:

● Ant

● Maven

● Ivy

● Buckminster

Apache Ant

http://ant.apache.org/

Apache Ant är ett av de vanligaste verk-tygen för automatiserade byggen. Det är likt make men är byggt på Java och kräver således en javaplattform för att kunna köras. Apache Ant passar bäst för att bygga javaprojekt.

En stor skillnad mellan make och Ant är att Ant använder XML för att beskriva byggprocessen medan make använder det gamla Makefile-formatet.

De stora nackdelarna med Ant är att beroenden mellan olika artefakter såsom tredjepartsbibliotek och liknande inte hanteras på något enhetligt sätt samt att Ant-filerna blir långa och svåra att över-blicka.

Maven 2

http://maven.apache.org

Maven 2 är ett verktyg för automatiserade byggen. Maven har stora likheter med Apache Ant men använder sig av en princip som kallas Convention over Configuration som innebär att bygg-skripten blir väldigt korta och över-blickbara. Det finns defaultvärden för vilken katalogstruktur som ska användas och så vidare.

En stor fördel med Maven är dess hantering av beroenden mellan olika arte-fakter. Detta gäller både egna artefakter (egna jar- eller war-filer) eller externa artefakter såsom tredjepartsbibliotek. Externa beroenden tankas hem från Mavens repository vilket innebär att ut-vecklare enkelt kan komma igång med utvecklingen från vilken maskin som helst.

Maven har dessutom ett väldigt bra stöd för rapporter och externa plugins.

Cygni | 08-459 93 30 | info@cygni.se | cygni.se | stacktrace.se

UtvecklingsmiljöEn utvecklingsmiljö är det verktyg som utvecklaren använder mest. Det är därför väldigt viktigt att utvecklingsmiljön fungerar bra och integrerar väl med de övriga verktyg som används inom projektet. Ett annat ord för utvecklings-miljö är IDE – Integrated Development Environment vilket kanske bättre be-skriver vad det hela handlar om.

Utvecklingsmiljön bör åtminstone till-handahålla följande:

● Editor för källkod (Java, JSP, XML, HTML etc)

● Kompilator

● Debugger

● Autocompletion

● Integration med versions-hanteringssystem

● Integration med defekt-hanteringsverktyg (JIRA, Trac, BugZilla etc)

Utöver ovanstående bör utvecklingsmiljön vara baserad på en plugin-arkitektur för att enkelt kunna lägga till nya features från externa tillverkare (exempelvis integration med byggverktyg, profilering, UML-diagram etc).

Eclipse

http://www.eclipse.org

Eclipse är ett open source-verktyg och det absolut vanligaste utvecklingsverktyget på marknaden. Applikationen är plugin-baserad via en teknologi som kallas OSGi vilket leder till att en mängd olika plugins finns att ladda hem för integration med olika verktyg.

Eclipse erbjuder ett bra stöd för re-faktorering av källkod och filer.

IntelliJ IDEA

http://www.jetbrains.com/idea/

IntelliJ IDEA är till skillnad från Eclipse ett kommersiellt utvecklingsverktyg. IntelliJ har gott rykte inom javavärlden och är liksom Eclipse baserat på en plugin- arkitektur. IntelliJ är känt för sitt utmärkta refaktoreringsstöd men eftersom verk-tyget inte är gratis har det inte fått lika stort genomslag som Eclipse.

NetBeans

http://www.netbeans.org/

NetBeans är ett open source-verktyg som håller hög klass men kanske inte fått lika stort genomslag som Eclipse. NetBeans är liksom Eclipse plugin-baserat och har bra stöd för refaktorering och liknande som erbjuds i både Eclipse och IntelliJ IDEA.

Värt att nämna är det utmärkta stödet för Java ME som används exempelvis för ut-veckling av applikationer som ska köras på en mobiltelefon.

Cygni | 08-459 93 30 | info@cygni.se | cygni.se | stacktrace.se

Kontinuerlig integrationKontinuerlig integration kallas på engelska Continuous Integration – CI. Konceptet innebär att versionshanterad källkod kontinuerligt kommer att kompileras (det vill säga integreras i kodbasen). Typiskt så installeras en CI-server som ansvarar för den kontinuerliga integration och denna startar ett nytt bygge så fort någon fil i versionshanteringssystemet ändrats. Om ett kompileringsfel uppstår så kan utvecklarna i projektet notifieras av CI-servern via exempelvis e-post för att genast kunna åtgärda problemet.

Utöver kompileringsfel kan även enhets-tester och liknande exekveras vilket innebär att CI-servern direkt hittar ifall något enhetstest misslyckas.

Utvecklarna brukar bli motiverade att endast checka in kod som faktiskt kompilerar för att inte ”sätta stopp i maskineriet” för de andra utvecklarna.

Fördelar med CI:

● Kontinuerlig återkoppling på hur systemet ”mår”

● Fel hittas tidigt – Inte i anslut-ning till testperiod eller release

● Kodkvaliteten ökar

● Koden testas ofta (via auto-matiserade tester)

● Det är enkelt att hämta det senaste bygget

CruiseControl

http://cruisecontrol.sourceforge.net/

CruiseControl är ett av de vanligaste verktygen för CI. Det erbjuder stöd för det mesta inom CI men kräver en viss mängd konfiguration för att få allt att fungera. CruiseControl är open source men det finns även en kommersiell variant som kallas Cruise.

Continuum

http://continuum.apache.org/

Continuum är ett CI-verktyg som är gjort för integration med Maven. Continuum är enkelt att sätta upp om Maven-filerna är i ordning men erbjuder endast ett subset av de features som finns i exempelvis CruiseControl. Beroende på vilka krav som ställs på CI-verktyget kan Continuum dock räcka till.

Continuum utvecklas via Maven-projektet och är open source.

Hudson

https://hudson.dev.java.net/

Hudson är ett modernt CI-verktyg som är enkelt och lättkonfigurerat. Hudson erbjuder stöd för många delar inom CI såsom rapporter men till skillnad från exempelvis CruiseControl är det betydligt enklare att konfigurera. Översiktssidan som beskriver systemets ”hälsa” är lättmanövrerad och tydlig.

Hudson är en open source-produkt och rekommenderas varmt, speciellt för nya projekt.

Cygni | 08-459 93 30 | info@cygni.se | cygni.se | stacktrace.se

EnhetstesterEnhetstester handlar om att skriva testfall i Java som testar begränsade delar av koden. Ett enhetstest exekverar typiskt väldigt fort och testar kanske en eller ett par klasser. Grundtanken är att irrelevanta delar av koden ”mockas” – det vill säga att man fejkar de komponenter som inte är relevanta för testet.

Ett enhetstest exekveras i olika steg, dessa är setup, test, assert och tear down. Detta innebär att ett test först sätter upp de komponenter och det data som ska användas för testet. Sedan exekveras själva testet (exempelvis att man kör en metod som ska testas). Därefter sker en eller flera asserts – det vill säga verifieringar av det förväntade utfallet. Utan asserts har man ju faktiskt inte verifierat att koden gör som den ska. Det sista steget handlar om att rensa upp komponenter och data som använts så att nästa enhetstest kan exekveras.

Det finns flera typer av ramverk som hanterar både enhetstester och så kallad mockning av komponenter. De vanligaste enhetstestramverken är JUnit och TestNG medan de vanligaste ramverken för att mocka komponenter är EasyMock, JMock, RMock och Mockito.

När det gäller agil utveckling har enhets-tester visat sig vara ett ovärderligt verktyg. Genom att tidigt införa dessa tester erhålls typiskt avsevärt högre kvalitet på koden.

Enhetstester passar bra in i bygg-processen eftersom dessa tester typiskt kan exekveras via exempelvis Maven eller andra automatiserade byggverktyg.

JUnit

http://junit.org/

JUnit är det vanligaste verktyget för enhetstester på marknaden. Det är open source och välbeprövat.

Det finns dock några delar av JUnit som har förbättringspotential såsom stöd för multitrådade tester. Dessa områden kommer säkert att täckas upp i nyare versioner av JUnit och flera av dessa har redan täckts upp av TestNG.

Det finns två större versioner av JUnit. Version 3.8+ och version 4+. Skillnaderna är att version 4+ använder annotationer för att styra den testsvit som ska köras medan version 3.8+ ger stöd för Java 1.4 och använder reflection.

TestNG

http://testng.org

TestNG bygger är ett verktyg för enhets-testning som skapats för att kompensera de brister som funnits i JUnit. TestNG har liksom JUnit ett brett stöd i javavärlden och integrerar väl med de flesta verktyg.

TestNG erbjuder ett unikt stöd för testning av multitrådning, hantering av testdata via datasets, att testa för ”failure” istället för ”success” det vill säga att man testar för att verifiera att exempelvis ett undantag sker snarare än att man testar att det inte ska ske.

RMock

http://rmock.sourceforge.net/

RMock är ett mockverktyg som används för att ”mocka” irrelevanta komponenter samt för att definiera vissa förväntade beteenden på en viss komponent.

RMock använder liksom verktygen EasyMock och jMock metoden expect-run-verify som innebär att man först sätter upp förväntningar, därefter exekverar koden och sist sköter ram-verket verifiering av att alla förväntningar uppfyllts. Detta kan tyvärr leda till att många förväntningar som är irrelevanta måste sättas upp och koden blir därmed svårläst och lång.

Mockito

http://code.google.com/p/mockito/

Mockito är ett nytt och modernt mock-ramverk. Ramverket kan i stort sett samma saker som exempelvis RMock men man har lagt ett stort fokus på att den testkod som skrivs ska bli så enkel som möjligt.

Cygni | 08-459 93 30 | info@cygni.se | cygni.se | stacktrace.se

ProjektkommunikationSnabb feedback och maximal tillgång till projektinformation är faktorer som effektiviserar utvecklingsprojektets väg framåt. I communities för open source och agil utveckling har det över tiden tagits fram flera verktyg och arbetssätt för att underlätta flödet och tillgången till information och kommunikationen mellan projektmedlemmarna.

Wiki

En wiki är en lättviktig textbaserad webb-sajt, med mycket låg tröskel för vem som helst (som har rättigheter) att lägga till nya sidor och redigera befintliga dito. Det gör det som ett utmärkt verktyg att samla in och spara den ackumulerade kunskap som projektet och dess medlemmar samlar på sig under resans gång. Det är här man hittar webbsidor som beskriver allt från vilka kodregler man ska använda sig av och vilka lösenord det är på testservrarna, till designdokument som resonerar kring hur man valt att lösa specifika problem som behöver vara känt av hela projektet.

Google Docs

Där en wiki-sida blir för enkel för den information som ska behandlas så vänder man sig snart till ett Office-program av något slag. Det kan vara för att man vill ha bättre kontroll över formatteringen eller för att man vill ha en tabell med beräkningar eller liknande. Nackdelen med de traditionella Office-sviterna (Microsoft Office) är att det ställer krav på att alla har dessa installerade (och samma version dessutom) och att man måste vara noga med att hantera dokumenten så att man inte råkar uppdatera samma dokument samtidigt på olika ställen.

Ett bra alternativ är att använda sig av Googles webbaserade Office-svit: Google Docs (http://docs.google.com). Funk-tionerna är inte lika kompletta och avancerade som de installerade alternativen, men det går ändå att göra relativt avancerade saker utan krav på en installerad programvara (utöver en vanlig webbläsare) och eftersom dokumenten ligger på nätet så får man versions-hantering och åtkomsthantering på köpet!

Instant Messaging (IM)

IM kan användas till mer än att chatta med kompisarna om var man ska ta sin after-work-öl just idag... Om alla i projektet ser varandra online via ett bra IM-verktyg så underlättar det mycket när man vill skicka små kodsnuttar, länkar till bra informationskällor på nätet och annan typ av kort textuell information. Om ni dessutom kopplar upp CI-verktyget till nätet så får alla samma omedelbara feedback på hur läget är på bygget och om det är några tester som fallerar och måste åtgärdas.

Maven-projektsajt

Maven kan generera en kodrelaterad projektsajt till dig, vid varje automatiserat bygge (som en del av den kontinuerliga integrationen). Du kan konfigurera genereringen så att de den tar med de delar ni i projektet är intresserade av, till exempel JavaDoc, syntaxmarkerad käll-kod (JXR), länkar till projekt-dokumentation på andra ställen och rapporter från alla de övriga verktygen vi tar upp i det här kompendiet. Eftersom sajten genereras om i samband med incheckning är den alltid i synk med koden som ligger i repositoryt.

Old school

Flera av ovanstående verktyg hanterar information som man tidigare kanske hade återfunnit på post-it-lappar eller på någon projekt-whiteboard. Ofta kan man få samma effektivitet fast bättre spridning och tillgänglighet på informationen om man använder rätt systemverktyg istället, men det betyder inte på något sätt att lapparna och skrivtavlorna inte har en roll att fylla! Se till att även ha med dessa i valet av verktyg och välj det som passar bäst just för er!

Cygni | 08-459 93 30 | info@cygni.se | cygni.se | stacktrace.se

KodtäckningDet finns en mängd verktyg för att mäta hur stora delar av koden som körs, både vid exekvering och test av applikationen. Vid testning av en applikation kan 80%-regeln vara bra att tillämpa. Om man täcker 80% av all kod via sina tester har man en väldigt hög täckningsgrad – det är nästan omöjligt att nå upp till 100% och det är varken nödvändigt eller kostnadseffektivt.

Verktyg för kodtäckning kan både köras för att generera rapporter vid ett automatiserat bygge och kan även integreras i utvecklingsmiljön. När verk-tygen integreras i utvecklingsmiljön får utvecklaren ett bra stöd för att se vilka kodrader som täcks att ett specifikt test som denne just nu utvecklar.

Förutom de open source-alternativ som presenteras till höger finns även flera kommersiella verktyg för kodtäckning såsom Clover. Det finns dessutom en flora av alternativa open source-verktyg men Cobertura fungerar bra för auto-matiserade byggen via exempelvis Maven och EclEmma rekommenderas för integration med Eclipse.

Cobertura

http://cobertura.sourceforge.net/

Cobertura är ett verktyg som mäter vilka metoder och vilka instruktioner i koden som exekverats. Detta sker genom så kallad instrumentation av bytekoden (det vill säga den kompilerade koden). Detta innebär att koden måste kompileras på ett speciellt sätt så att Cobertura kan sätta in sina mätpunkter som sedan används vid själva exekveringen.

Cobertura är ett open source-verktyg som integrerar väl med Ant och Maven och kan generera detaljerade rapporter i både XML- och HTML-format.

EMMA

http://emma.sourceforge.net/

EMMA är liksom Cobertura ett kod-täckningsverktyg som instrumenterar bytekoden. EMMA är också open source och kan integreras med Ant och Maven.

En skillnad mellan EMMA och Cobertura är att EMMA kan hantera kodrader med partiell täckning, det vill säga att om en del av en rad har exekverats markeras den raden som delvis exekverad.

EclEmma

http://www.eclemma.org/

EclEmma är en plugin till Eclipse som baseras på kodtäckningsverktyget EMMA. Denna plugin integrerar väl med ut-vecklingsmiljön och utvecklaren får ett bra stöd för att se vilka rader kod som körs av ett visst test.

Bilden nedan visar hur det kan se ut efter körning av ett enhetstest.

Cygni | 08-459 93 30 | info@cygni.se | cygni.se | stacktrace.se

BeroendenOm man använder en modern arkitektur som är komponentbaserad är det viktigt att beroenden mellan komponenter och paket är tydliga. Man bör dessutom undvika cirkulära beroenden mellan komponenter och paket i största möjliga mån. Detta för att bygga en så lätt-förvaltad applikation som möjligt som har en komponent-/modulmodell som håller över tiden.

Det finns ett begränsat antal verktyg för att mäta denna typ av beroenden på en kodbas. Det kanske mest kända verktyget JDepend producerar rapporter som är svårtolkade. Dock har nya kommersiella alternativ dykt upp på marknaden som till exempel SonarJ.

Verktyg som tolkar beroenden kan användas i den automatiska bygg-processen genom att specificera olika gränsvärden som är tillåtna. Exempel på dessa värden kan vara vilka beroenden som är tillåtna, hur många beroenden en komponent får ha och så vidare.

JDepend

http://clarkware.com/software/JDepend.html

JDepend är ett verktyg som kontrollerar vilka beroenden som finns mellan olika paket.

Formatet på den rapport som genereras kan antingen vara XML eller HTML. Dock säger inte rapporten så mycket om exempelvis vilka cirkulära beroenden som finns utan dessa beroenden får utvecklaren själv gräva fram utifrån rådatat som produceras i rapporten.

Classycle

http://classycle.sourceforge.net/

Classycle är ett verktyg som är likt JDepend. En av skillnaderna är att Classycle har både snyggare rapporter och faktiskt analyserar det rådata som skapas djupare än vad JdDepend gör.

Classycle erbjuder enkel integration med Ant men tyvärr är det inte lika enkelt att integrera med Maven.

SonarJ

http://www.hello2morrow.com/products/sonarj

SonarJ är ett nytt kommersiellt verktyg som kan åskådligöra beroenden i systemet på ett enkelt och tydligt sätt.

Det är möjligt att sätta upp regler för vad som är tillåtet och inte och sedan låta SonarJ indikera ifall någon bryter en sådan regel.

SonarJ används bland annat vid utveckling och kvalitetssäkring av det populära ramverket Spring Framework.

Cygni | 08-459 93 30 | info@cygni.se | cygni.se | stacktrace.se

KodkonventionerKodkonventioner är regler och re-kommendationer för namnkonventioner, indentering, kommentarer, white space och så vidare. Dessa konventioner är viktiga för att:

● 80% av kostnaden för ett mjuk-varusystem är kostnaden för för-valtning.

● Det finns nästan ingen mjukvara som förvaltas under hela dess livslängd av originalförfattaren.

● Kodkonventioner förbättrar käll-kodens läsbarhet vilket innebär att utvecklare förstår koden snabbare exempelvis i en för-valtningssituation.

● Tydliga riktlinjer underlättar ut-veckling av ny kod vilket innebär att det är ”ett beslut som inte måste fattas”. Det innebär också att nya utvecklare ”vet vad som gäller”.

SUN tillhandahåller kodningsriktlinjer som har blivit grunden till en kodstandard som används inom javavärlden. Olika projekt har olika avvikelser från denna kod-standard. Riktlinjerna kan hittas på följande adress:

http://java.sun.com/docs/codeconv/

Checkstyle

http://checkstyle.sourceforge.net/

Checkstyle kan kontrollera att kodnings-standarden i ett projekt följs enligt de riktlinjer som satts upp.

Checkstyle är mycket konfigurerbart vilket innebär att nästan alla konventioner kan stödjas av programmet. Det medföljer två stycken konfigurationsfiler som kan användas för att snabbt komma igång med Checkstyle, en fil för SUNs kod-konventioner och en fil med en ”minimal” kodstandard.

Det finns flera nivåer som kan användas när en regel bryts. De vanligaste är Warning och Error, om ett Error hittas så hanteras det på samma sätt som ett kompileringsfel.

Rapporter kan genereras och integreras i den automatiska byggprocessen.

eclipse-cs

http://eclipse-cs.sourceforge.net/

eclipse-cs är en plugin till Eclipse för att integrera Checkstyle med Eclipse. De varningar och fel som upptäcks via Checkstyle rapporteras på ett överskådligt sätt i Eclipse. Checkstyle Errors hanteras som kompileringsfel.

IDE

http://www.eclipse.org

De flesta IDE:s som exempelvis Eclipse har inbyggt stöd för formattering av Java, XML, HTML, JSP och så vidare. I Eclipse så räcker det med att trycka Ctrl + Shift + F så formatteras koden enligt de inställningar som är bestämda för det aktuella projektet. Dessa inställningar kan delas mellan projektmedlemmar vilket leder till att en person kan sätta upp alla regler men alla kan använda dem.

Cygni | 08-459 93 30 | info@cygni.se | cygni.se | stacktrace.se

Kodmassa och komplexitetStora projekt med många utvecklare leder till stora mängder kod. Mindre projekt som håller på under en lång tid leder också till stora mängder kod. Om många utvecklare använder kodbasen kommer det förr eller senare att finnas klasser och metoder som är väldigt långa och/eller väldigt komplexa. Det är viktigt att hitta dessa ”hot spots” för att:

● Om man minskar kodmassan och komplexiteten ökas förvaltnings-barheten.

● Komplex kod tar betydligt längre tid att sätta sig in i.

● Kod som är komplex är generellt sett ”error prone”.

JavaNCSS

http://www.kclee.de/clemens/java/javancss/

JavaNCSS är ett open source-verktyg som mäter bland annat Non Commenting Source Statements (NCSS) och Cyclomatic Complexity Number (CCN). Förenklat kan man säga att NCSS är ett mått på mängden kod i ett paket, en klass eller metod. CCN är ett mått på hur komplex en klass eller metod är.

Det finns rekommenderade gränsvärden för både NCSS och CCN men dessa värden bör bestämmas för respektive projekt baserat på hur komplex koden kan bli, hur duktiga utvecklare som finns i projektet, om projektet är nyutveckling eller förvaltning och så vidare.

JavaNCSS kan enkelt integreras i den automatiska byggprocessen via exempel-vis Maven.

Cygni | 08-459 93 30 | info@cygni.se | cygni.se | stacktrace.se

Potentiella buggarAtt hitta potentiella buggar (eller även faktiska buggar) är inte lätt. Javakod kan vara syntaktiskt korrekt skriven men ändå innehålla buggar.

Det finns flera verktyg som analyserar javakod och kompilerad bytekod och letar efter potentiella buggar via så kallade ”bad programming practices” (i motsats till ”best practices”). Denna typ av verktyg kan vara ovärderliga under utveckling av ny kod, uppfräschning av gammal kod och när man letar buggar. Typiskt kan dessa verktyg både användas vid automatiska byggen och via utvecklingsmiljön.

PMD

http://pmd.sourceforge.net/

PMD är ett open source-verktyg som analyserar javakod med hjälp av olika konfigurerbara regler. PMD kan analysera följande problemområden:

● Potentiella buggar

● Död kod

● Tomma statements

● Överkomplicerade uttryck

● Suboptimal kod

● Komplexitet (PMD mäter CCN såsom verktyget JavaNCSS som nämnts tidigare)

● Duplicerad kod (via CPD)

PMD kan användas i den automatiska byggprocessen via exempelvis Maven och kan generera rapporter i bland annat XML- och HTML-format.

FindBugs

http://findbugs.sourceforge.net/

FindBugs analyserar kompilerad bytekod och letar efter ”bug patterns” det vill säga kod som är skriven på ett ”dåligt” sätt.

Det fina med FindBugs är att verktyget hittar potentiella buggar som andra liknande verktyg inte hittar.

FindBugs integreras enkelt med Maven och liknande verktyg för automatiserade byggen. Utöver detta finns bra plugins till exempelvis Eclipse.

Cygni | 08-459 93 30 | info@cygni.se | cygni.se | stacktrace.se

Upprepning (D.R.Y.)Ett av de allra vanligaste "lågnivå-problemen" i en stor kodbas är att det är vanligt med upprepning av kod, så kallad "copy-paste-programmering" (CPP)...

Det ligger nära till hands när man ska lösa ett problem som man vet redan är löst på annan plats i koden att bara kopiera hela eller delar av den gamla lösningen och göra om den lite så att den passar den nya situationen. Det är faktiskt så vanligt att det är snarare regel än undantag att det förekommer i icke-triviala system, om man inte använder sig av särskilda hjälpmedel för att förhindra detta.

Vad är då problemen att göra på det här sättet? Det är ju väldigt konkret åter-användning av kod, och det är ju bra?

Eller?

Det finns många problem med det här sättet att programmera:

Många kodrader är i sig ett problem, och CPP leder ju till just detta. System med många kodrader är (allt annat lika) svårare att överblicka, svårare att söka i och svårare att förstå. Allt detta leder till att de blir svårare och dyrare att underhålla och får generellt ofta sämre kvalitet.

I och med kod-dupliceringen kommer det att finnas många ställen i kodmassan som gör samma sak, på samma sätt. Om den koden måste ändras, eller om det upptäcks fel i den som funnits redan från början, blir det en väldigt känslig uppgift att söka rätt på alla ställen som berörs och ändra dem på samma sätt.

Allt eftersom tiden går kommer koden som från början var identisk att sakta men säkert att divergera i takt med att koden underhålls och vidareutvecklas. Det kommer då att bli allt svårare att identifiera och åtgärda fel och förändringar i den kopierade koden, utan att missa något ställe och/eller att samtidigt introducera nya fel.

Lösningen på dessa problem är naturligtvis att inte använda CPP det vill säga Don't Repeat Yourself – D.R.Y.

PMD-CPD

http://pmd.sourceforge.net/

Kvalitetsverktyget PMD som nämnts tidigare har en funktion, "Copy/Paste Detection" (CPD), för att gå igenom all kod och identifera partier av kod som återfinns på flera ställen, det vill säga såna som troligen har skapats genom CPP. CPD genererar en rapport som, modul för modul, visar statistik på hur många rader kod som är redundanta. Rapporten kan länkas direkt mot källkoden för att explicit peka ut rader som borde byggas bort.

Cygni | 08-459 93 30 | info@cygni.se | cygni.se | stacktrace.se

Översikt och trenderNär man jobbar med verktyg för kvalitetssäkring blir det väldigt mycket information som genereras. Denna information kan aggregeras på ett överskådligt sätt för flera av de verktyg som nämnts tidigare.

Det finns några verktyg för att jobba med aggregerad information. Dessa verktyg använder principen ”drill-down” vilket innebär att man utifrån en översikt kan ”borra” sig ner till mer och mer detaljer.

Det är viktigt att dessa verktyg förutom ”drill-down” också kan hantera trender så att man kan se hur en applikation förändras över tiden, exempelvis hur många varningar och liknande som finns jämfört med förra releasen eller förra veckan och så vidare.

Sonar

http://sonar.codehaus.org/

Sonar är ett open source-verktyg som använder andra rapportverktyg såsom PMD och Checkstyle och sammanställer en aggregerad rapport. Verktyget är mycket trevligt med enkel och kraftfull navigering.

Med hjälp av Sonar kan man se trender det vill säga man kan se hur kvaliteten på koden förändras över tiden.

För att köra Sonar krävs att det aktuella projektet använder Maven.

De verktyg som stöds av Sonar är:

● Checkstyle

● PMD

● PMD-CPD

● Cobertura

● Clover

● JavaNCSS

● Surefire

QALab

http://qalab.sourceforge.net/

QALab är ytterligare ett open source-verktyg som använder andra befintliga rapportverktyg och aggregerar information från dessa.

QALab kan aggregera information från följande rapportverktyg:

● Checkstyle

● PMD

● PMD-CPD

● FindBugs

● Cobertura

● Simian

XRadar

http://xradar.sourceforge.net/

XRadar har inte fått lika stort genomslag som exempelvis Sonar. XRadar aggregerar information precis som de andra verktygen och presenterar resultatet på ett något annorlunda sätt (andra skärningar).

Cygni | 08-459 93 30 | info@cygni.se | cygni.se | stacktrace.se

RekommendationerNedan följer några tips för hur man kan införa de verktyg som diskuterats ovan ett projekt.

1. Sätt upp en Wiki för kommunikation inom projektet. Wikin kan användas som central kommunikationspunkt för all typ av dokumentation såsom designdokument, FAQ, how-to:s, länkar och så vidare.

2. Använd någon form av IM för snabb kommunikation mellan projektmedlemmarna. IM är ypperligt när det gäller att skicka korta kodsnuttar, ställa kortare frågor och liknande.

3. Använd ”riktiga” byggskript, bygg inte från utvecklingsmiljön. Med ”riktiga” byggskript menas Ant eller Maven. Om ett nytt projekt påbörjas borde det självklara valet vara Maven och använder ert projekt redan Ant bör ni starkt överväga att övergå till Maven. Att konvertera ett befintligt Ant-projekt till Maven är relativt enkelt. Följande fördelar erhålls

○ Tydligare beroenden till externa bibliotek

○ Enkelt att integrera med utvecklingsmiljö

○ Enkelt att konfigurera rapporter och kvalitetsverktyg

○ Enkelt att integrera med CI-verktyg

○ Enkelt att integrera med aggregerings-verktyg såsom Sonar

4. Sätt upp ett CI-verktyg. Om ni inte använder något CI-verktyg föreslås Hudson som är enkelt att sätta upp, enkelt att konfigurera och väldigt kraftfullt. CI-verktyget bör initialt hantera kontinuerliga byggen där kompilering av källkod samt exekvering av enhetstester sker.

5. Använd enhetstester! Enhetstester är det överlägset viktigaste kvalitetsverktyget för systemutveckling. Genom att testa koden på detta sätt så erhålls betydligt högre kvalitet, koden blir såklart mer testbar vilket ofta leder till en bättre applikationsdesign.

6. Installera Sonar för att övervaka trender. Sonar påverkar inte byggskripten men ger en väldigt god överblick över flera kvalitetsverktyg.

7. Påbörja mätningar av kodtäckning. Inför exempelvis Cobertura i det kontinuerliga bygget för att få kontinuerlig status på hur mycket av koden som täcks. Använd EclEmma för att integrera kodtäckning i Eclipse.

8. Specificera vilka beroenden som får finnas mellan moduler, paket och komponenter. Sätt upp JDepend eller liknande för att analysera de beroenden som finns och verifiera att arkitekturen är korrekt vid varje kontinuerligt bygge.

9. Installera FindBugs-plugin i utvecklingsmiljön och gå manuellt igenom de potentiella buggar som verktyget rapporterar.

10. Konfigurera in Copy-Paste-Detection (PMD-CPD) i det kontinuerliga bygget och lägg tid på att minska kodmassan.

11. Konfigurera in regler för kodkonventioner via Checkstyle i det kontinuerliga bygget. Starta inte med alla regler på samma gång utan börja med EN regel och bygg sedan på med fler och fler regler.

12. Konfigurera in ytterligare verktyg såsom PMD när koden blir mer och mer stabil.

Cygni | 08-459 93 30 | info@cygni.se | cygni.se | stacktrace.se