Code-Qualität. Dr. Florian Deißenböck. AE-Kolloquium Versicherungskammer Bayern. 27. Oktober Continuous Quality in Software Engineering

Transkript

1 Code-Qualität Dr. Florian Deißenböck AE-Kolloquium Versicherungskammer Bayern 27. Oktober 2011 Continuous Quality in Software Engineering

2 Agenda Schlechter Code Code-Reviews Werkzeuge Qualitätsverfall Qualitäts-Controlling Zusammenfassung

3 #include <math.h> #include <sys/time.h> #include <X11/Xlib.h> #include <X11/keysym.h> double L,o,P,_=dt,T,Z,D=1,d, s[999],e,h= 8,I, J,K,w[999],M,m,O,n[999],j=33e-3,i= 1E3,r,t, u,v,w,s= 74.5,l=221,X=7.26, a,b,a=32.2,c, F,H; int N,q, C, y,p,u; Window z; char f[52] ; GC k; main(){ Display*e= XOpenDisplay( 0); z=rootwindow(e,0); for (XSetForeground(e,k=XCreateGC (e,z,0,0),blackpixel(e,0)) ; scanf("%lf%lf%lf",y +n,w+y, y+s)+1; y ++); XSelectInput(e,z= XCreateSimpleWindow(e,z,0,0,400,400, 0,0,WhitePixel(e,0) ),KeyPressMask); for(xmapwindow(e,z); ; T=sin(O)){ struct timeval G={ 0,dt*1e6} ; K= cos(j); N=1e4; M+= H*_; Z=D*K; F+=_*P; r=e*k; W=cos( O); m=k*w; H=K*T; O+=D*_*F/ K+d/K*E*_; B= sin(j); a=b*t*d-e*w; XClearWindow(e,z); t=t*e+ D*B*W; j+=d*_*d-_*f*e; P=W*E*B-T*D; for (o+=(i=d*w+e *T*B,E*d/K *B+v+B/K*F*D)*_; p<y; ){ T=p[s]+i; E=c-p[w]; D=n[p]-L; K=D*m-B*T-H*E; if(p [n]+w[ p]+p[s ]== 0 K <fabs(w=t*r-i*e +D*P) fabs(d=t *D+Z *T-a *E)> K)N=1e4; else{ q=w/k *4E2+2e2; C= 2E2+4e2/ K *D; N-1E4&& XDrawLine(e,z,k,N,U,q,C); N=q; U=C; } ++p; } L+=_* (X*t +P*M+m*l); T=X*X+ l*l+m *M; XDrawString(e,z,k,20,380,f,17); D=v/l*15; i+=(b *l-m*r -X*Z)*_; for(; XPending(e); u *=CS!=N){ XEvent z; XNextEvent(e,&z); ++*((N=XLookupKeysym (&z.xkey,0))-it? N-LT? UP-N?& E:& J:& u: &h); --*( DN -N? N-DT?N== RT?&u: & W:&h:&J ); } m=15*f/l; c+=(i=m/ l,l*h +I*M+a*X)*_; H =A*r+v*X-F*l+( E=.1+X*4.9/l,t =T*m/32-I*T/24 )/S; K=F*M+( h* 1e4/l-(T+ E*5*T*E)/3e2 )/S-X*d-B*A; a=2.63 /l*d; X+=( d*l-t/s *(.19*E +a *.64+J/1e3 )-M* v +A* Z)*_; l += K *_; W=d; sprintf(f, "%5d %3d" "%7d",p =l /1.7,(C=9E3+ O*57.3)%0550,(int)i); d+=t*(.45-14/l* X-a*130-J*.14)*_/125e2+F*_*v; P=(T*(47 *I-m* 52+E*94 *D-t*.38+u*.21*E) /1e2+W* 179*v)/2312; select(p=0,0,0,0,&g); v-=( W*F-T*(.63*m-I*.086+m*E*19-D*25-.11*u )/107e2)*_; D=cos(o); E=sin(o); } }

4 } for (const_iterator<permission> permission = permissions.begin(); permission!= permissions.end(); ++permission) { if (!permission->isinternal()) { if (user->haspermission (permission)) { cout << " " << permission << endl; } } } } } } /* bezieht sich auf if in Zeile 172 */ Zeilen C# in einer Klasse Zeilen C# in einer Methode Schachtelungstiefe Parameter

