UTVECKLINGSVERKTYG Praktiska tips för PUM-projekten
TEKNIKER I PROJEKTEN ios 2 C#.NET 1 Java (inkl Android) 6 Webb (HMTL/JS) 4 En genomskumning av de tilldelade projektförslagen ger ovanstående uppfattning om fördelningen mellan tekniker, vilket till viss del påverkat val av verktyg för kommande tips.
VERSIONSHANTERING Ett system för att spåra ändringar - vad som ändrades och vem som gjorde det En väldigt bra idé att använda vid utvecklingsprojekt större än hello world
CVCS ELLER DVCS Centraliserad (Subversion) Distribuerad (GIT, Mercurial) Många har tidigare erfarenhet Bra verktyg för *NIX Alla jobbar med samma data Moget GUI-verktyg för Windows Många kopior av data (backup) Kraftfullare mergemetoder Snabb hantering med lokal data Jag tror att SVN är det bästa valet för många grupper p.g.a. ovanstående. GIT är ett kraftfullt alternativ för de som kan det, vill testa eller har speciella behov (t.ex. kundkrav). Jag kommer fokusera på SVN här.
GIT - SVÅRT?
SVN - VERKTYG TortoiseSVN, bra GUI för Windows Subversion CLI för GNU/Linux, OS X, etc Integrerat i IDE (eller som plugin) Visual Studio har VisualSVN Apple XCode har inbyggd Eclipse har flera plugins för SVN, bl.a. Subeclipse TortoiseSVN känns som ett moget GUI-verktyg för att hantera ett SVN-repository. I unix-/linuxbaserade miljöer känns det mest naturligt att använda det officiella CLIverktyget. Plugins/inbyggda i IDEer fungerar oftast bra för enklare saker (checkout, update, commit) och ger gränssnittet integrerat i utvecklingsmiljön. Kan med fördel kompletteras med ovanstående. VisualSVN är betallicens ($49), gratis för open-source
SVN - DEMO Normal användning Checkout Update Göra ändringar (Revert) Update/merge Testbygga Never break trunk Commit Meningsfull kommentar Atomic, fillåsning behövs oftast inte
SVN - BRANCHES, TAGS Vanliga kataloger Branches för separata utvecklingsspår T.ex. prototypimplementation av två olika lösningar i huvudsystemet Tags för att markera versioner, t.ex. vid släpp av beta Demo Skillnad mellan branch och tag är enbart en konvention hur det används, båda är vanliga kataloger. Branchningstrategin beror på projektet (http://svn.apache.org/repos/asf/subversion/trunk/ doc/user/svn-best-practices.html, Know when to create branches) - extremfallen är att man aldrig eller alltid branchar för ändringar man gör. Att aldrig brancha kan fungera i PUMprojekt då alla jobbar väldigt samspelt mot /trunk, att alltid brancha kan ge mycket overhead för integration. Branch-when-needed är ett mellanting som möjliggör prototypimplementationer av delar som inte nödvändigtvis integreras i slutprodukten.
SVN - TIPS Best practices Layout (trunk/branches/tags) Sammanhängade commits med meningsfulla kommentarer SVN ignore för genererade skräpfiler Expert/ansvarig i gruppen Det finns en rad best practices som är bra att följa SVN ignore kan användas för att få en klarare blick över vad som ska commitas och undvika att skräpfiler commitas av misstag. Det kan vara en fördel att utse någon i gruppen som svarar på frågor om och löser eventuella problem som uppstår med repositoriet, speciellt om branchning osv. ska användas.
IDE - INTEGRATED DEVELOPMENT ENVIRONMENT Kompilerings-/byggverktyg Debugger Inbyggd dokumentation Grafisk designmiljö Språkmedveten källkodseditor Syntax highlighting Autocompletion av variabler, funktioner, etc. Påpekar fel i koden och erbjuder hjälp att lösa problemet En IDE integrerar flera utvecklingsverktyg för att ge en mer produktiv miljö för utvecklaren.
IDE - INTEGRATED DEVELOPMENT ENVIRONMENT Språkstöd i IDE är viktigt för full nytta Eclipse - Java (Android), C/C++, PHP... Aptana - Web (PHP, JavaScript, HTML...) Visual Studio - C#, ASP.NET, WP7... XCode - Objective-C (ios, OS X)... Eclipse (med plugins) stödjer det mesta, speciellt Java (Android), C/C++ Aptana Studio är baserat på Eclipse och har fokus på webbutveckling. Visual Studio är gör sig väldigt bra för.net-utveckling och utveckling mot andra Microsoftprodukter. XCode är Apples motsvarighet till Visual Studio.
IDE - APPUTVECKLING De vanliga funktionerna Testa program i enhetssimulator Deploy till och debug på enhet Analysera programmet, hitta minnesläckor m.m. En IDE är väldigt givande för apputveckling då det erbjuder många verktyg som behövs och kan vara bökiga att koppla ihop på egen hand.
STATIC CODE ANALYSIS Metod för att hitta vanliga programmeringsmisstag och stilmissar Finns många verktyg för static code analysis Java - FindBugs, PMD Objective-C (ios) - Clang.NET - FxCop, StyleCop (JavaScript - JSLint, Google Closure) John Carmack (id Software) hyllar Static Code Analysis Javaanalysatorerna FindBugs och PMD finns som plugin till Eclipse Clang följer med XCode - aktiveras i projektinställningarna För.NET analyserar FxCop koden och StyleCop verifierar att rekommenderad kodstil följs JavaScript är svårare på grund av att det är dynamiskt - JSLint och Google Closure kan ge feedback
KODSTIL Enhetlig kodstil underlättar läsning av koden, ger bättre intryck och kan reducera misstag. Kan följa ett huvudprojekts stilguide Ett eventuellt frameworks stilguide Programmeringsspråkets stilguide
KODSTIL Kommentarsstil för dokumentationsgenerering Uppmanar till kodkommentering Enhetlig kommentarformatering Underlag för teknisk dokumentation Ex: Doxygen, JavaDoc Visa exempel på dokumentation genererad av Doxygen.
FRÅGOR?