Cygni Powertools 1.0

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

Om Cygni

Javakonsultbolaget Cygni grundades i Den genomsnittlige Cygnikonsulten är 35
mars 2006. Sedan dess har bolaget växt år och har 12 års professionell erfarenhet
med god lönsamhet och mycket hög av avancerad systemutveckling. De flesta
kundnöjdhet. Idag är Cygni 25 anställda av Cygnis konsulter är civilingenjörer,
och sysselsätter även ett antal under- vanligtvis från D-linjen på KTH. En
konsulter. Cygnikonsult är van att snabbt sätta sig in
i kundens verksamhet, oavsett bransch,
Cygni är specialister på att utveckla och därmed möjliggöra en snabb och
avancerade Java- och Java EE- effektiv systemutveckling i linje med den
applikationer. Samtliga Cygnis konsulter övergripande kravbilden.
är utvecklare och/eller systemarkitekter
med lång erfarenhet från projekt i en
mängd olika branscher och teknik-
domäner.


Byggverktyg
Det finns en flora av byggverktyg på Apache Ant Maven 2
marknaden varav de flesta av dessa
http://ant.apache.org/ http://maven.apache.org
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 Apache Ant är ett av de vanligaste verk- Maven 2 är ett verktyg för automatiserade
det system eller den produkt man ut- tygen för automatiserade byggen. Det är byggen. Maven har stora likheter med
vecklar. Det är viktigt att byggverktyget likt make men är byggt på Java och Apache Ant men använder sig av en
är deterministiskt det vill säga att kräver således en javaplattform för att princip som kallas Convention over
resultatet som produceras blir lika varje kunna köras. Apache Ant passar bäst för Configuration som innebär att bygg-
gång. Dessutom är det viktigt att det att bygga javaprojekt. skripten blir väldigt korta och över-
finns möjlighet att plugga in olika blickbara. Det finns defaultvärden för
En stor skillnad mellan make och Ant är
rapporter och andra features via så kallad vilken katalogstruktur som ska användas
att Ant använder XML för att beskriva
plugin-arkitektur. och så vidare.
byggprocessen medan make använder det
gamla Makefile-formatet. En stor fördel med Maven är dess
hantering av beroenden mellan olika arte-
Omoderna verktyg: De stora nackdelarna med Ant är att fakter. Detta gäller både egna artefakter
beroenden mellan olika artefakter såsom (egna jar- eller war-filer) eller externa
Make
●
tredjepartsbibliotek och liknande inte artefakter såsom tredjepartsbibliotek.
hanteras på något enhetligt sätt samt att
Bat-filer / Shell scripts
● Externa beroenden tankas hem från
Ant-filerna blir långa och svåra att över- Mavens repository vilket innebär att ut-
IDE
● blicka. vecklare enkelt kan komma igång med
utvecklingen från vilken maskin som
helst.
Moderna verktyg:
Maven har dessutom ett väldigt bra stöd
Ant
● för rapporter och externa plugins.
Maven
●
Ivy
●
Buckminster
●


Utvecklingsmiljö
En utvecklingsmiljö är det verktyg som Eclipse IntelliJ IDEA NetBeans
utvecklaren använder mest. Det är därför
http://www.eclipse.org http://www.jetbrains.com/idea/ http://www.netbeans.org/
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.
Eclipse är ett open source-verktyg och det IntelliJ IDEA är till skillnad från Eclipse ett NetBeans är ett open source-verktyg som
Utvecklingsmiljön bör åtminstone till-
absolut vanligaste utvecklingsverktyget kommersiellt utvecklingsverktyg. IntelliJ håller hög klass men kanske inte fått lika
handahålla följande:
på marknaden. Applikationen är plugin- har gott rykte inom javavärlden och är stort genomslag som Eclipse. NetBeans är
Editor för källkod (Java, JSP,
● baserad via en teknologi som kallas OSGi liksom Eclipse baserat på en plugin- liksom Eclipse plugin-baserat och har bra
XML, HTML etc) vilket leder till att en mängd olika plugins arkitektur. IntelliJ är känt för sitt utmärkta stöd för refaktorering och liknande som
finns att ladda hem för integration med refaktoreringsstöd men eftersom verk- erbjuds i både Eclipse och IntelliJ IDEA.
Kompilator
● olika verktyg. tyget inte är gratis har det inte fått lika
Värt att nämna är det utmärkta stödet för
stort genomslag som Eclipse.
Debugger
● Eclipse erbjuder ett bra stöd för re- Java ME som används exempelvis för ut-
faktorering av källkod och filer. veckling av applikationer som ska köras
Autocompletion
●
på en mobiltelefon.
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).