5 Bezeichner Anzahl S0 810 S1 612 r1 490 I1 423 S2 362 i1 248 S3 211 SQL 199 CM 193 I2 155 Type # % chars % Keywords % % Delimiters % % Operators % % Identifiers % % Literals % % Total % % Eclipse 3.0: Bezeichner bestehend aus Wörtern Identifikatoren sind das Vokabular eines Programms (ca. 70%) Synonyme & Homonyme Limitierung durch Programmiersprachen F. Deißenböck, M. Pizka, Concise and Consistent Naming, IWPC, 2005

6 /* if-else-kaskade */ if (GlobalSettings::mayPrintToConsole ()) { if (!user->isadmin()) { if (!permission->isinternal()) { if (user->haspermission int search (String s, String[] strings) { //strings = tolowercase(strings); strings = sort(strings); List<String> l = aslist(strings); return search(s, strings); }

7 TODO: ist das wirklich Okay, einem QWidget einen QObject Parent zu geben? TODO: Soll das so sein? Jetzt echt? Alle alten Sachen in die Tonne? TODO: ist es korrekt? TODO: find the real reason, why this can become VOID FIXME: solve timeout problem FIXME: fix it as soon as we know the iso format hack for supporting international iso messages TODO: remove this hack 2011 CQSE GmbH

8 public double calc (double d1, double 2) { if (d1 == d2) { return 0; }... public double comp (String s1, String s2) { if (s1 == s2) { return 0; } CQSE GmbH if (condition); { code_in_if (); } if (a<1 && a>5) { code_in_if (); } Socket s = new Socket (" ", 8080); return valid? true : false; Redundante Literale Magic Numbers GOTO Ausgerollte Schleifen public int find (String[] strings) { prepare(strings); int result = findprep(strings); Logger.debug(sort(strings)); return result; }

9 private static class Dir extends PathEntry { private String dir; Dir(String d) { dir = d; } ClassFile getclassfile(string name, String suffix) throws IOException { final File file = new File(dir + File.separatorChar + name.replace('.', File.separatorChar) + suffix); return file.exists()? new ClassFile() { public InputStream getinputstream() throws IOException { return new FileInputStream(file); } public String getpath() { try { return file.getcanonicalpath(); } catch(ioexception e) { return null; } } public long gettime() { return file.lastmodified(); } public long getsize() { return file.length(); } public String getbase() { return dir; } } : null; }...

10 Juergens et al., Do Code Clones Matter?, ICSE 2009

11 Probleme Redundanzen blähen Artefakte unnötig auf Volumen beeinflusst Wartungsaufwand (Dokumentation, Testen, Programmverstehen, ) Änderungen werden aufwändiger Änderung an einem Klon betrifft vermutlich auch andere Klone Änderung muss mehrfach durchgeführt werden Vergleiche: Updateanomalien in Datenbanken Fehlerpotential Notwendige Folgeänderungen an Klonen können übersehen werden Inkonsistenzen entstehen

12

13

14 Studie Werden Klone inkonsistent gewartet? Sind Inkonsistenzen ungewollt? Führen ungewollte Inkonsistenzen zu Fehlern? Untersuchte Systeme 3 industrielle C#-Systeme ( kloc, Alter 3-6 Jahre) 1 industrielles COBOL-System (200 kloc, Alter 17 Jahre) 1 Open-Source Java-System (280 kloc, Alter 8 Jahre) Durchführung Werkzeuggestützte Identifikation von inkonsistenten Klonen > 700 Inkonsistenzen durch Entwickler bewertet Juergens et al., Do Code Clones Matter?, ICSE 2009

15 Clones C Inconsistent Clones IC Unintentional Inconsistent Clones UIC Faulty Clones F System A B C D Sysiphus Sum Mean Clone groups C Inconsistent clone groups IC Unintentionally inconsistent clone groups UIC Faulty clone groups F Prop. inconsistent clone groups IC / C Prop. unintended inconsistencies UIC / IC Prop. faults for inconsistent clones F / IC Prop. faults for unintentionally inconsistent clones F / UIC

16 LoC Clone LoC Aug. 04 Okt. 04 Dez. 04 Feb. 05 Apr. 05 Jun. 05 Aug. 05 Okt. 05 Dez. 05 Feb. 06 Apr. 06 Jun. 06 Aug. 06 Okt. 06 Dez. 06

17 public class Order { private String name; private List<Item> items; private Date date; public class Order { private String name; private List<Item> items; private Date date; 2011 CQSE GmbH } public String getname () { return name; } public List<Item> getitems() { return items; } public Date getdate () {return date; }... } public List<Item> getitems() { return helper(items); } List<Item> helper(list<item> items){...} Kapselung Visibilities Verschattung Static vs Non-Static»finale«Felder ungenutzte Variablen unnötige Getter/Setter unnötige Interfaces Equals/Hashcode-Implementierung

18 try {... } catch (Throwable t) {} try {... } catch (Exception ex) { ex.printstracktrace(); } try {... } catch (Exception ex) { throw new RuntimeException(ex); } ungenügende/keine Behandlung von Ausnahmen inkonsistente Verwendung von Ausnahmen Ausnahmen vs Rückgabewerte Java: Checked vs Unchecked Exceptions

19 2011 CQSE GmbH

20 Dokumentation Implementierung Dokumentation Implementierung

21 Studie Projekt Alter kloc #Beziehungen #Abweichungen Doku. Probleme Architektur- Verletzungen A ~90% ~10% B ~88% ~12% C ~72% ~28% Erkenntnisse Dokumentation typischerweise veraltet Vielzahl relevanter Verletzungen aufgedeckt (inkl. Bugs) gemeinsames Architekturverständnis ist nötig M. Feilkas et al., The Loss of Architectural Knowledge during System Evolution, ICPC 2009

22 >10 Programmiersprachen in einem System Wahl der Sprache auf Basis der Entwicklerverfügbarkeit veraltete Technologien Sprachvermischung

23 <body> <% If Request.QueryString( ID ) <> Then %> <SCRIPT language= JavaScript > function dologin() { X } </script> <% Else %> <SCRIPT language= JavaScript > function dologin() { Y } </script> <% End If %>... </body> 2011 CQSE GmbH

24 35 Trigger entführte Tabellen/verlorene User SQL-Injection Impact-Analyse auf Zuruf

25 Tests, die kontinuierlich fehlschlagen Unit-Tests, die nichts testen Mangelnde Testbarkeit Capture&Replay-Werkzeuge

26 public void perform(string s) { Tracer.enter("perform"); dosomething(s); Tracer.exit("perform"); } public String read(file f) { FileReader reader = new FileReader(f);... } Text-Encodings Datentypen (Nicht-)Benutzung von Bibliotheken Thread-Sychronisierung»nach Gefühl«Logging/Tracing Missbrauch von Sprachkonstrukten Lizenzverletzungen Quelltext-Layout Verteilung auf verschiedene Artefakttypen (Dependency Injection) Code-Formatierung

27 Manuelle Reviews viele relevante Qualitätseigenschaften sind nicht automatisch analysierbar Bezeichner Kommentare sinnvolle Verwendung von Datenstrukturen und Algorithmen Konsistenz der Fehlerbehandlung logische Redundanz diese Eigenschaften bedürfen der manuelle Analyse manuelle Analysen werden in der Praxis nur spärlich eingesetzt manuelle Analysen sollten soweit möglich durch automatische Analysen unterstüzt werden

28 Reviews bei der ConQAT-Entwicklung flächendeckendes Review aller Änderungen auf Basis des Ampelzustands der angepassten Dateien Sammlung der Issues als TODO-Tags im Code review creation release review RED YELLOW GREEN deletion modification

29

30 Werkzeuge Metrik-Tools Rule-Checker Java: PMD, Checkstyle, FindBugs, C#: FxCop, Gendarme, Fortify, C/C++: PCLint, Klocwork, Coverity, Cobol: Fortify,? Compiler & IDEs Clone-Detection: ConQAT, CloneDR, CCFinder, Architektur-Analyse: ConQAT, Lattix, Structure-101,

31 Architektur-Konformität Ziele Aufdecken von Architekturverletzungen Aufdecken von Schwächen in Architekturdokumentation Konservierung des Architekturwissens Motivation Programmverstehen Impact-Analyse Ansatz Architekturdokumentation als lebendiges Entwicklungsartefakt Automatisierter Abgleich Soll-/Ist-Architektur Soll-Architektur System Differenz

32

33

34 »Programs, like people, get old«*»software aging in all successful products«ursachen: mangelnde Bewegung unkundige Behandlung Symptome: Gewichtszunahme sinkende Performance und Zuverlässigkeit Prävention: Vorausplanen (Qualität, Flexibles Design) Aufzeichnung aufbewahren (Dokumentation) zweite Meinung einholen (Review) Heilkunde: Alterungsprozess aufhalten, Nachdokumentation Restrukturieren, Amputation * D. L. Parnas, Software Aging, ICSE, 1994

35 Beispiel Bell Labs: 100Mloc, Module, 15 Jahre, Entwickler S. G. Eick et al., Does Code Decay?, IEEE Trans. Softw. Eng., 2001 Phänomen: Änderungsaufwand/Fehlerpotential zunehmend Symptome:»bloated«Code, Behelfslösungen, Ursachen: Zeitdruck, Werkzeuge, Umfeld, Team, Architektur, Proportional zur Anzahl Änderungen

36 Änderungen gewünschte Wartbarkeit Abweichung Korrekturen Wartbarkeit Q-Ing. Entwickler System Analyse-Ergebnis (feedback) Qualitäts-Analyse Review Analyse-Tool Qualitäts-Dashboard

37 Qualitäts-Dashboards 2011 CQSE GmbH

38 Herausforderungen Aggregation und Visualisierung Anpassbarkeit und Erweiterbarkeit Vielfalt der analysierten Artefakte autonomer Betrieb Skalierbarkeit Behandlung von»false-positives«unterstützung von»brownfield Measurement«

39 ConQAT graphische DSL zur Spezifikation der Analysekonfiguration Prozessoren beschreiben Analyseoperationen Kanten beschreiben Datenfluss Blöcke ermöglichen die Wiederverwendung von Analysefunktionalität source modulea Utility.java Main.java Loader.java source modulea Utility.java 128 Main.java 244 Loader.java 331 source 703 modulea 703 Utility.java 128 Main.java 244 Loader.java /04/ /04/ /03/ /06/

40 Eingabe Quelltext (Ada, ABAP, C/C++, Cobol, C#, Java, JavaScript, VB, PL/I, ) Textdokumente (Plain, CSV, Word, PDF) Modelle (Simulink/Stateflow) Repositories (Subversion, Bugzilla) Analyse Basis-Metriken (# Files, LOC, SLOC, # Methods, Nesting Depth, ) Clone-Detection Architektur-Analyse Tool-Integration (PMD, Findbugs, JUnit, Cobertura, Klocwork, FxCop, ) Basis-Metriken (# Files, LOC, SLOC, # Methods, Nesting Depth, ) Historisierung Ausgabe verschiedene Formate (HTML, PDF, Text, ) Tabellen Diagramme (Balken, Linie, Radar, Fläche, Scatter, Torte, ) Tree-Maps (Plain & Cushion)

41 LoC Clone LoC Aug. 04 Okt. 04 Dez. 04 Feb. 05 Apr. 05 Jun. 05 Aug. 05 Okt. 05 Dez. 05 Feb. 06 Apr. 06 Jun. 06 Aug. 06 Okt. 06 Dez. 06 Feb. 07 Apr. 07 Jun. 07 Aug. 07 Okt. 07 Dez. 07 Feb. 08 Apr. 08 Jun. 08 Aug. 08 Okt. 08 Dez. 08 Feb. 09 Apr. 09

42

43 »Brownfield«-Analyse Einsatz von Werkzeugen in existierenden System meist schwierig Gründe: Big-Bang-Sanierung erfordert (unnötig) hohe Aufwände Keine Ressourcen für Big-Bang-Sanierung Big-Bang-Sanierung birgt Risiken Ansatz: Schrittweise Verbesserung Motto: Leave the campsite cleaner than you found it Erforderlich: Erkennung von Modifikationen Trennung von alten und neuen Problemen

44 Delta-Analyse Quality Dashboard Baseline Quality Dashboard Aktueller Stand

45 Quality Control as a Service 2011 CQSE GmbH

46 Zusammenfassung Schlechten Code gibt es in vielen Spielarten Schlechten Code gibt es in (fast) jedem System Schlechter Code wird schlechter wenn keine Gegenmaßnahmen ergriffen werden kontinuierliches Qualitäts-Controlling ist unerlässlich manuelle Analysen sind nicht zu ersetzen Umgang mit großen, existierenden Systemen ist eine Herausforderung

47 Kontakt Dr. Florian Deißenböck CQSE GmbH Lichtenbergstraße Garching bei München