Simon Otto Nielsen Diplomingeniør i informations og kommunikationsteknologi fra

1. Simon Otto Nielsen Diplomingeniør i informations og kommunikationsteknologi fra SDU Odense i januar 2011 Senior Developer hos Netcompany Primær kundes it systemer - 4 kodebaser af forskellig alder - 200.000+ linjer kode - 3 forskellige teknologier Primære teknologier Microsoft Dynamics CRM 2011 EPiServer CMS

2. Typisk debug flow • Udvikling af ny kode eller brug af eksisterende løsning • Test og verificering af der er en fejl • Fejlsøgning på fejlkilder • Debugging af relevant kode • Udbedring af kodefejl • Test og verificering af rettelsen fungere • Fejl rettet

3. Fejlsøgning • IT Systemer bliver mere og mere komplekse • Vi kan ikke skrive fejlfri software • Test kommer ikke ud i alle hjørner af løsningen • Der kommer flere og flere fejlkilder • Office • Installeret supporteret OS • Installeret office pakken • Office 365 • Adgang til internettet • Gyldigt login • Ledig server kappacitet • Browser der er supporteret • Backup af brugerdata

4. Fejlsøgning • Udelukkelse af bruger fejl • Browsermode, cache, manglende viden om systemet, osv. • Afgrænsning af fejlkilde • Indsnævring af ramte systemer og funktionalitet • Undersøgelse af miljø • Hvad andet sker der på serverne • Hvad andet sker der på netværket • Undersøgelse af input data • Skyldes fejlen eksterne datasom håndteres uhændsigtsmæssigt

5. Historie fra erhvervslivet

6. Historie fra erhvervslivet • 600.000+ medlemmer er afhængige af deres data står rigtigt for at kunne logge ind • Data kommer fra ekstern leverandør via en kopiering til en staging database • Fuld load af data tager ca. 3 dage, jobbet køre automatisk hver fredag lige før midnat • Systemet verificere data kvalitet, ikke kvantitet • Ekstern leverandør misser data leverancen så der ikke er nogen data • Alle medlemmer fjernes fra systemet • Fejlen opdages først tirsdag da alle medlemmer er fjernet • Førte til tjek på data kvantiet • Fejlfri kode der ikke tager højde for alt kan føre til uventet fejl

7. Test • Er oftest sket manuelt • Har ofte ikke haft stort fokus • Er på vej ind efter lektioner lært af f.eks. Amanda og polsag

8. Unit tests • Sikre at koden bliver testet på samme måde hver gang • Gør test til et klik med musen i stedet for en langsommelig procedure • Bliver brugt mere og mere • Kernen i Test Driven Development

9. Debugging • Koden bliver mere og mere kompleks • Sikkerhed for at input data er som forventet • Sikkerhed for at output data er som forventet • Let at manipulere med data imens koden køre • Fanger simple fejl hurtigt • Giver tid til at grave i dybden med komplekse problemer

10. Simpel kode • Let at overskue • Indeholder sjældent fejl publicstaticvoid main(String[] args) { System.out.println("Hello World!"); } publicdoubleCalculateTax(intamount, doubletax){ returnamount*tax; }

11. Kompleks kode med fejlhåndtering • Fejler sjældent • Får sjældent systemet til at gå ned • De typiske fejl senarier er oftest gennemtænkt • Let at fejlsøge på det præcise senarie publicData retriveData(UUID ID) { try{ return_DataManager.getData(ID); } catch (Exception ex){ _Logger.log("Error in retriveData" + ex.toString()); } return_DataManager.getDefault(); }

12. Kompleks kode uden fejlhåndtering • Fejler oftere • Svært at fejlsøge • Den egentlige fejl kan være skjult længere nede i koden • Typiske fejl er typisk ikke gennemtænkt • Indeholder ofte skjulte null pointers publicvoidsetBookings(){ String[] instruments = BookingSystem.getInstance().requestListOfOwnBookings(); intlength = instruments.length; for(int i=0; i<length; i++){ table.setValueAt(instruments[i], i, 0); } String[] times = BookingSystem.getInstance().getBookingTimes(); length= times.length; for(int i=0; i<length; i++){ table.setValueAt(times[i], i, 1); } }

13. Det meget generiske • Fejler sjældent • De typiske fejl er oftest gennemtænkt • Oftest single point of failure • Er svært at sætte sig ind i • Tager lang tid at debugge

14. Det meget generiske protectedTResponsePerformCall<TClient, TRequest, TResponse> (Func<TClient, TRequest, TResponse> call, Trequestreq, TClient cli) whereTClient : class { varcontext = BeforeCall(req); try { varresponse = call(cli, req); AfterCall(response, context, false); returnresponse; } catch(FaultException ex) { stringmessage = String.Format("Webservice ID: '{0}' threwexceptionafter {1} ms.", context.CallLogId, context.Stopwatch.ElapsedMilliseconds); Logger.ErrorFormat(ex, message); throw; } catch(Exception ex) { stringmessage = String.Format("Webservice ID: '{0}' threwconnectionexceptionafter {1} ms.", context.CallLogId, context.Stopwatch.ElapsedMilliseconds); Logger.ErrorFormat(ex, message); throw; } }

15. Historie fra erhvervslivet • Ved skift af hjemmeside layout begyndte dankort indbetalinger at fejle. • Fejlen skyldtes en nullpointerexception fordi dankort modulet ikke længere lå samme sted på siden som det plejede. ExtensionPageDatastructure = PageDataManager.LoadPageStruct(requestedPageReference); varcontentArea = structure.ContentAreas[0]; vardata = contentArea.ContentFunctions[0]; vararea = data.ContentAreas[1]; • Fejlen havde været langt mere åbenlys hvis der var bedre logning omkring kaldet.

16. Fiddler • www.fiddler2.com

17. dotTrace • http://www.jetbrains.com/profiler/

18. SQL Profiler • Del af Microsoft SQL Server

19. Debugging i praksis (Eclipse demo) • Breakpoints • Watch/Expresions • Locals • Step in • Step over • Step out • Unittest

20. Debugging tips og tricks • Start altid fra toppen af det flow der fejler. • Tjek forventet input/output på alle metoder er korrekt, inden der hoppes videre til næste metode. • Find ud af hvad du forventer en metode gør inden den kaldes, hvis den giver andet output end du forventer undersøg hvorfor. • Brug breakpoints i stor stil, flyt dem efterhånden som du ved koden fungere som du forventer. • Fjern flest mulige eksterne fejlkilder (Databaser, filsystem, webservices osv.). • Forklar problemstillingen for en anden, ofte belyser det problemstillingen fra en ny vinkel.

21. Workshop Opgaver kan findes på www.farmerhe.dk/NC