Kontinuerlig integration
Kontinuerlig integration kallas på engelska CruiseControl Continuum Hudson
Continuous Integration – CI. Konceptet
http://cruisecontrol.sourceforge.net/ http://continuum.apache.org/ https://hudson.dev.java.net/
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
CruiseControl är ett av de vanligaste Continuum är ett CI-verktyg som är gjort Hudson är ett modernt CI-verktyg som är
utvecklarna i projektet notifieras av CI-
verktygen för CI. Det erbjuder stöd för för integration med Maven. Continuum är enkelt och lättkonfigurerat. Hudson
servern via exempelvis e-post för att
det mesta inom CI men kräver en viss enkelt att sätta upp om Maven-filerna är i erbjuder stöd för många delar inom CI
genast kunna åtgärda problemet.
mängd konfiguration för att få allt att ordning men erbjuder endast ett subset såsom rapporter men till skillnad från
fungera. CruiseControl är open source av de features som finns i exempelvis exempelvis CruiseControl är det betydligt
Utöver kompileringsfel kan även enhets-
men det finns även en kommersiell CruiseControl. Beroende på vilka krav enklare att konfigurera. Översiktssidan
tester och liknande exekveras vilket
variant som kallas Cruise. som ställs på CI-verktyget kan Continuum som beskriver systemets ”hälsa” är
innebär att CI-servern direkt hittar ifall
dock räcka till. lättmanövrerad och tydlig.
något enhetstest misslyckas.
Continuum utvecklas via Maven-projektet Hudson är en open source-produkt och
Utvecklarna brukar bli motiverade att
och är open source. rekommenderas varmt, speciellt för nya
endast checka in kod som faktiskt
projekt.
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


Enhetstester
Enhetstester handlar om att skriva testfall JUnit TestNG RMock
i Java som testar begränsade delar av
http://junit.org/ http://testng.org http://rmock.sourceforge.net/
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,
JUnit är det vanligaste verktyget för TestNG bygger är ett verktyg för enhets- RMock är ett mockverktyg som används
dessa är setup, test, assert och tear
enhetstester på marknaden. Det är open testning som skapats för att kompensera för att ”mocka” irrelevanta komponenter
down. Detta innebär att ett test först
source och välbeprövat. de brister som funnits i JUnit. TestNG har samt för att definiera vissa förväntade
sätter upp de komponenter och det data
liksom JUnit ett brett stöd i javavärlden beteenden på en viss komponent.
som ska användas för testet. Sedan
Det finns dock några delar av JUnit som och integrerar väl med de flesta verktyg.
exekveras själva testet (exempelvis att
har förbättringspotential såsom stöd för RMock använder liksom verktygen
man kör en metod som ska testas).
multitrådade tester. Dessa områden TestNG erbjuder ett unikt stöd för EasyMock och jMock metoden expect-
Därefter sker en eller flera asserts – det
kommer säkert att täckas upp i nyare testning av multitrådning, hantering av run-verify som innebär att man först
vill säga verifieringar av det förväntade
versioner av JUnit och flera av dessa har testdata via datasets, att testa för sätter upp förväntningar, därefter
utfallet. Utan asserts har man ju faktiskt
redan täckts upp av TestNG. ”failure” istället för ”success” det vill säga exekverar koden och sist sköter ram-
inte verifierat att koden gör som den ska.
att man testar för att verifiera att verket verifiering av att alla förväntningar
Det sista steget handlar om att rensa upp Det finns två större versioner av JUnit. exempelvis ett undantag sker snarare än uppfyllts. Detta kan tyvärr leda till att
komponenter och data som använts så att Version 3.8+ och version 4+. Skillnaderna att man testar att det inte ska ske. många förväntningar som är irrelevanta
nästa enhetstest kan exekveras. är att version 4+ använder annotationer måste sättas upp och koden blir därmed
för att styra den testsvit som ska köras svårläst och lång.
Det finns flera typer av ramverk som
medan version 3.8+ ger stöd för Java 1.4
hanterar både enhetstester och så kallad
och använder reflection.
mockning av komponenter. De vanligaste
enhetstestramverken är JUnit och TestNG Mockito
medan de vanligaste ramverken för att
http://code.google.com/p/mockito/
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.
Mockito är ett nytt och modernt mock-
Enhetstester passar bra in i bygg-
ramverk. Ramverket kan i stort sett
processen eftersom dessa tester typiskt
samma saker som exempelvis RMock men
kan exekveras via exempelvis Maven eller
man har lagt ett stort fokus på att den
andra automatiserade byggverktyg.
testkod som skrivs ska bli så enkel som
möjligt.


Projektkommunikation
Snabb feedback och maximal tillgång till Instant Messaging (IM) Old school
projektinformation är faktorer som
IM kan användas till mer än att chatta Flera av ovanstående verktyg hanterar
effektiviserar utvecklingsprojektets väg
med kompisarna om var man ska ta sin information som man tidigare kanske
framåt. I communities för open source
after-work-öl just idag... Om alla i hade återfunnit på post-it-lappar eller på
och agil utveckling har det över tiden
projektet ser varandra online via ett bra någon projekt-whiteboard. Ofta kan man
tagits fram flera verktyg och arbetssätt
IM-verktyg så underlättar det mycket när få samma effektivitet fast bättre spridning
för att underlätta flödet och tillgången till
man vill skicka små kodsnuttar, länkar till och tillgänglighet på informationen om
information och kommunikationen mellan
bra informationskällor på nätet och annan man använder rätt systemverktyg istället,
projektmedlemmarna.
typ av kort textuell information. Om ni men det betyder inte på något sätt att
dessutom kopplar upp CI-verktyget till lapparna och skrivtavlorna inte har en roll
nätet så får alla samma omedelbara att fylla! Se till att även ha med dessa i
Wiki Google Docs feedback på hur läget är på bygget och valet av verktyg och välj det som passar
om det är några tester som fallerar och bäst just för er!
En wiki är en lättviktig textbaserad webb- Där en wiki-sida blir för enkel för den
måste åtgärdas.
sajt, med mycket låg tröskel för vem som information som ska behandlas så vänder
helst (som har rättigheter) att lägga till man sig snart till ett Office-program av
nya sidor och redigera befintliga dito. Det något slag. Det kan vara för att man vill
gör det som ett utmärkt verktyg att samla Maven-projektsajt
ha bättre kontroll över formatteringen
in och spara den ackumulerade kunskap eller för att man vill ha en tabell med
Maven kan generera en kodrelaterad
som projektet och dess medlemmar beräkningar eller liknande. Nackdelen
projektsajt till dig, vid varje automatiserat
samlar på sig under resans gång. Det är med de traditionella Office-sviterna
bygge (som en del av den kontinuerliga
här man hittar webbsidor som beskriver (Microsoft Office) är att det ställer krav på
integrationen). Du kan konfigurera
allt från vilka kodregler man ska använda att alla har dessa installerade (och
genereringen så att de den tar med de
sig av och vilka lösenord det är på samma version dessutom) och att man
delar ni i projektet är intresserade av, till
testservrarna, till designdokument som måste vara noga med att hantera
exempel JavaDoc, syntaxmarkerad käll-
resonerar kring hur man valt att lösa dokumenten så att man inte råkar
kod (JXR), länkar till projekt-
specifika problem som behöver vara känt uppdatera samma dokument samtidigt på
dokumentation på andra ställen och
av hela projektet. olika ställen.
rapporter från alla de övriga verktygen vi
tar upp i det här kompendiet. Eftersom
Ett bra alternativ är att använda sig av
sajten genereras om i samband med
Googles webbaserade Office-svit: Google
incheckning är den alltid i synk med
Docs (http://docs.google.com). Funk-
koden som ligger i repositoryt.
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!


Kodtäckning
Det finns en mängd verktyg för att mäta Cobertura EMMA EclEmma
hur stora delar av koden som körs, både
http://cobertura.sourceforge.net/ http://emma.sourceforge.net/ http://www.eclemma.org/
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.
Cobertura är ett verktyg som mäter vilka EMMA är liksom Cobertura ett kod- EclEmma är en plugin till Eclipse som
metoder och vilka instruktioner i koden täckningsverktyg som instrumenterar baseras på kodtäckningsverktyget EMMA.
Verktyg för kodtäckning kan både köras
som exekverats. Detta sker genom så bytekoden. EMMA är också open source Denna plugin integrerar väl med ut-
för att generera rapporter vid ett
kallad instrumentation av bytekoden (det och kan integreras med Ant och Maven. vecklingsmiljön och utvecklaren får ett
automatiserat bygge och kan även
vill säga den kompilerade koden). Detta bra stöd för att se vilka rader kod som
integreras i utvecklingsmiljön. När verk-
En skillnad mellan EMMA och Cobertura är
innebär att koden måste kompileras på körs av ett visst test.
tygen integreras i utvecklingsmiljön får
att EMMA kan hantera kodrader med
ett speciellt sätt så att Cobertura kan
utvecklaren ett bra stöd för att se vilka
partiell täckning, det vill säga att om en Bilden nedan visar hur det kan se ut efter
sätta in sina mätpunkter som sedan
kodrader som täcks att ett specifikt test
del av en rad har exekverats markeras körning av ett enhetstest.
används vid själva exekveringen.
som denne just nu utvecklar.
den raden som delvis exekverad.
Cobertura är ett open source-verktyg som
Förutom de open source-alternativ som
integrerar väl med Ant och Maven och kan
presenteras till höger finns även flera
generera detaljerade rapporter i både
kommersiella verktyg för kodtäckning
XML- och HTML-format.
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.


Beroenden
Om man använder en modern arkitektur JDepend Classycle SonarJ
som är komponentbaserad är det viktigt
http://clarkware.com/software/JDepend.html http://classycle.sourceforge.net/ http://www.hello2morrow.com/products/sonarj
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.
JDepend är ett verktyg som kontrollerar Classycle är ett verktyg som är likt SonarJ är ett nytt kommersiellt verktyg
vilka beroenden som finns mellan olika JDepend. En av skillnaderna är att som kan åskådligöra beroenden i
Det finns ett begränsat antal verktyg för
paket. Classycle har både snyggare rapporter systemet på ett enkelt och tydligt sätt.
att mäta denna typ av beroenden på en
och faktiskt analyserar det rådata som
kodbas. Det kanske mest kända verktyget
Formatet på den rapport som genereras Det är möjligt att sätta upp regler för vad
skapas djupare än vad JdDepend gör.
JDepend producerar rapporter som är
kan antingen vara XML eller HTML. Dock som är tillåtet och inte och sedan låta
svårtolkade. Dock har nya kommersiella
säger inte rapporten så mycket om Classycle erbjuder enkel integration med SonarJ indikera ifall någon bryter en
alternativ dykt upp på marknaden som till
exempelvis vilka cirkulära beroenden som Ant men tyvärr är det inte lika enkelt att sådan regel.
exempel SonarJ.
finns utan dessa beroenden får integrera med Maven.
SonarJ används bland annat vid
utvecklaren själv gräva fram utifrån
Verktyg som tolkar beroenden kan
utveckling och kvalitetssäkring av det
rådatat som produceras i rapporten.
användas i den automatiska bygg-
populära ramverket Spring Framework.
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.


Kodkonventioner
Kodkonventioner är regler och re- Checkstyle eclipse-cs IDE
kommendationer för namnkonventioner,
http://checkstyle.sourceforge.net/ http://eclipse-cs.sourceforge.net/ http://www.eclipse.org
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 Checkstyle kan kontrollera att kodnings- eclipse-cs är en plugin till Eclipse för att De flesta IDE:s som exempelvis Eclipse
●
som förvaltas under hela dess standarden i ett projekt följs enligt de integrera Checkstyle med Eclipse. De har inbyggt stöd för formattering av Java,
livslängd av originalförfattaren. riktlinjer som satts upp. varningar och fel som upptäcks via XML, HTML, JSP och så vidare. I Eclipse
Checkstyle rapporteras på ett överskådligt så räcker det med att trycka
Checkstyle är mycket konfigurerbart vilket
Kodkonventioner förbättrar käll-
● sätt i Eclipse. Checkstyle Errors hanteras Ctrl + Shift + F så formatteras koden
innebär att nästan alla konventioner kan
kodens läsbarhet vilket innebär som kompileringsfel. enligt de inställningar som är bestämda
stödjas av programmet. Det medföljer två
att utvecklare förstår koden för det aktuella projektet. Dessa
stycken konfigurationsfiler som kan
snabbare exempelvis i en för- inställningar kan delas mellan
användas för att snabbt komma igång
valtningssituation. projektmedlemmar vilket leder till att en
med Checkstyle, en fil för SUNs kod- person kan sätta upp alla regler men alla
Tydliga riktlinjer underlättar ut-
● konventioner och en fil med en ”minimal” kan använda dem.
veckling av ny kod vilket innebär kodstandard.
att det är ”ett beslut som inte
Det finns flera nivåer som kan användas
måste fattas”. Det innebär också
när en regel bryts. De vanligaste är
att nya utvecklare ”vet vad som
Warning och Error, om ett Error hittas så
gäller”.
hanteras det på samma sätt som ett
SUN tillhandahåller kodningsriktlinjer som kompileringsfel.
har blivit grunden till en kodstandard som
Rapporter kan genereras och integreras i
används inom javavärlden. Olika projekt
den automatiska byggprocessen.
har olika avvikelser från denna kod-
standard. Riktlinjerna kan hittas på
följande adress:
http://java.sun.com/docs/codeconv/


Kodmassa och komplexitet
Stora projekt med många utvecklare leder JavaNCSS
till stora mängder kod. Mindre projekt
http://www.kclee.de/clemens/java/javancss/
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:
JavaNCSS är ett open source-verktyg som
Om man minskar kodmassan och
●
mäter bland annat Non Commenting
komplexiteten ökas förvaltnings-
Source Statements (NCSS) och
barheten.
Cyclomatic Complexity Number (CCN).
Komplex kod tar betydligt längre Förenklat kan man säga att NCSS är ett
●
tid att sätta sig in i. mått på mängden kod i ett paket, en
klass eller metod. CCN är ett mått på hur
Kod som är komplex är generellt
● komplex en klass eller metod är.
sett ”error prone”.
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.


Potentiella buggar
Att hitta potentiella buggar (eller även PMD FindBugs
faktiska buggar) är inte lätt. Javakod kan
http://pmd.sourceforge.net/ http://findbugs.sourceforge.net/
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
PMD är ett open source-verktyg som FindBugs analyserar kompilerad bytekod
verktyg kan vara ovärderliga under
analyserar javakod med hjälp av olika och letar efter ”bug patterns” det vill säga
utveckling av ny kod, uppfräschning av
konfigurerbara regler. PMD kan analysera kod som är skriven på ett ”dåligt” sätt.
gammal kod och när man letar buggar.
följande problemområden:
Typiskt kan dessa verktyg både användas
Det fina med FindBugs är att verktyget
vid automatiska byggen och via
hittar potentiella buggar som andra
Potentiella buggar
●
utvecklingsmiljön.
liknande verktyg inte hittar.
Död kod
●
FindBugs integreras enkelt med Maven
Tomma statements och liknande verktyg för automatiserade
●
byggen. Utöver detta finns bra plugins till
Överkomplicerade uttryck
● exempelvis Eclipse.
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.


Upprepning (D.R.Y.)
Ett av de allra vanligaste quot;lågnivå- Det finns många problem med det här PMD-CPD
problemenquot; i en stor kodbas är att det är sättet att programmera:
http://pmd.sourceforge.net/
vanligt med upprepning av kod, så kallad
Många kodrader är i sig ett problem, och
quot;copy-paste-programmeringquot; (CPP)...
CPP leder ju till just detta. System med
Det ligger nära till hands när man ska många kodrader är (allt annat lika)
lösa ett problem som man vet redan är svårare att överblicka, svårare att söka i
löst på annan plats i koden att bara och svårare att förstå. Allt detta leder till
kopiera hela eller delar av den gamla att de blir svårare och dyrare att
lösningen och göra om den lite så att den underhålla och får generellt ofta sämre
Kvalitetsverktyget PMD som nämnts
passar den nya situationen. Det är kvalitet.
tidigare har en funktion, quot;Copy/Paste
faktiskt så vanligt att det är snarare regel
I och med kod-dupliceringen kommer det Detectionquot; (CPD), för att gå igenom all
än undantag att det förekommer i icke-
att finnas många ställen i kodmassan som kod och identifera partier av kod som
triviala system, om man inte använder sig
gör samma sak, på samma sätt. Om den återfinns på flera ställen, det vill säga
av särskilda hjälpmedel för att förhindra
koden måste ändras, eller om det såna som troligen har skapats genom
detta.
upptäcks fel i den som funnits redan från CPP. CPD genererar en rapport som,
Vad är då problemen att göra på det här början, blir det en väldigt känslig uppgift modul för modul, visar statistik på hur
sättet? Det är ju väldigt konkret åter- att söka rätt på alla ställen som berörs många rader kod som är redundanta.
användning av kod, och det är ju bra? och ändra dem på samma sätt. Rapporten kan länkas direkt mot
källkoden för att explicit peka ut rader
Allt eftersom tiden går kommer koden
som borde byggas bort.
som från början var identisk att sakta
Eller? 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.


Översikt och trender
När man jobbar med verktyg för Sonar QALab XRadar
kvalitetssäkring blir det väldigt mycket
http://sonar.codehaus.org/ http://qalab.sourceforge.net/ http://xradar.sourceforge.net/
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
Sonar är ett open source-verktyg som QALab är ytterligare ett open source- XRadar har inte fått lika stort genomslag
innebär att man utifrån en översikt kan
använder andra rapportverktyg såsom verktyg som använder andra befintliga som exempelvis Sonar. XRadar
”borra” sig ner till mer och mer detaljer.
PMD och Checkstyle och sammanställer rapportverktyg och aggregerar aggregerar information precis som de
Det är viktigt att dessa verktyg förutom en aggregerad rapport. Verktyget är information från dessa. andra verktygen och presenterar
”drill-down” också kan hantera trender så mycket trevligt med enkel och kraftfull resultatet på ett något annorlunda sätt
QALab kan aggregera information från
att man kan se hur en applikation navigering. (andra skärningar).
följande rapportverktyg:
förändras över tiden, exempelvis hur
Med hjälp av Sonar kan man se trender
många varningar och liknande som finns
Checkstyle
●
det vill säga man kan se hur kvaliteten på
jämfört med förra releasen eller förra
koden förändras över tiden.
veckan och så vidare.
PMD
●
För att köra Sonar krävs att det aktuella
PMD-CPD
●
projektet använder Maven.
FindBugs
●
De verktyg som stöds av Sonar är:
Cobertura
●
Checkstyle
●
Simian
●
PMD
●
PMD-CPD
●
Cobertura
●
Clover
●
JavaNCSS
●
Surefire
●


Rekommendationer
Nedan följer några tips för hur man kan införa de verktyg 5. Använd enhetstester! Enhetstester är det
som diskuterats ovan ett projekt. överlägset viktigaste kvalitetsverktyget för
systemutveckling. Genom att testa koden på
1. Sätt upp en Wiki för kommunikation inom detta sätt så erhålls betydligt högre kvalitet,
projektet. Wikin kan användas som central koden blir såklart mer testbar vilket ofta leder
kommunikationspunkt för all typ av till en bättre applikationsdesign.
dokumentation såsom designdokument, FAQ,
how-to:s, länkar och så vidare. 6. Installera Sonar för att övervaka trender. Sonar
påverkar inte byggskripten men ger en väldigt
2. Använd någon form av IM för snabb god överblick över flera kvalitetsverktyg.
kommunikation mellan projektmedlemmarna.
IM är ypperligt när det gäller att skicka korta 7. Påbörja mätningar av kodtäckning. Inför
kodsnuttar, ställa kortare frågor och liknande. exempelvis Cobertura i det kontinuerliga bygget
för att få kontinuerlig status på hur mycket av
3. Använd ”riktiga” byggskript, bygg inte från koden som täcks. Använd EclEmma för att
utvecklingsmiljön. Med ”riktiga” byggskript integrera kodtäckning i Eclipse.
menas Ant eller Maven. Om ett nytt projekt
påbörjas borde det självklara valet vara Maven 8. Specificera vilka beroenden som får finnas
och använder ert projekt redan Ant bör ni starkt mellan moduler, paket och komponenter. Sätt
överväga att övergå till Maven. Att konvertera upp JDepend eller liknande för att analysera de
ett befintligt Ant-projekt till Maven är relativt beroenden som finns och verifiera att
enkelt. Följande fördelar erhålls arkitekturen är korrekt vid varje kontinuerligt
bygge.
Tydligare beroenden till externa bibliotek
○
9. Installera FindBugs-plugin i utvecklingsmiljön
Enkelt att integrera med utvecklingsmiljö
○ och gå manuellt igenom de potentiella buggar
som verktyget rapporterar.
Enkelt att konfigurera rapporter och
○
10. Konfigurera in Copy-Paste-Detection (PMD-CPD)
kvalitetsverktyg
i det kontinuerliga bygget och lägg tid på att
Enkelt att integrera med CI-verktyg
○ minska kodmassan.
Enkelt att integrera med aggregerings-
○ 11. Konfigurera in regler för kodkonventioner via
verktyg såsom Sonar Checkstyle i det kontinuerliga bygget. Starta
inte med alla regler på samma gång utan börja
4. Sätt upp ett CI-verktyg. Om ni inte använder
med EN regel och bygg sedan på med fler och
något CI-verktyg föreslås Hudson som är enkelt
fler regler.
att sätta upp, enkelt att konfigurera och väldigt
kraftfullt. CI-verktyget bör initialt hantera 12. Konfigurera in ytterligare verktyg såsom PMD
kontinuerliga byggen där kompilering av källkod när koden blir mer och mer stabil.
samt exekvering av enhetstester sker.


Cygni Powertools 1.0

Recommended

Recommended

More Related Content

Similar to Cygni Powertools 1.0

Similar to Cygni Powertools 1.0 (20)

Cygni Powertools 1.0