Clean Coding Cosmos: Teil 1: Kosmologie für Softwareentwickler

Transkript

1 Clea Codig Cosmos: Teil 1: Kosmologie für Softwareetwickler Clea Codig Cosmos: Teil 1: Kosmologie für Softwareetwickler Die Kosmologie ist die aturwisseschaftliche Diszipli, die das Big Picture userer Welt zeichet: eie vierdimesioale Raumzeit, i der verschiedee Kräfte auf Materie eiwirke. User kosmologischer Blick auf die Softwareetwicklug ergibt ei gaz ähliches Bild. Es gibt vier Dimesioe (Prozess, Wisse, Hadwerk ud Motivatio), i dee Kräfte (die Meiuge der Akteure) auf die Materie (Software) eiwirke ud diese forme. I diesem Artikel wolle wir die vier Dimesioe ud ihre Aspekte möglichst vollstädig vorstelle, ohe us i Details zu verliere. Es geht us um eie Überblick, um das Big Picture i der Softwareetwicklug. Jeder Akteur i der Softwareetwicklug (SE), z. B. Aforderugsspezialist, Etwickler, Stakeholder vo der Fachseite oder aus dem Betrieb, Edaweder, hat eie Vorstellug, wie die Materie Software sei soll oder icht sei darf. Diese Mei uge wirke i verschiedee Dime sioe als aziehede oder abstoßede Kräfte auf die Materie ei ud forme sie. Hiter dem Begriff Software verberge sich zwei sehr uterschiedliche Aspekte, die aber stark miteiader verwobe sid (siehe Abbildug 1): Zum eie gibt es eie für de Kude/Aweder sichtbare Teil der Materie (die Awedug). Zum adere gibt es eie verborgee Teil de Softwareetwicklugs pro zess im weiteste Sie (siehe Kaste 1). Beide Aspekte sid gleich wichtig ud i alle Dimesioe de abstoßede ud aziehede Kräfte ausgesetzt. Zwei dieser Dimesioe (Hadwerk ud Wisse) sid typische Hard Skills. Die meschliche Dime sio Motivatio widmet sich de Soft Skills. Da die Festlegug ud Eihaltug vo Prozesse stark vom Faktor Mesch geprägt ist, besitzt die zeitliche Dimesio Prozess eie Misch charakter. Die zeitliche Dimesio Prozess Der Lebeszyklus eier Awedug wird durch das Applicatio Lifecycle Maagemet (ALM) orgaisiert (vgl. [Wil12]). Doch wa begit dieser Zyklus? Begit er mit der erste Produktiosversio, mit dem Kick-Off des Etwicklugsprojekts oder mit dem erste Aufwad, der im Vorfeld i de Etwurf ud i die Projektplaug ivestiert wird? Die Existez eier Awedug begit virtuell mit der Idee i der Vorstellug eies Mesche (siehe Abbildug 2). Ist diese attraktiv, zieht sie weitere Idee a ud eie Visio begit, ihre Leuchtkraft zu etfalte. Ei euer Ster ist im Etwickler kosmos sichtbar geworde. Die Awedug wächst virtuell i der Afor derugsaalyse zu eiem Etwurf. Schließlich begit sie, mit der Implemetierug auch i der reale Welt zu existiere. Währed ihrer produktive Phase im Betrieb reift die Awedug. Wie ei echter Ster edet ihre Lebeszeit etweder schell ud laut, we sie ersetzt wird, oder sie erfährt ei lagsames stilles Ede, we sie immer selteer gebraucht wird. Der Ak teur, der a de meiste Phase beteiligt ist, ist der Softwareetwickler (siehe Kaste 1). Das ALM ist der Basisprozess, i de alle Teilprozesse rud um die Awedug eigebude sid. Er beihaltet oft komplexe Prozesse, die miteiader verzaht sid ud die aus eifachere Teilprozesse bestehe (siehe Kaste 2). Abb. 1: Software ist wie ei Eisberg. Das Softwareprodukt (SP) ist die Spitze des Eisbergs, die aus dem Wasser ragt. Eiige Merkmale sid och kapp uter der Wasseroberfläche erkebar. Der größte Teil aber, der die Eisbergspitze trägt, ist ur dem Isider ersichtlich. Der SEP muss für das SP mächtig geug sei, sost geht der Eisberg uter. ALM ud Traceability Problematisch beim ALM ist der Mediebruch im Iformatiosfluss zwische de Akteure, der typischerweise beim Phasewechsel im ALM auftritt: Wie stellt der Visioär sicher, dass der Afor derugs spezialist alle wichtige Idee berücksichtigt? Wie stellt der Aforderugsspezialist sicher, dass der Etwickler alle Afor deruge richtig umsetzt? Wie stellt der Etwickler sicher, dass der Betrieb alle wichtige Iformatioe zur korrekte Ibetriebahme hat? Bei dem Iforma tiosfluss über die Phasegreze ist es wichtig, Iformatioe zurückzuverfolge, das heißt festzustelle, wo Iforma tioe herkomme ud ob sich Iforma tioe geädert habe. Um diese Rück verfolgug (Traceability) sicherzustelle, wäre ei eiheitliches Repository

2 Clea Codig Cosmos: Teil 1: Kosmologie für Softwareetwickler Im weiteste Sie steht der SEP für de Lebeszyklus eier Awedug bzw. das ALM (siehe Abbildug 2). Die Akteure aller Phase trage letztlich zur Etwicklug der Software bei. Im egste Sie steht der SEP für das Kergeschäft der Software etwickler: die Implemetierug (Phase 3 i Abbildug 2) I eiem icht weite ud icht ege Si steht der SEP für das, was der Softwareetwickler zu leiste hat: Mit dem Aforderugsspezialiste die Aforderuge prüfe ud vervollstädige, die Awedug implemetiere ud zusamme mit dem Betrieb die Software eisatzfähig mache. I diesem Si schließt der SEP auch eie Teil vo Phase 2, 4 oder 5 i Abbildug 2 mit ei. I Soderfälle ka der SEP auch die Phase 1 oder 5 komplett beihalte. Kaste 1: Bedeutugsbreite des Begriffs Softwareetwicklugsprozess (SEP). sivoll, das die Akteure aller Phase gemeischaftlich utze. Außerdem ist eie etsprechede Tool-Uterstützug otwedig (siehe ute Traceability ud SLI ). Die techische Dimesio Wisse Diese Dimesio fasst all das Kow-how zusamme, das als SE-Theorie bezeichet werde köte. Dazu zähle techologisches Kow-how sowie das Verstädis vo Architektur ud Implemetierug (siehe Kaste 3). Architekturwisse Architektur hat sehr viele Aspekte (vgl. [Sta09], Kapitel 6 ud 7). Für eie saubere Architektur halte wir aus Clea-Codig- Sicht drei Qualitätsmerkmale vo Software für besoders wichtig: Erweiterbarkeit, Aa lysierbarkeit ud Testbarkeit. Diese Quali tätsmerkmale habe auch eie Impleme tierugsaspekt (uverstädlicher Quellcode midert die Qualität aller drei Merkmale). I de drei folgede Abschitte gehe wir ur auf de architektoische Aspekt ei. Erweiterbarkeit Erweiterbare Architektur beruht auf modulare Strukture (z. B. kompoeteorietierte Architektur, vgl. [Ko12]). Allerdigs habe moolithische Strukture de Vorteil, dass die Etwickler ohe Rücksicht auf Modulschittstelle implemetiere köe. Eie Vielzahl vo Schittstelle ud Abhägigkeite zwische Module erhöht ämlich die (Modul-)Komplexität Abb. 2: Phase im Lebeszyklus eier Awedug. Zu eiem Zeitpukt köe gleichzeitig verschiedee Phase aktiv sei. Das ALM orgaisiert diese Phase. Projektmaagemet: Das Etwicklerteam orgaisiere. Issue-Trackig: Neue Aforderuge oder Fehler verwalte ud bearbeite. Release-Maagemet: Die ächste Versio geau mit de beötigte Soft wareäderuge ausliefer. Defiitio of Doe: Die Kriterie festlege ud sicherstelle, dass die Implemetierugsaufgabe vollstädig abgeschlosse ist. Qualitätssicherug i der Etwicklug: Sicherstelle, dass bereits bestehede Softwarefuktioe icht ugewollt verädert wurde. Auslieferug: Die fertige Software für die Istallatio auf dem Zielsystem bereitstelle. Qualitätssicherug im Betrieb: Sicherstelle, dass die auf dem Zielsystem istallierte Software richtig fuktioiert. Kaste 2: Typische Teilprozesse/Workflows im SEP. vo Software. Jedoch habe moolithische Strukture de Nachteil eier größere (Klasse-)Komplexität. Diese Form vo Komplexität ist der große Nachteil eies Moolithe, die ih uflexibel oder gar uwartbar macht. Sie wird durch eie modulare Architektur miimiert, wobei ei Teil der Komplexität vo der Klasseauf die Modul ebee verschobe wird. Die Verschie bug vo Komplexität auf die Modulebee ist vorteilhaft, weil sie sowohl die Klasse- als auch die Gesamtk omplexität miimiert zumidest, we die Module techisch sauber ud sivoll voeiader abgegrezt sid (vgl. [Ko12], [Sta09]). Die Abgre zug vo Module (die Schitte durch de Moolithe) köe fachlich ud/oder techisch erfolge (siehe Abbildug 3). Aalysierbarkeit im Betrieb Eie Awedug, die ausdrucksstarke Ifor matioe durch Loggig, Protokollierug ud Moitorig-Fuktioe liefert (siehe Kaste 4), ist zur Laufzeit gut aalysierbar. Für die techische Realisierug dieser Ifor matiosdieste muss die Architektur eie eiheitliche Rahme zur Verfügug stelle. 4

3 Wisse, wie ma effektiv dokumetiert Dokumetatio loht sich, we sie etweder mit weig Aufwad hilfreiche Iformatio liefert (Notiz-Fuktio) oder we sie vollstädig, korrekt ud verstädlich ist (Lexiko-Fuktio). Ei Großteil vo Dokumetatio liegt dazwische, d. h. großer Umfag, aber uvollstädig ud/ oder uverstädlich letzteres häufig wege fehlede Spezialwisses der Leser. Außerdem ist es sehr schwierig, umissver Architektur ist das Treffe ud Dokumetiere vo Etscheiduge im Baupla ud Ablaufpla mit systemweiter (globaler) Tragweite. Solche Tragweite habe Etschei duge, die alle Etwickler eie eiheitliche Rahme für ihre Arbeit gebe ud für ei gemeisames Verstädis der Software esseziell sid. Desig ist das Treffe vo Etscheiduge mit mäßiger (regioaler) Tragweite. Plakativ lässt sich formuliere: Architektur ist Grobdesig. Die Umkehrug Desig ist Fei architektur ist wege magelder Tragweite falsch. Außerdem hat Desig eie stärkere Bezug zur Implemetierug ud ist i der Regel stärker fachlich orietiert. Implemetierug beihaltet das Treffe vo Etscheiduge mit lokaler Tragweite. Solche Etscheiduge habe auf die Arbeit aderer Et wickler weig Eifluss. Kaste 3: Architektur vs. Desig vs. Implemetierug. Testbarkeit Teste ist das Sammel aller Arte vo Iformatioe über das Testsystem (vgl. [Sch11]). Ohe Tests ist es praktisch umöglich, sichere Aussage zur Softwarequalität zu mache. Wird ach der TDD-Methode (Test First) etwickelt, wird vor der Implemetierug des Produktivcodes zuerst der Testcode implemetiert (vgl. [Bec02]). Auf diese Weise ergebe sich automatisch Architektur- ud Desigstrukture, die ebe der Testbarkeit auch eie bessere Erweiterbarkeit gewährleiste. Ohe die TDD-Methode werde häufig ubewusst Etscheiduge getroffe, die das achträgliche Implemetiere vo Tests praktisch umöglich mache (vgl. [Fre10]). Tabelle 1 stellt die drei typische Testebee vor: Uit-, Itegratios- ud Systemtests. Der Teststrategie i Tabelle 1 folged, sollte alle Tests regelmäßig ausgeführt werde, um Fehler möglichst frühzeitig zu fide. Das ist jedoch ur bei automatisierte Tests wirtschaftlich möglich. Diese köe allerdigs i der Wartug durch Umbaumaßahme im Quellcode oder Fuktioserweiteruge sehr aufwädig sei. Aber ohe diese Tests muss ma davo ausgehe, dass bei komplexe Systeme die Aalyse ud Behebug vo Abb. 3: Mögliche techische ud fachliche Schitte durch eie Awedug. Vorrag habe fachliche Schitte (vgl. [Par72]). Fehler och viel teurer werde als das Implemetiere ud Pflege des Testcodes (vgl. [Fea11]). Automatische Tests sid ukreativ. Deshalb sid ebe de automatische Tests, die schell ud fehlerfrei ablaufe immer zusätzlich mauelle Tests vo kreative Mesche ötig, die eue Test variate fide ud die Software im Eisatz erlebe. Wisse, wie ma verstädlich implemetiert Sauberer Code ist verstädlicher Code. Verstädlicher Code bedeutet effektive SE. Jahrzehte lage Erfahrug habe i der SE eie Reihe vo Best Practices (Patters) deutlich gemacht. Außerdem gibt es eiige typische Fehler, die immer wieder gemacht werde (Ati-Patters). Zum Teil sid diese Dos ad Do ts vo der verwedete Programmiersprache ud Techologie abhägig, zum Teil aber auch icht. Die Clea Code Developer (CCD) habe die allgemeigültige Best Practices zu eiem Regelwerk gebüdelt, desse Awedug zu sauberer SE führt. Tabelle 2 zeigt, dass es ebe de CCD-Regel aber och weiteres Wisse gibt, das für die Verstädlichkeit vo Quellcode wichtig ist. Loggig (Tracig): Speicher vo Iformatioe über die im System ablaufede Fuktioe ud Prozesse i spezielle Logdateie geeiget für techische Iformatioe. Protokollierug (Reportig): Häufig wird daruter das Speicher vo techischer ud/oder fachlicher Iformatio verstade (z.b. [Sta09] ). Wir schlage vor, uter diesem Begriff ur das Speicher vo fachliche Iformatioe zu verstehe vorzugsweise i strukturierte Form i Datebak-Tabelle. So ka dieser fachliche Aspekt besser vom Loggig abgegrezt werde. Moitorig: Automatische regelmäßige Prüfug vo Sollzustäde ud ei defiierter Alarm, we ei Sollzustad icht erfüllt ist. Kaste 1: Bedeutugsbreite des Begriffs Softwareetwicklugsprozess (SEP)

4 Clea Codig Cosmos: Teil 1: Kosmologie für Softwareetwickler Tabelle 1: Vergleich der verschiedee Testebee. städlich zu formuliere. Für eie gute Dokumetatio außerhalb des Codes helfe dabei Formu lierugsregel ud Stadard- Templates (vgl. [Rup10], [Rup09]). Für Dokumetatio im Code gilt: Whe you feel the eed to write a commet, first try to refactor so that ay commet becomes superfluous (vgl. [Fow99], [Mar08]). Wisse über Techologie Die grudlegede Techologie für eie Etwickler ist seie Programmiersprache ud dere Grudfuktioalität. Zusätzlich gibt es eie große Vielfalt vo Third-Party- Libraries, welche die Grudfuktioalität der Programmiersprache drastisch erweiter. Darüber hiaus existiere mächtige Frameworks, die dem Etwickler die Komplexität für eie umfagreiche oder schwierige Fuktio abehme. Ei guter Etwickler hat auf alle drei Ebee ei breites ud a ausgewählte Stelle auch ei tiefes Wisse. Die praktische Dimesio Hadwerk SE ohe Werkzeuguterstützug ist heute udekbar. So hägt die Produktivität stark vom Eisatz der passede Werkzeuge ud dere Beherrschug ab. Nebe diese Tool-Fertigkeite ist es für de Software etwickler ebefalls wichtig, Nutze aus modere SE-Techike zu ziehe. Traceability ud SLI Ei weiteres Problem betrifft die Kooperatiosmöglichkeite der verschiedee Tools im ALM utereiader (vgl. [Wil12]). Die letzte Jahre ware gekezeichet vo eier zuehmede Spezialisierug. Viele Werkzeuge sid geschlosse ud köe ur weig oder gar keie Iformatioe utereiader austausche. Das führt zu Mediebrüche im ALM (siehe obe, ALM ud Traceability ). Für eie Teil der Tools ist es üblich, die Itegratiosmöglichkeite eier Itegrated Developmet Eviromet (IDE) zu utze. Die IDE ist das Cockpit des Et wicklers. Nebe der Grudausstattug verfüge modere IDEs über zahlreiche Erweiterugsmöglichkeite mit Hilfe vo Plug-Is. Damit sid IDEs vo Natur aus offee Systeme, a die sich viele adere Tools akoppel lasse: Versiosver waltug, Build- Systeme, Datebake, Applika tios server, Issue-Tracker usw. Allerdigs sid auch hierbei die Möglichkeite beschräkt. Eie durchgägige Traceablitiy vo der Visio bis zum Betrieb ist auch mit eier IDE bislag icht geluge. Zum Beispiel fidet ma kaum Ver biduge (Liks) zwische Quelltexte ud de dazugehörige Aforderuge ud umgekehrt. Für diese Zweck wurde Tools für AML-Komplettlösuge etwi ckelt. Dieser Asatz, Tools aus dem gesamte ALM zusammezuschließe, heißt SLI (Software Lifecycle Itegratio) (vgl. [Tas]). Die große Hersteller habe das Problem erkat ud biete Realisieruge dafür a (siehe Tabelle 3). Ei offesichtlicher Nachteil besteht dari, dass diese Lösuge icht herstellerübergreifed fuktioiere. Das ka sich jedoch och äder: OSLC: 2008 wurde der offee Stadard OSLC (Ope Services for Lifecycle Collaboratio) is Lebe gerufe mit der Zielsetzug, Tools sämtlicher Kategorie ud vor allem auch uterschiedlicher Hersteller auf eifache Weise itegriere zu köe (vgl. [You]). Atlassia: Die Firma Atlassia bietet selbst keie komplette ALM-Lösug a, soder präferiert ei offees Plug- I-Kozept (IDE-ählich). Mittlerweise gibt es eie beträchtliche Azahl (> 600) vo Plug-Is. Auch die Abidug vo Drittabieter-Tools ist bereits weit fortgeschritte. Microsoft: Der Team Foudatio Server zeichet sich ebefalls durch eie große Ausbaustufe der ALM-Komplettlösug aus, allerdigs ur im.net- Umfeld. Die Werkzeugladschaft i der SE Ei Problem ist die kaum überschaubare Auswahl vo Tools ja sogar dere Kategorisierug wächst stetig. Ohe A spruch auf Vollstädigkeit versucht Abbil dug 4, Ordug i die Werkzeug ladschaft zu brige (vgl. auch [Hru12]). Viele Werkzeuge werde zu immer weiter wachsede Tool-Chais kombiiert (vgl. [Wiki-c]). Tabelle 2: Was ist zu beachte, um verstädlich zu implemetiere? 6

5 Itrisische Motivatio stammt zu 100 % aus dem Mesche selbst. Er hadelt, weil sei Hadel für ih eie Selbstzweck hat eifach, weil er es für sich selbst will. Extrisische Motivatio beruht auf Faktore seier Umgebug (Stichwort Zuckerbrot ud Peitsche ). Abb. 4: Übersicht über die Tool-Ladschaft im SEP im weiteste Sie. Mit diese Superwerkzeuge ist zu erwarte, dass der SEP im weiteste Sie deutlich effizieter wird. Wir werde sehe, ob die SLI-Welle wirklich dazu führt. SE-Techike Es gibt verschiedee Kategorie vo SE- Techike: Zum eie Techike für das IT-Maagemet im SEP im weiteste Sie (z.b. [Boh12]), zum adere für das Projektmaagemet (z.b. RUP, XP, Scrum, Kaba, TCC) ud schließlich für de SEP im egste Sie (z.b. OOD, TDD, DDD, BDD). Alle diese Techike werde häufig icht streg formalisiert agewadt. Vielmehr ist es hilfreich, ihre Daseisberechtigug zu verstehe, ihre Vor- ud Nachteile abwäge zu lere ud zu etscheide, welche ihrer Aspekte i welchem Kotext wichtig sid. TCC (Team Clea Codig) ist eie Techik, die wir i Teil 3 dieses Artikels vorstelle werde. Die meschliche Dimesio Motivatio Die vierte Dimesio ist vo spezieller Natur, de hier steht der Faktor Mesch im Mittepukt. Atrieb alle meschliche Hadels ist die Motivatio. Steckt dahiter ur Zuckerbrot ud Peitsche? mierug (für de Kosumete) astrebt. Demetspreched herrschte im Maagemet lage Zeit Eiigkeit darüber, dass Arbeit a sich keie Spaß mache ud die Motivatio, sie zu erledige, folglich äußerer Reize bedürfe (vgl. [Pi10]). So köe der Arbeiter ur durch Belohug (Lob, Boi, Karriere) bzw. Bestrafug (Tadel, Abmahug) zur Ausführug be wegt werde: Zuckerbrot ud Peitsche ebe (vgl. [Wiki-d]). Berufsgruppe wie Küstler ud Wisseschaftler passte icht so recht i dieses Bild, galte aber als Miderheit ud kote so diesem Weltbild ichts ahabe. Das äderte sich spätestes mit dem Auf komme ud der beträchtliche Verbrei tug der Ope-Source-Bewegug. Soft ware etwickler, die uetgeltlich a solche Projekte mitarbeite, stelle beileibe keie Radgruppe dar. Küstler, Wisseschaftler ud Ope-Source-Et wickler sid stark itrisisch (siehe ute) motiviert. Ursprüge vo Motivatio Ihrem Ursprug ach köe zwei Forme vo Motivatio uterschiede werde: itrisisch ud extrisisch (vgl. [Wiki-b]). Eie eue Sichtweise Ei wichtiges Ergebis moderer Forschug lautet, dass der klassische Weg ( Zuckerbrot ud Peitsche ) sich schädlich auf die itrisische Motivatio auswirke ka (vgl. [Pi10]). Werde beispielsweise Boi bzw. Mali ausschließlich uter vorher festgelegte Bediguge vergebe, verschiebt sich das Iteresse vo der Sache a sich schell zur alleiige Frage ach der Belohug bzw. Bestrafug : Ei Homo Oecoomicus ist etstade. Ei Lob, Dak oder Obolus bei guter Arbeit im Nachhiei hat higege stets eie positive Effekt ud passiert leider viel zu selte. Werde Zuckerbrot ud Peitsche schoed eigesetzt, bleibt wahrscheilich die itrisische Motivatio ebe der extrisische erhalte, sodass sie sich sogar gegeseitig ergäze. Motivatiosziele Nebe ihrem Ursprug gehört zu jeder Motivatio auch ihr Ziel. I der SE sehe wir vier Ziele vo Motivatio als grudleged a (siehe Kaste 5). Sie habe userer Meiug ach fudametale Eifluss auf de berufliche Werdegag (siehe auch Abbildug 5): Der Mesch startet eugierig ud uvoreigeomme ud begit zu lere (Phase 1). I dieser Phase ist er i der Regel stark itrisisch motiviert. Nach Jahre itesiver Berufserfah rug maifestiert sich eie Meiugs bildug (Phase 2). Dabei erlebt er, dass Rahmebediguge wie Budget ud Termie oder spezielle Projektsitua tioe (vgl. [Voll] ud Teil 2 dieses Artikels) de Projektalltag stark beeiflusse. Die klassische Sicht Im Zeitalter des Kosums schuf ma de so geate Homo Oecoomicus (vgl. [Wiki-a]): ei Meschebild, das ebe seie Grudtriebe (Huger, Fortpflazug ud soziale Bidug) als weiteres vorherrschedes Ziel die Gewimaximierug (für de Produzete) bzw. die Nutzemaxi Tabelle 3: SLI-Realisierug verschiedeer Hersteller

6 rachläs- de eier ei ie chgeg hat t ei ickler werteier r der it tie- weite-. de ka. Software, die für Edaweder magelde Qualität bescheiigt wird. gedacht ist, muss bei dieser Testart vom Clea Beutzer Codig selbst Cosmos: geprüft werde. Teil 1: Kosmologie Dazu ist es für Last Softwareetwickler ud Performace-Tests otwedig, de fachliche Kotext der zu Die Teststufe Last- ud Performace-Tests prüfede Soft ware zu kee ud eizu- diet im Wesetliche dazu, drei icht- OBJEKTspektrum ist eie Fachpublikatio des Verlags: SIGS DATACOM GmbH Lidlaustraße 2c Troisdorf Tel.: / Fax: / ifo@sigs-datacom.de Ei Teil der Mitarbeiter resigiert mache so stark, dass sich eie Null- Bock-Stimmug maifestiert (Phase 3a). Diese Gruppe ist gar icht mehr motiviert, weder i- och extrisisch. Ei aderer Teil i der Phase 2 bleibt egagiert ud ist vo sich überzeugt, die Lage zu beherrsche. So ket ma Fachlichkeit, Techik, hat vieles gelert ud versucht dogmatisch (zum Teil uerbittlich), mit seie Vorstelluge ud Idee adere zu überzeuge. Für diese Gruppe besteht eie Frustratiosgefahr primär dari, bei de Teammitglieder auf Widerstad zu stoße. Magelde Aerkeug ud eie subjektiv empfudee schlechte Projektsituatio führe häufig zu Resigatio (Phase 3b) häufig verbude mit Zyismus. Eie gute Etwicklug ehme die Mesche, die lere, dass sowohl für de persöliche Erfolg als auch für de des Projekts zwei weitere Motivatioe immer wichtiger werde: Die Motivatio zu kommuiziere ud die, über sich selbst zu reflektiere. Zusamme führe sie zur agostisch-pragmatische Phase (vgl. [Li10]), i der eie Lösug icht ur techisch pragmatisch, soder auch psychologisch pragmatisch gefude wird (Phase 3c). I diesem Stadium hat der Etwickler Folgedes erkat: Bei hireicheder Komplexität gibt es die eizig richtige Lösuge icht, weil fast alles Vor- ud Nachteile hat. Literatur & Liks [Ale04] A. Alexadrescu, H. Sutter, C++ Codig Stadards: 101 Rules, Guidelies, ad Best Practices, Addiso-Wesley Professioal 2004 [All02] E. Alle, Bug Patters i Java, Apress 2002 [Bec02] K. Beck, Test Drive Developmet: By Example, Addiso-Wesley Professioal 2002 [Blo08] J. Bloch, Effective Java: A Programmig Laguage Guide, Addiso-Wesley Professioal 2008 [Boh12] M. Bohle, Softwarearchitektur auf die schlake Art, Amazo Media, Oktober 2012 [Cle] Clea Code Developer, Die Clea Code Developer Grade, siehe: [Dev08] DevAdvice.com, C# Nuggets, 2008, siehe: [Fea11] M.C. Feathers, Effektives Arbeite mit Legacy Code, mitp 2011 [Fow99] M. Fowler, Refactorig: Improvig the Desig of Existig Code, Addiso-Wesley Logma 1999 [Fre10] S. Freema, N. Pryce, Growig Object-Orieted Software, Guided By Tests, Addiso-Wesley Professioal 2010 [Hru12] P. Hruschka, G. Starke, Kolume: Kigge für Softwarearchitekte, i: Javamagazi 11/2012 [Ko12] K. Koerschild, Java Applicatio Architecture: Modularity Patters with Examples Usig OSGi, Addiso Wesley 2012 [Li10] J. Lid, A. Kecht, Der Weg zur Erleuchtug: Utersuchug zur Otogeese des Software-Architekte, i: OBJEKTspektrum 3/2010 [Ma04] T. Majaly, C# Codig Stadards ad Best Programmig Practices, 2004, siehe: [Mar08] R.C. Marti, Clea Code: A Hadbook of Agile Software Craftsmaship, Pretice Hall 2008 [sz10] sz, Dark side of C++, 2010, siehe: [Par72] D.L. Paras, O the Criteria To Be Used i Decompsitio Systems ito Modules, Caregie-Mello Uiversity, Dezember 1972, Vol 15, No 12 [Pi10] D.H. Pik, Drive: Was sie wirklich motiviert, Ecowi Verlag 2010 [Rup09] C. Rupp & die SOPHISTe, Requiremets-Egieerig ud -Maagemet, Carl Haser Verlag 2009 (5. Auflage) [Rup10] C. Rupp, R. Joppich, C. Wüch, Molekulares Requiremets-Egieerig (M-RE) Der Baupla eier perfekte Aforderug, 2010, siehe: [Sch11] H. Schaefer, Illusios about software testig, 2011, siehe: about software testig_has Schaefer.pdf [Sta09] G. Starke, Effiziete Software Architekture. Ei praktischer Leitfade, Carl Haser Verlag 2009 [Tas] Tasktop Techologies, Software Lifecycle Igegratio, siehe: [Voll] Iformatikbüro Jörg Vollmer, Umfrage Was stört Sie im IT-Alltag am meiste?, siehe: [Wiki-a] Wikipedia, Homo oecoomicus, siehe: [Wiki-b] Wikipedia, Motivatio, siehe: [Wiki-c] Wikipedia, Toolchai, siehe: [Wiki-d] Wikipedia, Zuckerbrot ud Peitsche, siehe: [Wil12] A. Willert, Applicatio Lifecycle Maagemet Tool oder Vorgehe?, i: OBJEKTspektrum Soderbeilage CALM, Witer 2012, siehe: [You] Youtube, Ope Services for Lifecycle Collaboratio (OSLC), siehe 8

7 Motivatio, besser zu werde, z. B.: Suche ud lese. Rede ud zuhöre Taguge, Fortbilduge ud Vera stal tuge besuche. Ausprobiere ud teste. Motivatio, zu kommuiziere, z. B.: Sich präzise ausdrücke ud aktiv zuhöre. Fremde Meiuge akzeptiere lere. Helfe beim Eirichte ud Verbesser vo Prozesse. Motivatio, veratwortugsvoll zu hadel, z.b.: Kosequet Regel ud Prozesse eihalte. Mitdeke ud hiterfrage. Der Sache auf de Grud gehe. Abb. 5: Phase im berufliche Werdegag vo Mesche, die mit komplexe Systeme arbeite (vgl. [Li10]). Motivatio, über sich selbst zu reflektiere, z. B.: Ist meie Meiug für adere achvollziehbar? Ist mei Verhalte für adere akzeptabel? Kaste 5: Grudlegede Ziele vo Motivatio i der SE. Adere Meiuge sid zu toleriere, selbst we ma selbst überzeugt ist, eie bessere Lösug gefude zu habe. Nachhaltig gute Lösuge lasse sich meist ur uter Berücksichtigug vieler Eiflussfaktore (d. h. mit viel Kommuikatio) ermittel. Veräderuge werde am effektivste mit der Uterstützug vo Gleichgesi te erreicht (d. h. mit viel Kommuikatio). Das gezielte Vermeide vo Kommuikatio stellt eie große Gefahr für Ieffiziez ud Uproduktivität dar ud ka zu große wirtschaftliche Schäde führe. Fazit I der Naturwisseschaft ist die Suche ach der Grad Uified Theory (der Weltformel) gescheitert. Die Weltformel liegt wohl auch außerhalb der meschliche Möglichkeite. Gleiches köe wir auch für die kosmologische Weltformel der SE aehme, de die Kräfte, die i de verschiedee Dimesioe herrsche, sid zu verschiede, um sie zu vereiheitliche. Deshalb suche wir i der SE icht ach dem allgemeigültig richtige Weg. Stattdesse halte wir es für wichtig, de Überblick zu erlage ud zu bewahre, welche Eiflussfaktore die tägliche Arbeit i der SE bestimme. Diese Eiflussgröße lasse Die Autore sich i vier verschiedee Dime sioe eiorde: Klar defiierte, rudlaufede Prozesse, brei tes ud tiefes techisches Wisse, gute had werkliche Fertigkeite im Umgag mit Tools ud Techike sowie positiv motivierte Team mitglieder: Wer i alle vier Dimesio e seie Kräfte ausgewoge eizusetze vermag, wird die Materie Software erfolgreich for me ud davo auch persölich profitiere. Im zweite Teil dieses Artikels möchte wir zeige, wie die Raumzeit der SE durch Soft wareschmutz gekrümmt ud verboge wird. Hier agelagt weitet sich der Blick, der da die Perspektive uterschiedlicher Stakeholder eischließt. Ohe Dogma- Fessel köe Etscheiduge gefude werde, die eie breitere Akzeptaz fide. Kaste 5 soll helfe, diese Etwicklugsstufe, die wir mit diesem Artikel zur Diskussio stelle, zu erreiche. Dr. Reik Oberrath (R.Oberrath@iks-gmbh.com) ist als IT-Berater bei der iks Gesellschaft für Iformatios- ud Kommuikatiossysteme tätig. Er beschäftigt sich seit viele Jahre mit der Etwicklug vo idividuelle Geschäftsaweduge ud mit der Architektur kompoetebasierter Systeme. Jörg Vollmer (ifo@iformatikbuero.com) ist freiberuflicher IT-Berater ud verfügt über lagjährige Erfahrug als Etwickler, Softwarearchitekt ud Traier im Java-Umfeld, speziell Java EE ud Sprig. Seie Leideschaft gehört dem Vermittel vo Software-Qualitätsbewusstsei

8 Clea Codig Cosmos: Teil 2: Kosmologische Suche ach Softwareetwicklugsschmutz Clea Codig Cosmos: Teil 2: Kosmologische Suche ach Softwareetwicklugsschmutz Aalysiert ma modere Quellcode, fidet ei kudiger Leser dort reichlich Schmutz. Die uterschiedliche Arte vo Schmutz im Code lasse die Urheber (us eigeschlosse) ufähig, faul oder feige erscheie. Werde Softwareautore direkt befragt, was ihe i ihrem Alltag Probleme bereitet, ee sie eie Reihe vo Schwierigkeite, die ihre Arbeit wesetlich beeiträchtige. Ob Codeaalyse oder Programmierer-Befragug, die Grüde sid sehr uterschiedlich ud betreffe alle Dimesioe des Etwicklerkosmos, die wir i Teil 1 dieses Artikels i der letzte Ausgabe vo OBJEKTspektrum vorgestellt habe. Wir wolle Licht auf diese dukle Materie i userem Etwicklerkosmos werfe, um zu lere, wora ma Schmutz erket ud wie ma ih beseitigt oder gar vermeidet. Schmutz will keier habe, clea soll alles sei. Aber was bedeutet diese Metapher i der Softwareetwicklug (SE)? Software hat zwei sehr uterschiedliche Aspekte, die beide gleich wichtig sid (siehe Kaste 1, Iere ud äußere Softwarequalität ). Für beide Aspekte gilt: Schmutz ist das, was Ieffiziez verursacht (siehe Kaste 2). Schmutz ist die dukle Materie im Etwicklerkosmos ud, ebeso wie die physikalische Materie durch Masseaziehug vo selbst akkumuliert, reichert sich i der SE Schmutz ascheied vo allei immer mehr a. Der Schmutz verzerrt die Raumzeit ud wirkt auf alle Dimesioe. Die Akteure der SE müsse regelmäßig Eergie aufbrige, um sich vor eiem Übermaß a Schmutz zu schütze ud ei gesudes Maß a Sauberkeit zu bewahre (siehe Abbildug 1). Um Schmutz zu erkee oder ih gar zu vermeide, stelle wir i diesem Artikel zum eie typische techologie- ud sprachuabhägige Ati-Patters vor (Schmutz im Code bzw. im Produkt). Zum adere präsetiere wir die Ergebisse eier Umfrage, was Softwareetwickler bei ihrer Arbeit am meiste behidert (Schmutz im SE-Alltag bzw. im Prozess). Softwareetwicklugsprozess (SEP) Der SEP schließt die Implemetierug sowie die adere Aufgabe im Etwickleralltag mit ei, z.b. Aforderugsaalyse, Qualitätssicherug ud Ibetriebahme (vgl. auch Kaste 1 i [Obe13]). Iere ud äußere Softwarequalität Äußere Qualität ist vom Aweder sichtbar (z.b. Fuktioalität), iere Qualität ist ur für de Isider ersichtlich (Qualität des SEP, Codequalität). Iere ud äußere Qualität müsse ausgewoge, d.h. aufeiader abgestimmt sei (vgl. Eisberg-Metapher i Abbildug 1 i [Obe13]). Dimesio Die Dimesio ist ei Typ vo Eigeschafte, welche die Softwareetwicklug prägt: Prozess: Zeitliche Dimesio, die Abläufe ud Aktioskette thematisiert. Hadwerk: Praktische Dimesio, die Fertigkeite i der Awedug vo Tools ud Softwareetwicklugstechike thematisiert. Wisse: Techische Dimesio, welche die SE-Theorie thematisiert. Dazu zähle z.b. Ketisse i Programmiersprache, Modellierug, Datebakdesig ud Softwarearchitektur. Motivatio: Meschliche Dimesio, die das Wolle der Akteure thematisiert. Kaste 1: I Teil 1 vo Clea Codig Cosmos ([Obe13]) eigeführte Begriffe. Schmutz ist alles, was die SE verzögert ud ihre Akteure behidert, z. B. uverstädliche Dokumete oder uklare Prozesse. Schmutz fidet sich i alle vier Dimesioe des Etwicklerkosmos wieder (vgl. [Obe13]). Schmutz äußert sich dari, dass er eie Akteur bei seier Arbeit stört. Aber icht alles Störede ist Schmutz. Nebe Schmutz stört auch, was de persöliche Vorliebe der Akteure widerspricht. Dazwische zu uterscheide, ist oft sehr schwer. Schmutz ist ach Abwäge aller Vor- ud Nachteile deoch eiigermaße objektiv begrüdbar. Kaste 2: Was ist Schmutz ud was keier? Dirty-Code Erschrocke betrachtet auch der erfahree Etwickler Programm-Code, de er vor Moate selbst geschriebe hat, ud fragt sich: War ich damals eigetlich ufähig, oder eifach ur zu faul oder gar zu feige, das sauber zu mache? Dirty-Code äußert sich durch Schmerze bei der Wartug (siehe Kaste 3). Typische Symptome sid lagwierige Fehleraalyse, aufwädige Umbaumaßahme, ugewollte Seiteeffekte bei Codeäderuge ud Mägel i de icht-fuktioale Qualitätsmerkmale, wie Stabilität, Äderbarkeit ud Testbarkeit. Kokrete Idizie im Code sid uter aderem: Codeverdoppluge Uverstädlicher Code (upassede Bezeicher, große Klasse, zu lage Methode, große Verschachtelugstiefe) Uvollstädige Implemetierug (bezüglich Fehlerbehadlug, Refactorig, Loggig usw.) Uötig komplexe Implemetierug Toter Code (Zu) starke Koppluge zwische Klasse ud Module Vermischug vo Belage ud Veratwortlichkeite Fehlede Tests, magelde Testabdeckug Magelde Automatisierug (Build, Auslieferug usw.) 10

9 Code ist wartbar, we er folgede Eigeschafte besitzt: gut verstädlich leicht äderbar eifach testbar Abb. 1: Lebede Orgaisme wie Kühe ud Software zeiche sich durch Stoffwechsel aus: Stoffaufahme, Verarbeitug ud Ausscheidug. Fuktioiert die Ausscheidug schlecht, reicher sich Schadstoffe a. Dauert diese Areicherug a, kommt es schließlich zu Schmerze, Orgaausfall oder gar zum Tod des Orgaismus. Eie gute Ausscheidug erreicht keie perfekte Sauberkeit (Sterilität), soder stellt ei Fließgleichgewicht ei, bei dem die Verschmutzug auf eiem maßvolle, gesude Niveau gehalte wird. Verstädlicher Code macht es möglich, schell ud präzise die Stelle zu fide, die für eie Implemetierugsaufgabe geädert werde müsse. Leicht äderbarer Code erlaubt es, Erweiteruge ohe große Umbau der bestehede Implemetierug realisiere zu köe. Eifach testbarer Code ermöglicht es, mit weig Aufwad sicherzustelle, dass keie uerwüschte Seiteeffekte auftrete. Jede Verletzug dieser drei Aspekte behidert die Wartug ud lähmt die SE. Weig wird über die Ursache vo Dirty- Code diskutiert ud och weiger über Prävetio. Dieser Abschitt widmet sich vorragig diese Theme. Abbildug 2 zeigt die Übersicht über die im Folgede agesprochee Ursache. Kaste 3: Was ist wartbarer Code? Fallbeispiel Ei Mitarbeiter kommt i ei eues Projekt. Er erhält zum Eistieg eie kleie Aufgabe als Möglichkeit, Software, Tools ud Ifrastruktur keezulere. Wie wird der Etwickler vorgehe? Utersucht er bestehede Code dahigehed, ob ähliche Aufgabe bereits gelöst wurde ud Lösugsstrategie überomme werde köe? Sucht er ach Tests? Ar Abb. 2: Diagose ud Therapie vo sprach- ud techologie-uabhägigem Dirty-Code: Die Zusammehäge zwische de Idizie, de Ursache ud Gegemaßahme sid vielfältig. Aus Grüde der Übersichtlichkeit sid die Beziehuge exemplarisch ur für ei Idiz eigezeichet

10 Clea Codig Cosmos: Teil 2: Kosmologische Suche ach Softwareetwicklugsschmutz Als Atwort auf schell wechselde Aforderuge wurde die agile Methode etwickelt (vgl. [Bec01], [Coh04]). Doch auch die agile Methode stehe im Verdacht, zum Softwareschmutz beizutrage (Kapitel 3 i [Kor13]). Beispielsweise ka der Zwag, bei jedem Sprit auslieferugsfähige Software zu erzeuge, Termidruck ud damit Softwareschmutz verursache (siehe 7. Termidruck ). Doch die Kombiatio vo agile Methode ud Clea-Code-Prizipie verspricht, diese egative Aspekte auszugleiche (vgl. [Ble13], [Wes12]). Kaste 4: Agile SE-Methode. Abb. 3: Was ka ud was soll die DoD beihalte? Die Meiuge gehe dabei oft auseiader. Reiche Uit-Tests? Müsse Code-Aalyse sei? Clea Codig (TCC) vor. Diese Methode soll Eiigug ud Eihaltug gewährleiste. beitet er Test-First? Vermutlich icht. Ei Großteil der Etwickler wird wahrscheilich versuche, diese Aufgabe möglichst schell zu erledige, um das eigee Köe ud seie Wert für die Firma uter Beweis zu stelle. Da ka er mit Stolz verküde: Fertig! Aber was bedeutet es geau, fertig zu sei? Wie sieht die DoD de aus? 1. Defiitio of Doe (DoD) Die so geate Defiitio of Doe ist ei wesetlicher Bestadteil, Softwarequalität sicherzustelle. Was zur DoD gehöre ka, zeigt Abbildug 3. Das Fehle der DoD ka Koflikte ierhalb des Teams ach sich ziehe, de Etwickler habe uterschiedliche Vorstelluge vo fertig. Gegemaßahme sid: DoD möglichst frühzeitig kläre. DoD alle Etwickler deutlich mache. Eihaltug prüfe. Sowohl die Eiigug auf eie DoD als auch ihre Eihaltug stelle ei wesetliches Problem im SEP dar. I Teil 3 dieses Artikels i OBJEKTspektrum stelle wir das Team 2. Die Gas-Fabrik Ispiriert vo der Komplexität eier echte idustrielle Gasfabrik steht der Begriff i der SE für eie übertriebe komplexe Lösug. Ei Motiv ist typischerweise ugezügelte Neugierde. Nicht selte wird eie kleie Erweiterug zum Alass geomme, ei eues Framework oder Patter auszuprobiere. Ei aderes Motiv ist die zu hohe Priorisierug vo Kofigurierbarkeit ud Erweiterbarkeit: Eie geerische ud a jede Situatio apassbare Lösug erfordert i der Regel eie uötig komplexe Implemetierug. Gegemaßahme sid: Folgede Clea-Code-Developer-Regel etabliere: KISS (vgl. [CCD1]), Vorsicht vor Optimieruge (vgl. [CCD2]) ud YAGNI (vgl. [CCD3]). Eihaltug der Regel prüfe: Code- Reviews durchführe (vgl. [CCD4]) Abb. 4a: Kräftedreick aus Koste, Termie ud Qualität. Sollte die Termie bei gleiche Koste schwerer wiege, würde die Qualität leide. 4b: Iere ud äußere Qualität sid gleich wichtig (vgl. Kaste 1). Allerdigs wird i der Regel die äußere Qualität (z.b. Fuktioalität) bei gleiche Termie ud Koste schwerer gewichtet als die iere (z.b. Wartbarkeit), woruter letztere ud damit die SE-Effiziez der folgede Etwicklugsphase leidet (siehe Abb. 5). 3. Die x-te Äderug/schell wechselde Aforderuge Der Projektalltag ist geprägt vo städig wechselde Aforderuge. Folglich sid Situatioe, i dee Codeteile stark umgebaut oder gar verworfe werde, icht ausgeschlosse. Das drückt die Motivatio, vollstädig sauber zu arbeite, weil ugewiss ist, ob die aktuelle Versio icht abermals überarbeitet oder verworfe werde muss. Siehe dazu auch ute im Abschitt Rahmebediguge. Gegemaßahme sid: Betreffede Codestelle mit eiem spezielle Kommetar markiere ud 12

11 Schätzfehler i der Softwareetwicklug sid eie häufige Ursache für falsche Projektplaug (vgl. Estimatio i [Mar11]) ud für uötige Zeitdruck (vgl. Time Maagemet i [Mar11]): 1. Komplexe (Software-)Systeme sid uberechebar. Stelleweise wird die Materie umso komplizierter, je tiefer ma i sie eidrigt, ud die Wechselwirkuge ihrer Bausteie etziehe sich eier präzise Vorhersagbarkeit (vgl. [Roy04]). Ohe Berücksichtigug dieser Zusatzaufwäde (siehe Pukt 2) falle regelmäßig deutliche ugeplate Mehraufwäde a. 2. Der Mesch schätzt psychologisch eher de für ih wahrscheilichste als de (höhere) durchschittlich zu erwartede Aufwad (siehe Abbildug 6). Das heißt, die i Pukt 1 geate Ausahmefälle, die sehr viel läger beötige als erwartet, fließe i die persöliche Schätzug icht mit dem richtige Gewicht ei. 3. Projektmaager trage die Veratwortug für kurzfristige Ziele. Sie werde a der zeitliche Eihaltug vo Termie gemesse. Folglich werde Etwickler (seites des Maagemets) für Geschwidigkeit ud weiger für Sorgfalt beloht. 4. Etwickler eige dazu, scho währed der Schätzug mit kurze Fertigstellugszeite Koflikte mit dem PM ausweiche oder damit beeidrucke zu wolle. 5. Eiige Ursache sid orgaisatorischer oder politischer Art. Ugüstige Projektfaktore (siehe ute Rahmebediguge ) verzöger häufig uerwartet die techische Umsetzug wege beötigter, aber icht rechtzeitig zur Verfügug gestellter Ressource: Hardware, Software, Mapower. Kaste 5: Schätzfehler bei Aufwadsabschätzuge. kosequet diese Markieruge prüfe (siehe Code-Taggig-System i der ächste Ausgabe vo OBJEKTspektrum). Agile SE-Methode awede (aber siehe Kaste 4). Frusttoleraz stärke (z.b. mit eiem gute Stück Schokolade). 4. Broke Widows Dieser Begriff steht ursprüglich für ei i der Krimialistik beschriebees Phäome ud besagt, dass ei kleier ubehadelter Schade (z.b. eie zerschlagee Scheibe eies Gebäudes) zur weitere Zerstörug eilädt ud letztlich zu völliger Verwahrlosug führt (vgl. [Wiki1]). I der IT ist diese Erscheiug auch bekat uter dem Name Software- Etropie (vgl. [Wiki2]): Je weiter die Verrottug (z.b. eier Klasse) fortgeschritte ist, desto astregeder wird es, sich dort hieizudeke, ud desto mehr läuft ma Gefahr, Workarouds zu programmiere, astatt eimal grüdlich aufzuräume. Damit aber wird das gaze Gebilde och uverstädlicher. Gegemaßahme sid: Kosequet Pfadfider-Regel awede (vgl. [CCD5]). Regelmäßig Refactorig-Maßahme durchführe (vgl. [CCD6], [CCD7]). 5. Koformitätsbrüche Ei Koformitätsbruch liegt da vor, we der Code plötzlich vo eiem regelmäßige Implemetierugsschema abweicht. Beispiel: Für eie Teil der Busiessobjekte wurde zur Datespeicherug Library A verwedet, für de adere Library B. Die Folge ist, dass ei weiterer Etwickler später eie uötige Teil seier Zeit damit verbrigt, ach dem Grud der Abweichug zu suche, ud sich i zwei Lösugswege für das gleiche Problem eiarbeite muss. Eie typische Ursache dafür ist ei uvollstädiges Refactorig, das evetuell aus Zeitot vorzeitig beedet wurde. Eie adere Ursache liegt dari, dass ei Etwickler eie eue Aufgabe mit eier bereits im Code umgesetzte Lösug realisiere köte, diese aber gar icht ket (magelde Kommuikatio) oder sogar glaubt, sie aders besser löse zu köe (Profilierugseigug). Gegemaßahme sid: Code-Review oder Pair-Programmig: Gemeisam etscheide, ob eie eue Lösug etabliert werde soll. Vollstädiges Refactorig: Alle Stelle umbaue, we eie eue Lösug etabliert wird. Abb. 5: Techischer Kredit: Techische Schulde (vgl. [Wiki4]) köe i eier heiße Phase zu Guste der Koste ud Termie aber zu Laste der Qualität bewusst eigegage werde. Das ka verdeckt geschehe (ur Schulde a die iere Qualität) oder sichtbar für de Kude ud die Aweder (Schulde a die äußere Qualität). Alle Schulde müsse aber i der Folgephase bewusst wieder begliche werde. Asoste droht Orgaausfall (siehe Abbildug 1) bzw. der Utergag des Eisbergs Software (vgl. Abbildug 1 i [Obe13]). 6. Ueiigkeit im Team Es gibt viel Literatur zu de so geate Soft Skills (vgl. [Sch10]). Soft Skills habe eie große Eifluss auf die Effiziez des SEP, de persöliche Eigeheite vo Teammitglieder köe die Stimmug im Team belaste, die Kommuikatio eischräke

12 Clea Codig Cosmos: Teil 2: Kosmologische Suche ach Softwareetwicklugsschmutz Mehr Motivatio, Veratwortug zu überehme (sich zu kümmer). Mehr Motivatio, Neues zu lere ud auszuprobiere. Abb. 6: Ihäreter Fehler bei der Aufwadsschätzug: Typischerweise schätze Etwickler de für sie wahrscheilichste Aufwad, de so geate Modus (vgl. [Wiki5]). Für die Projektplaug ist aber ei aderer Schätzwert vo größerer Bedeutug, der die weiger wahrscheiliche hohe Werte auch berücksichtigt, der Erwartugswert (vgl. [Wiki6]). ud für Ueiigkeit sorge. I solche Situatio arbeitet jeder für sich allei, sodass gemeisame Idee vo Lösuge icht existiere ud Wildwuchs im Code etsteht. Gegemaßahme sid: Mehr Mut, sich ehrlich selbst zu reflektiere. Mehr Mut, mit adere i Kommuikatio zu trete. 7. Termidruck Als Hauptgrud vo Dirty-Code wird vo Etwickler eigetlich immer als erstes Termidruck geat. I der Tat ka dieser große Probleme aufwerfe. Das Kräftedreieck i Abbildug 4 zeigt, dass die Faktore Koste, Termie ud (äußere ud iere) Qualität miteiader i eiem kokurrierede Zusammehag stehe. Bei der dort abgebildete Waage hat ei Druck auf de Termi bei gleichbleibede Koste stets eie egative Eifluss auf die Softwarequalität ud zwar i der Regel auf die iere Qualität (siehe Kaste 1). Magelde iere Qualität beeiträchtigt Merkmale wie Aalysierbarkeit, Äderbarkeit ud Testbarkeit ud lähmt deshalb lagfristig die Effiziez der SE (siehe auch ute, Abschitt Projekt-Maagemet ). Gegemaßame sid: Tabelle 1: Ergebis der Umfrage uter (Stad vom mit 142 Teilehmer). Jeder Teilehmer kote bis zu 5 Probleme akreuze, die ih am meiste behider. Die Prozetwerte gebe de Ateil der Persoe a, die dieses Problem agekreuzt habe. Probleme mit weiger als 3% sid hier icht aufgeführt. Alle Probleme sid eiem oder mehrere vo sechs Problemtype zugeordet (siehe Tabelle 2). 14

13 Ei SE-Projekt muss i mehrfacher Hisicht betreut werde: Techisch: Architektur u. a. Fachlich: Aforderuge Fiaziell: Budget, Zeit, Qualität Persoell: Teamstimmug u. a. Orgaisatorisch: Prozesstreue, Ifrastruktur u. a. Tabelle 2: Kategorisierug der Umfrageergebisse vo Tabelle 1, wobei pro Problemtyp die relative Azahl der Kreuze i Prozet agegebe ist. Es gibt verschiedee Strategie diese Veratwortlichkeite zu verteile. Im klassische PM fidet ma die Strategie, die Veratwortlichkeite i möglichst weige Persoe zu vereie (z.b. i der eies Projektleiters). Scrum mit seier agile Vorgehesweise beihaltet die Strategie, diese Veratwortlichkeite aufzuteile. Hier liegt die techische Veratwortug beim Etwicklerteam, die fachliche ud fiazielle beim Product Ower, die persoelle ud orgaisatorische Veratwortug beim Scrum Master. Uabhägig vo der Strategie besteht die wesetliche Aufgabe des PM dari, de Rahme des Projekts gegeüber der Etwicklug, de Geldgeber ud der Fachseite zu defiiere ud zu gewährleiste. Kaste 6: Aufgabe des PM. Veratwortug für die iere Softwarequalität überehme ud seiem Berufsethos (de Clea-Codig-Regel) treu bleibe. Termidruck durch realistische Aufwadsschätzuge (siehe Kaste 5) reduziere. I Ausahmefälle ka ei techischer Kredit aufgeomme werde (siehe Abbildug 5). Frusttoleraz stärke (diesmal vielleicht mit frischer Luft bei eiem kleie Spaziergag) Schmutz im SE-Alltag Die Ergebisse zur Umfrage, was Softwareetwickler i ihrem Alltag am meiste behidert, zeigt Tabelle 1. Die Atworte beziehe sich icht ur auf de Code, soder auf de gesamte SEP. Sie lasse sich i sechs Problemtype eiteile: 1. Requiremets Egieerig (RE) RE steht icht zu Urecht auf Platz 1 vo Tabelle 1 ud auf Platz 2 vo Tabelle 2, de falls Etwickler icht ausreiched mit richtige Aforderuge versorgt werde, führt dies zu Schmutz, der die Softwareetwicklug lahmlege ka. Aber wie ist der große Abstad zu de adere Pukte zu erkläre? Ursache für RE-Probleme köe i alle Dimesioe liege: Prozess: Gibt es Akteure im Projekt mit der alleiige Aufgabe, Etwickler mit Aforderuge zu versorge? Wir meie: Nei, i viele Projekte icht. Wisse: Sid diese Akteure RE-Spezialiste? Gibt es Best Practices ud werde diese agewedet? Wir meie: Nei, i viele Projekte icht. Hadwerk: Sid die verwedete Tools leistugsstark geug ud werde sie sivoll eigesetzt? Wir meie: Nei, i viele Projekte werde ur Office- Programme verwedet. Versioierug, Strukturierug, gute Suchfuktioe, Traceability ud die Verwaltug vo Metaiformatioe fehle. Motivatio: Ist bei alle Akteure wirklich der Wille da, sauber zu arbeite? Stimmt die Kommuikatio mit der Fachseite ud habe die Stakeholder dort geug Zeit, ausreiched fachliche Iput zu liefer? Wir meie: Nei, i viele Projekte hat die Fachseite icht geüged Ressource zur Kommuikatio mit der Etwicklug. Alle Dimesioe müsse clea sei, damit das RE ud damit der SEP effiziet laufe. Aber i alle Dimesioe gibt es och viel Verbesserugspotezial. Aus diesem Grud ist der hohe Abstad der RE zu de adere Probleme i Tabelle 1 durchaus verstädlich. 2. Projektmaagemet (PM) Ei Softwareetwickler braucht für seie Arbeit ei hohes Maß a Kreativität. Mache Etwickler betrachte sich deshalb eher als Küstler. Derjeige Akteur, der als Nicht- Etwickler am meiste mit ihm zusammearbeitet, ist der Projektmaager bzw. das PM (siehe Kaste 6). Immer wieder schräkt das PM de Spielraum des Etwicklers ei ud hat daher bei viele Etwickler ei schlechtes Image. Doch auch aus adere Grüde fide sich vier PM-Probleme uter de Top 10 i Tabelle 1. Ei typischer Grud für Eischräkuge ist Termidruck (siehe obe), der im Iteresseskoflikt zwische Etwicklug ud Vertrieb begrüdet liegt. Zusamme mit de Etwickler sollte der Projektmaager oder gegebeefalls der Etwicklugsleiter gemeisam dafür kämpfe, dass geüged Zeit zur Verfügug steht. Urealistische Aufwadsabschätzuge sid hier der größte Feid (siehe Kaste 5). Als Etwickler scheut ma davor, Aufwadszahle Grudsätzlich köe Koflikte auf zwei Arte gelöst werde: Fight or Flight, zwei Strategie, welche die Psychologie us lehrt (vgl. [Wiki7]). Fight bedeutet hier aber keie Aggressio, soder eie aktive, kostruktive Problemlösug durch Kommuikatio oder im Fall vo Kommuikatiosprobleme durch Meta-Kommuikatio (vgl. [Sch10]). Flight bedeutet hier keie Kommuikatiosverweigerug, soder die dauerhafte Treug der Kofliktparter, zum Beispiel durch Projektwechsel eies Beteiligte. Nebe diese beide aktive Reaktiosmöglichkeite ist es auch möglich, ichts zu tu, abzuwarte, die Frusttoleraz zu stärke ud durchzuhalte. Dauerhaft geht das aber ur, we der dabei empfudee Disstress icht zu groß ist. Asoste besteht die große Gefahr zu resigiere (siehe Abbildug 5 i [Obe13]). Kaste 7: Möglichkeite, mit Koflikte umzugehe

14 Clea Codig Cosmos: Teil 2: Kosmologische Suche ach Softwareetwicklugsschmutz zu ee, die im PM uwillkomme sid. Das geschieht aus magelder Erfahrug, aus magelder Motivatio zur Aufwadsaalyse oder aus mageldem Mut, Zahle zu ee, die Stress verursache (siehe Kaste 7). Etwickler sollte sich stets ehrlich bemühe, realistische Aufwäde zu schätze, ud Projektmaager ei Eisehe habe, diese zu akzeptiere. Gutes Projektmaagemet äußert sich dari, dass icht ur kurzfristige Ziele (siehe Kaste 5) soder auch lagfristige verfolgt werde. Da köe ämlich Etwickler ud Projektmaager zusamme eie Weg suche, eie Rahme zu schaffe, i dem die Etwickler sauber arbeite köe: eie Clea Codig Cosmos. Aber es gibt auch schlechtes PM. Hier helfe kei Mecker ud Klage, soder die Motivatio, diplomatisch zu kommuiziere: Feedback gebe ud kostruktive Kritik äußer (siehe Kaste 7). 3. Techische SEP-Schwäche Es gibt eie Reihe vo techische Probleme im SEP (siehe Tabelle 1). Zusamme köe sie mit 18,2 Prozet aller Probleme i Zusammehag gebracht werde (siehe Tabelle 2). Auch die Ursache vo techische Probleme köe i alle Dimesioe liege: Prozess: Sid Qualitätssicherugsmaßahme gut im SEP itegriert? Wisse: Ist das Kow-how vorhade, wie Architektur, Implemetierug, Build, Release ud Qualitätssicherug sauber realisiert werde? Hadwerk: Sid die richtige Tools im Eisatz? Werde sie effiziet eigesetzt? Werde Softwareetwicklugstechike (z. B. Domai Drive Desig (DDD), Test Drive Developmet (TDD)) agewadt? Motivatio: Sid alle Akteure bereit, Prozesse eizuhalte, sich eues Wisse azueige oder eue Tools ud Techike eizusetze? ke TDD ud TCC (siehe Teil 3 dieses Artikels) awede. Die Dirty-Code-Ati-Patters bewusst vermeide De Eisatz vo CI-Tools (vgl. [Pal04]) im Prozess veraker. 4. Kommuikatio Kommuikatiosprobleme sid häufig. Zwei habe es i die Top 10 i Tabelle 1 geschafft ud fast jeder zehte Etwickler gab Kommuikatiosprobleme a (siehe Tabelle 2). Dabei gibt es drei typische Fehler: Erstes zu weig, zweites zu viel uötige, ud drittes otwedige, aber ieffektive Kommuikatio. Wie bei alle Koflikte gibt es verschiedee Möglichkeite, damit umzugehe (siehe Kaste 7). Wie eie sivolle Kommuikatio im Projektalltag gestaltet werde ka, stelle wir i Teil 3 dieses Artikels dar. Das Kommuikatiosvermöge eies Mesche hat mehrere Aspekte: Fehlede oder vorhadee atürliche Begabug. Erlerbares Kommuikatiosgeschick. Die persöliche Beziehug zu dem Kommuikatiosparter. Atipathie zwische de Beteiligte ka die Kommuikatio ud damit die Softwareetwicklug drastisch lähme. Durch gezieltes Traiig ud spezielle Kommuikatiosprozesse (vgl. [Sch10]) köe Kommuikatiosprobleme abgeschwächt oder sogar gelöst werde. Die Autore 5. Rahmebediguge I jedem Projekt gibt es zwei Sorte vo Rahmebediguge, welche die Arbeit der Akteure erschwere: Ugüstige Naturkostate ud ugüstige Projektfaktore. Zu de Naturkostate zähle Termidruck ud schell wechselde Aforderuge. Sie trete immer auf, auch we iemad etwas falsch macht (vgl. auch The Ucertaity Priciple, [Mar11]). Nicht ohe Grud ragiere sie i de Umfrageergebisse i de Top 5 (siehe Tabelle 1). Ugüstige Projektfaktore sid z.b. starre Orgaisatiosstrukture, Teamzusammesetzug, räumliche Aufteilug des Teams, dauerhafter Maagemetdruck für höhere Etwicklerleistug sowie magelde Fortbildugsmöglichkeite. Sie trete icht immer auf, aber we sie existiere, sid sie oft schmerzhaft ud ebefalls kaum äderbar ud we, da ur mittels Kommuikatio. 6. Teamstimmug Zwischemeschliche Probleme köe ebefalls Effiziezkiller darstelle. Allerdigs ist das eher selte (siehe Tabelle 2). Ueiigkeit bei Etscheiduge, Schwäche eizeler Mitglieder, welche die Zusammearbeit belaste, oder mageldes Iteresse a der eigee Arbeit ( ist doch egal, wie ich das mache, schaut sich ja sowieso keier a ) drücke häufig die Motivatio der Mitarbeiter ud damit die Effiziez der Softwareetwicklug. Hizu komme vielleicht auch ugüstige Rahmebediguge. Mehr als jeder vierte Teilehmer der Umfrage gab a, dass fehlede Tests ei Problem sid. Mehr als jeder füfte Teilehmer gab a, dass auch uwartbarer Code ei Problem ist. Deshalb gebe wir folgede Empfehluge: Mit de Regel der Clea Code Developer etwickel ud die beide Techi Dr. Reik Oberrath (R.Oberrath@iks-gmbh.com) ist als IT-Berater bei der iks Gesellschaft für Iformatios- ud Kommuikatiossysteme tätig. Er beschäftigt sich seit viele Jahre mit der Etwicklug vo idividuelle Geschäftsaweduge ud mit der Architektur kompoetebasierter Systeme. Jörg Vollmer (ifo@iformatikbuero.com) ist freiberuflicher IT-Berater ud verfügt über lagjährige Erfahrug als Etwickler, Softwarearchitekt ud Traier im Java-Umfeld, speziell Java EE ud Sprig. Seie Leideschaft gehört dem Vermittel vo Software-Qualitätsbewusstsei. 16

15 Literatur & Liks [Bec01] K. Beck, et al., Maifesto for Agile Software Developmet, 2001, siehe: [Ble13] M. Bless, T. Bührer, Scrum & Clea Code Developmet: Ei perfektes Paar? i: OB JEKTspektrum 5/2013 [CCD1] Clea Code Developer, Roter Grad, siehe: [CCD2] Roter Grad Clea Code Developer, siehe: [CCD3] Blauer Grad Clea Code Developer, siehe: Phttp:// de/blauer-grad.ashx#you_ai%c2%b4t_goa_need_it_yagni_2 [CCD4] Orager Grad Clea Code Developer, siehe: [CCD5] Roter Grad Clea Code Developer, siehe: [CCD6] Roter Grad Clea Code Developer, siehe: Roter-Grad.ashx#Eifache_Refaktorisierugsmuster_awede_7 [CCD7] Gelber Grad Clea Code Developer, siehe: [Coh04] M. Coh, User Stories Applied: For Agile Software Developmet, Addiso-Wesley Professioal 2004 [Kor13] H.-P. Kor, Das agile Vorgehe: Neuer Wei i alte Schläuche oder ei Déjàvu?, i: GI Editio Proceedigs Bad 224 Vorgehesmodelle 2013, siehe: kor.ch/archiv/publikatioe/neuer-wei-i-alte-schlaeuche-oder-deja-vu.pdf [Mar11] R.C. Marti, The Clea Coder: A Code of Coduct for Professioal Programmers, Pretice Hall 2011 [Obe13] R. Oberrath, J. Vollmer, Clea Codig Cosmos: Teil 1: Kosmologie für Softwareetwickler, i: OBJEKTspektrum 6/2013 [Pal04] M. Paluch, Testautomatisierug mit Cotiuous Itegratio: Ist mauelles Teste och sivoll? i: OBJEKTspektrum 4/2013 [Roy04] Royal Academy of Egieerig, British Computer Society, The Challeges of Complex IT Projects, 2004 [Sch10] B. Scheider, U. Vigeschow, Soft Skills für Software-Etwickler: Fragetechike, Kofliktmaagemet, Kommuikatiostype ud -modelle, dpukt.verlag 2010 [Wes12] R. Westphal, Wir glaube icht a schöe Worte Iterview mit CCD-Mitbegrüder Ralf Westphal, i: OBJEKTspektrum 4/2012 [Wiki1] Wikipedia, Broke-Widows-Theorie, siehe: [Wiki2] Wikipedia, Software etropy, siehe: [Wiki3] Wikipedia, Diagose Boreout, siehe: [Wiki4] Wikipedia, Techische Schuld, siehe: [Wiki5] Wikipedia, Modus, siehe: [Wiki6] Wikipedia, Erwartugswert, siehe: [Wiki7] Wikipedia, Fight-or-flight, siehe: Gesamtbewertug der Umfrage Tabelle 2 zeigt, dass über ei Viertel aller Probleme mit dem PM i Verbidug gebracht werde köe. Dieser hohe Wert mag teilweise am schlechte PM-Image bei de Etwickler liege, ist aber bestimmt icht dadurch allei erklärbar. Die PM- Probleme habe mit de RE-Probleme ud de Rahmebedigugsprobleme gemeisam, dass sie vo de Etwickler icht alleie gelöst werde köe. Hier köe ur Mut zur Kommuikatio ud Aufklärug weiterhelfe. Bei Probleme mit techische Aspekte des SEP, mit (teamiterer) Kommuikatio ud mit der Teamstimmug ist das aders. Hier köe die Etwickler vieles allei zum Bessere wede. Voraussetzug hierfür ist: I alle vier Dimesio Neuem gegeüber aufgeschlosse zu sei. Fazit SE-Schmutz ist die dukle Materie im Etwicklerkosmos, die wie echte physikalische Materie dazu eigt, zu akkumuliere ud sich zu verdichte. Ohe aktive Astreguge gege Schmutz werde immer mehr Umwege ud Workarouds ötig, um die erkrakte Software am Lebe zu halte (Verzerrug der SE-Raumzeit). SE-Schmutz fidet sich i alle Dimesioe des Etwicklerkosmos ud maifestiert sich vor allem i schlecht wartbarem Code, suboptimale Prozesse ud verbesserugswürdiger Kommuikatio zwische de Akteure. Zur Prävetio vo SE-Schmutz halte wir folgede Kerkompeteze für wichtig: Mehr Motivatio, sich eues Wisse ud hadwerkliche Fähigkeite azueige. Mehr Motivatio, kostruktive Kommuikatio zu suche. Mehr Mut, seiem Berufsethos treu zu bleibe. Außerdem ka sich als Folge vo Mootoie, Uterforderug oder magelder Wertschätzug eie Null-Bock-Stimmug ( iere Küdigug ) eistelle euerdigs auch Boreout geat (vgl. [Wiki3]). Hiter schlechter Teamstimmug steht immer ei Koflikt, etweder zwische Teammitglieder (iterer Koflikt) oder mit eiem extere Kofliktparter. I beide Fälle gibt es die i Kaste 7 aufgezeigte Möglichkeite, damit umzugehe. Alle i diesem Artikel agesprochee Maßahme ka jeder Etwickler für sich allei verfolge. Im dritte Teil dieses Artikels stelle wir vor, wie diese Maßahme effektiv ud systematisch im Etwicklerteam realisiert werde köe

16 Clea Codig Cosmos: Teil 3: Kosmische Effiziez durch Team Clea Codig Clea Codig Cosmos: Teil 3: Kosmische Effiziez durch Team Clea Codig Was bedeutet eigetlich clea? Usere Atwort darauf lautet: effiziet. Als clea wurde ursprüglich ur der Quellcode bezeichet, der Begriff wird heutzutage aber viel breiter verstade. Wir dehe ih auf de gesamte Etwicklerkosmos aus. Wir glaube weiter, dass ei Appell a die Professioalität bei de meiste Etwickler icht ausreicht, soder dass es och ei stärkeres Mittel gibt, um mehr Sauberkeit im Etwickler- Kosmos zu erreiche: ämlich Teamplay. Deshalb wolle wir i diesem Artikel die Team-Clea-Codig - Methode vorstelle ud zeige, mit welche kokrete Maßahme diese Methode im Projektalltag eigeführt ud so die Clea-Codig-Metalität viel lebediger werde ka. Professioalität ist die Fähigkeit, durch spezielle Hadluge ei kokretes Ziel mit miimalem Aufwad zu erreiche. Professioell bedeutet also, etwas effiziet d.h. clea zu tu (siehe Kaste 1). Demetspreched habe die Clea Code Developer (CCD) eie Iitiative, die 2009 vo Ralf Westphal ud Stefa Lieser gegrüdet wurde (vgl. [CCD]) eie Defiitio dieses Begriffs aufgestellt, der für effiziete Softwareetwicklug (SE) wichtig ist: Professioalität = Bewusstsei + Prizipie. Uter Bewusstsei verstehe die CCD die städige Selbstkotrolle eies Etwicklers, das Wertesystem auch uter widrige Umstäde kosequet azuwede. Damit appelliere die CCD (ud wir auch) a de Berufsethos ud de Ehrgeiz vo Etwickler, ei Profi zu sei oder eier zu werde. Dieser Appell richtet sich a die meschliche Veruft eies jede eizele Etwicklers. ei Mesch, der verstade habe, was verüftig ist, schöpfe aus dieser ratioale Eisicht die Motivatio, das Verüftige auch wirklich zu tu (vgl. [Wik-c]). Diese Philosophie hätte die Welt eigetlich verbesser müsse. Tatsächlich reicht die ratioale Eisicht ur bei starke Idealiste als alleiige Motivatiosquelle aus, verüftig zu hadel. Eie zusätzliche, viel stärkere Motivatiosquelle ist eie soziale Form vo Kotrolle. Als sozialverträglich betrachte wir eie Kotrolle auf Augehöhe i Form der TCC-Qualitätssicherug (siehe Abbildug 1). Sie wirkt folgede Eistelluge etgege: Aber Saubermache ka ich das jetzt icht mehr! Diese Haltug macht deutlich, dass der iere Schweiehud auf Dauer vor allem uter Zeitdruck stärker wird als die persöliche Überzeugug, dass Clea Codig wichtig ist. Nei, ei, so mach ich das aber icht! Uterschiedliche Meiuge, die sich icht aäher, stelle offee oder versteckte Koflikte dar, die Wildwuchs ud damit Ieffiziez bewirke. TCC hilft, die Meiugsvielfalt zusammezuführe. Meie Meiug zählt ja sowieso icht! Die Durchsetzugsstarke im Team habe icht automatisch die bessere Argumete. Durch TCC habe die Durchsetzugsschwache ei Mittel, das ihre Positio stärkt. Ist doch egal, wie mei Code aussieht, es iteressiert sich ja doch keier dafür! Gege diese Eistellug hilft die Warum Team Clea Codig (TCC)? Der Philosoph Immauel Kat vertrat scho vor über 200 Jahre die Meiug, Clea ist alles, was ituitiv verstädlich ist: (Quellcode-)Dokumete, Datestrukture, Kozepte, Regel, Verfahre usw. Ituitiv verstädlich ist, was mit weig Spezialwisse i kurzer Zeit richtig verstade wird. Weig ud kurz ist dabei relativ zur vorliegede Komplexität zu sehe. Clea ist also alles, was die Softwareetwicklug beschleuigt. Das schließt die Korrektheit (vgl. [Wes12]), die Evolvierbarkeit (vgl. [Wes13-a]) ud die Produktioseffiziez (vgl. [Wes13-b]) der Software ei. Kaste 1: IT-Defiitio vo clea. Abb. 1: Das TCC-Kozept (Kaste 3) besteht aus 4 Bereiche ud acht Teilbereiche. Es hat das Ziel, Clea Code ud Clea Architectig (Kaste 5) zu gewährleiste. 18

17 Clea Code ist ei alter Begriff, der de Blick auf de Quellcode fokussiert. Die CCD- Bewegug hat mit ihre Praktike bereits deutlich gemacht, dass viel mehr als ur der Code sauber sei sollte. Um de Blick zu weite ud de gaze Softwareetwicklugsprozess i de Fokus der Effiziezsteigeruge zu brige, spreche wir im Clea Codig Cosmos (CCC) vom Clea Codig. Der CCC erweitert de Professioalitätsgedake der CCD um weitere Aspekte des Applikatios-Lebeszyklus-Maagemets (siehe Abbildug 1 i [Obe13]). Diese Erweiterug schließt sauberes Requiremets-Egieerig, Clea Architectig (siehe Kaste 4), veratwortugsvolles Projektmaagemet (siehe Kaste 6 i [Obe14]) ud effektive Zusammearbeit mit dem Betrieb ei. Als CCD uterscheide wir Prizipie, also Maßahme, die de Quellcode sauber halte, ud Praktike, d. h. eie bute Sammlug vo Maßahme, die gaz uterschiedliche Teile des Softwareetwicklugsprozesses betreffe. Im CCC verfolge wir das gazheitliche Ziel, alle Eiflussgröße auf die Software ud de Softwareetwicklugsprozess icht ur zu ee, soder sie so zu strukturiere, dass alle gleichzeitig besser im Blick behalte werde köe. Zu diesem Zweck habe wir i [Obe13] die vierdimesioale Raumzeit des Softwareetwickler-Kosmos vorgestellt. Im CCC betrachte wir icht ur die schöe, saubere Seite der Softwareetwicklug, soder auch die dukle, schmutzige Seite. Das ist wichtig, um zu erkee, i welche Bereiche des Softwareetwicklugs-Kosmos am meiste Hadlugsbedarf für Effiziezsteigerug besteht. Zu diesem Zweck habe wir i [Obe14] de kosmologische Schmutz beleuchtet. Der i [Obe14] gefudee Softwareetwicklugs-Schmutz macht deutlich, dass die Kommuikatio, die i alle vier Dimesioe des CCC eie Rolle spielt, im Kotext vo Effiziezsteigerug verachlässigt wurde. Der Appell der CCD a die Professioalität ist gut, reicht aber oft icht aus. Eie gegeseitige Qualitätskotrolle im Team ist dagege viel wirkugsvoller. Diese fuktioiert allerdigs ur mit effektiver Kommuikatio. Zu diesem Zweck gibt es im TCC zusätzliche Regel, die das Teamplay betreffe. Wie das clea aussehe ka, stelle wir i diesem Artikel vor. Kaste 2: Clea Code Developer (CCD) ud Clea Codig Cosmos (CCC). TCC-Kotrolle. Sie ist eie stärkere Motivatio als das Zuckerbrot ud Peitsche -Prizip (vgl. [Obe13]) durch eie Code-Watch. Das Team Clea Codig TCC ist Teil des Clea Codig Cosmos (CCC). Im CCC schließe wir us der Philosophie der Clea-Code-Developer (CCD) a, gehe allerdigs i eizele Pukte och weiter (siehe Kaste 2). Die Ritter der Tafelrude verbad das gemeisame Grudverstädis, dass sie erstes alle Gleiche uter Gleiche ware ud sie sich zweites eiem gemeisame Verhalteskodex uterordete. Die gleiche Idee liegt dem TCC zu Grude. Auf diesem Grudverstädis basiert das TCC- Kozept, das aus folgede vier Bereiche besteht: 1. Iitialisierug 2. Ausführug 3. Optimierug 4. Qualitätssicherug Jeder dieser Bereiche beihaltet Teilbereiche. Die isgesamt acht Teilbereiche des TCC-Kozepts lasse sich gut durch die Staatsmetapher veraschauliche (siehe Abbildug 1 ud Kaste 3). Iitialisierug 1.1 Alle Teammitglieder (TM) verpflichte sich, Regel ud Prozesse azuerkee ud eizuhalte, die für alle gleichermaße verbidlich sid. Diese Regel ud Prozesse köe bei Bedarf jederzeit agepasst werde. 1.2 Als erstes wird eie Methode zur Etscheidugsfidug festgelegt: Wie fällt das Team verbidliche Etscheiduge? 1.3 Als ächstes werde zu folgede grudsätzliche Frage verbidliche Etscheiduge getroffe: a) Dokumetatio: Welche Iformatioe werde wie festgehalte, persistiert ud für alle TMs zugäglich gemacht? b) Defiitio of Clea (DoC): Was bedeutet für us Clea Code ud Clea Architectig? c) Defiitio of Doe (DoD): Was geau muss erfüllt sei, damit eie Programmieraufgabe als fertig aerkat werde ka? d) Code Owership: Gibt es so etwas wie persöliche Code oder darf jedes TM jede beliebige Codestelle äder? Awedug 2. Alle TM wede alle festgelegte Regel ud Prozesse bei ihrer tägliche Arbeit kosequet a. Optimierug 3.1 Die TM komme regelmäßig zusamme ud tausche Iformatioe aus, ob die bisherige Regel ud Prozesse gut fuktioiere oder ob sie agepasst bzw. erweitert werde müsse. Dazu stehe Daily-Stadups, Joural Codig Club ud Retrospektive-Meetigs zur Verfügug. Darüber hiaus köe Iformatioe auch durch Pair-Programmig ud Codig Notes ausgetauscht werde. 3.2 Bei Bedarf verabschiedet das Team mit der uter Iitialisierug, Pukt 1.3, festgelegte Methode eue Regel oder ädert bestehede. Qualitätssicherug 4.1 Nach Abschluss eier Programmieraufgabe durch ei TM stellt ei aderes TM sicher, dass die vereibarte DoD erfüllt ist (Vier-Auge-Review). Erst we für beide TM die DoD vollstädig ist, gilt die Programmieraufgabe offiziell als fertig. 4.2 Das Team ka Regel beee, dere Verstoß als schwerwieged deklariert wird. Ei Verstoß gege solche Regel darf im Koses aller TM mit eier Verpflichtug zu eier 1-Euro-Spede verküpft werde. Das Team bestimmt später gemeischaftlich die Verwedug der Spedekasse. Kaste 3: Formelle Beschreibug des TCC (siehe auch Abbildug 1)

18 Clea Codig Cosmos: Teil 3: Kosmische Effiziez durch Team Clea Codig Abb. 2: Thumb Votig. Alle Teammitglieder werde um ei Hadzeiche gebete, bei dem diese drei Daumepositioe zulässig sid. Kostitutio/Basiskoses Am Afag steht die Eiigug aller Teammitglieder (TM) auf de kleiste gemeisame Neer: de Basiskoses (Pukt 1.1 i Kaste 3) er ist das Fudamet des TCC- Kozepts. Abb. 3: Ablauf eier Programmieraufgabe im TCC. Defiitio der Legislative/Methode zur Etscheidugsfidug Die (Meta-)Etscheidug, wie das Team zu eier Etscheidugsfidug kommt, ist für alle kommede Etscheiduge vo grudlegeder Wichtigkeit. Als Werkzeug für die Etscheidugsfidug eiget sich das Thumb Votig (siehe Abbildug 2). Für die Meta-Etscheidug gibt es vier Wege: Sauberes Umsetze eier Architekturaufgabe hat aus CCC-Sicht drei Aspekte: 1. Dokumetatio Die Beschreibug der Architektur beihaltet alle relevate Aforderuge, ist i sich schlüssig ud für alle Stakeholder gut zugäglich ud leicht verstädlich. 2. Bewertug Die gefällte Architekturetscheiduge ermögliche, dass die wichtige Aforderuge gut umgesetzt werde köe ud die Risike miimiert werde. 3. Realisierug Die beschriebee Architektur wird i der Implemetierug umgesetzt ud lässt sich im Code klar achvollziehe. Um das zu erreiche, schlage wir im TCC die Verwedug des arc42 Templates vor (vgl. [Hru13-a], [Zör12]). Zu diesem Template gehört eie Methodik, die eie gewisse Prozess ahe legt (vgl. [Hru13-b]). Die Awedug vo Template ud Prozess führt zu Clea Architectig. Kaste 4: Clea Architectig. Hierarchisches Modell: Das Team überträgt eiem Mitglied für eie bestimmte Bereich die Etscheidugshoheit, z. B. eiem Mitglied mit viel Architekturerfahrug die Etscheidugshoheit über Architekturfrage. Mehrheitsmodell: Die Alterative mit der höchste Zustimmug wird beschlosse. Koset: Die Alterative mit der gerigste Ablehug wird beschlosse (vgl. [Wik-a]). Koses: Eie Alterative wird ur beschlosse, we sie keie Ablehug erfährt (vgl. [Wik-b]). Sie muss evetuell so geädert werde, dass es keie Ablehug mehr gibt. Bei eier Kosesrude wird jeder Teilehmer explizit befragt, welche Alterative ei (gegebeefalls persöliches) Problem darstellt (vgl. [Wit11]). Vorteil der erste drei Möglichkeite ist, dass Etscheiduge relativ schell gefällt werde köe. Ihr Nachteil besteht i der Gefahr, Teamkollege zu zwige, gege ihre persöliche Überzeugug zu arbeite. Das ka zu starke offee oder versteckte Widersprüche führe. Der Vorteil der vierte Möglichkeit ist geau die Vermeidug solcher Widersprüche im Team. Ihr Nachteil ist jedoch eie uter Umstäde lagwierige Etscheidugsfidug. Grudgesetz/projektuspezifische Regel Letzter Schritt der Iitialisierug ist das gemeischaftliche Beatworte vo Frage, die grudsätzlich i jedem Projekt wichtig sid (Pukt 1.3 i Kaste 3). Dies stellt die zuvor beschlossee Meta-Etscheidug auf eie erste Probe ud ka bei größere Teams mehr als eie Nachmittag Aufwad bedeute. Wir gebe für die i Kaste 3 gestellte Frage folgede Empfehluge: Dokumetatio: Alle beschlossee Regel ud Prozesse sowie alle vom Team getroffee architektoische Etscheiduge (siehe Kaste 4) sid i eiem Wiki festzuhalte. Alle TM habe Lese- ud Schreibrechte. Darüber hiaus werde ei zetraler Problem-Lösug-Katalog ud eie zetrale Checklistesammlug gepflegt (siehe Kaste 5). DoC: Für CCD-Afäger eige sich die Regel des rote Grades (siehe ute). CCD-Fortgeschrittee köe uter Berücksichtigug der Kritikalität die für das Projekt geeigete CCD-Regel festlege (siehe Abbildug 6). DoD: Die i Kaste 3 uter 4.1 geate Maßahme verbidlich festlege (siehe Abbildug 3 i [Obe14]). Im Zusammehag mit der Testabdeckug empfehle wir bei mittlerer Kritikalität circa 80 Prozet der Programmzeile (siehe Abbildug 6). Außerdem halte wir midestes eie Itegratiostest für otwedig. Eie mauelle Utersuchug muss dabei sicherstelle, dass alle kritische Pfade ethalte sid. Code-Owership: Alle gehört alles, d. h. jeder Etwickler darf jede Codestelle äder. Das ist icht selbstverstädlich ud muss klar kommuiziert werde. 20

19 Exekutive/Awedug Der Projektalltag eies Etwicklers besteht im Wesetliche aus der Aalyse vo Aforderuge, dem Umsetze dieser Aforderuge ud der Qualitätssicherug. Bei dieser Arbeit werde alle im Team abgesprochee Regel ud Prozesse agewadt. Dabei gehört es zum Berufsethos, diese Regel auch gege widrige Umstäde wie Termidruck ud de iere Schweiehud professioell zu verteidige. Parlamet/Meiugsaustausch Für eie städige Optimierug des TCC braucht das Team ei Forum zum Diskutiere ud zur Meiugsbildug. Im TCC stehe dafür drei verschiedee Forme vo Parlametssitzuge zur Verfügug: Do t Repeat Mistakes Vieles i der Softwareetwicklug lässt sich icht automatisiere ud muss mauell erledigt werde. Dabei geschehe immer wieder Fehler. Damit diese Fehler icht wiederholt auftrete, ist es wichtig festzuhalte, wie sie vermiede werde köe. Für mauelle Arbeitsschritte eiget sich eie Checkliste, die jede Schritt i der richtige Reihefolge beet. Do t Re-uravel Mysteries Bei komplexe Systeme kommt es immer wieder vor, dass sich das System völlig uerwartet verhält. Die Ursachefidug dauert machmal lage ud hält die Softwareetwicklug sehr auf. Nach Abschluss eier solche Rätselsuche ist es deshalb wichtig, das Problem zusamme mit seier Lösug zu dokumetiere. Dafür eiget sich ei Problem-Lösug-Katalog. Dieser ka mit der Zeit für ei spezielles Problem (Symptom) mehrere Lösuge beihalte. Auf diese Weise muss ei Rätsel ur eimal gelöst werde. Kaste 5: Die DoReMi- ud DoReMy-Regel. Daily Stadups: Nach dem Vorbild vo Scrum sehr kurze Meetigs, die täglich zur selbe Zeit im Stehe durchgeführt werde. Jedes TM beschreibt kurz seie aktuelle Tätigkeit ud et gegebeefalls Probleme, die es aufhalte. Koste: Circa zwei Miute pro Perso ud Tag, circa 0,5 Persoetage (PT) pro Moat für ei füfköpfiges Team. Nutze: Aufdecke vo Querverbiduge zwische Programmieraufgabe, Hilfeagebote vo TM, die Möglichkeit zur tägliche Optimierug vo Regel ud Prozesse. Joural Codig Club: Wöchetliche oder 14-tägige Team-Meetigs, die Fortbildugscharakter mit direktem Projektbezug habe. Koste: Circa 2 PT pro Moat für ei füfköpfiges Team. Ihalt: Besprechug vo Fachliteratur, Code-Reviews, Vorstellug vo aktuell oder zuküftig eigesetzte Techologie. Nutze: Agleichug des Wissesstads im Team, eiheitliche Vorstellug davo, was sauber ist ud was icht, eiheitliche Meiug, mit welcher Lösugsstrategie wiederkehrede Probleme agegage werde. Retrospektive-Meetigs: Nach dem Vorbild vo Scrum moatliche oder quartalsweise zwei- bis dreistüdige Team-Meetigs. Ihalt: Was lief gut, was schlecht? sowie Lessos Leared. Koste: Circa 1,5 PT pro Moat für ei füfköpfiges Team. Nutze: Regelmäßige Reflexio der aktuelle TCC-Regel ud -Prozesse über eie lägere Zeitraum. Diese drei Team-Meetigs beötige zusamme für ei füfköpfiges Team ca. 4 PT pro Moat a Kommuikatiosaufwad. Dieser Aufwad ist aber kei reier Zusatzaufwad für TCC, de Kommuikatio fidet auch ohe TCC statt. Bei Teams, die vo sich aus viel kommuiziere, ist der Zusatzaufwad für TCC gerig, die Kommuikatio erfolgt ur i strukturierterer Form. Parlametsmitglieder tausche auch außerhalb der Parlametssitzuge Iformatioe aus. Für TCC-Mitglieder stehe dazu Pair-Programmig (vgl. [Wik-f]) ud Codig-Notes zur Verfügug: Pair-Programmig ist besoders effektiv, we es gezielt bei kifflige Probleme zum Eisatz kommt. Eie gute Lösug wird so meistes viel scheller gefude als allei. Zugleich wird das Wisse über diese Lösug im Team verbreitet ud uerfahree Etwickler köe dabei extrem gut vo erfahree lere. Codig Notes sid ei Mittel, um wertvolle Iformatioe zu verbreite ud auch zu koserviere. Die eifachste Form eier Codig Note ist die a de Team-Verteiler. Auf diese Weise köe Hiweise über eue Utilities im Code oder Liks zu eier iteressate Webseite eifach mitgeteilt werde. Werde solche s mit eiem spezielle Schlüsselbegriff im Betreff markiert, ka jeder Etwickler i seiem Postfach sehr eifach eie Wissesdatebak aufbaue. Abb. 4: Schematische Darstellug vo Team-Type ([Wiki-e]). Jeder Pfeil stellt die Wirkrichtug eies Etwicklers ud desse Stärke dar. Jeder Kreis stellt ei Team dar. Die Summe der Wirkrichtuge i eiem Team stellt die Team-Performace (die Effiziez des Teams) dar. Nur i echte Teams ist die Performace hoch. Arbeite die Teammitglieder icht gut zusamme, hadelt es sich eher um eie Gruppe oder sogar um eie Haufe. TCC ermöglicht, aus Haufe Gruppe ud aus Gruppe echte Teams zu mache. Dazu müsse aber auch die Rahmebediguge stimme

20 Clea Codig Cosmos: Teil 3: Kosmische Effiziez durch Team Clea Codig Alle im Team vereibarte CCD-Regel wurde eigehalte (DoC). Es gibt keie als ufertig markierte Codestelle mehr (siehe Kaste 6). Der Quellcode ist leicht verstädlich (dazu zählt uter aderem die Code- Dokumetatio). Die Testabdeckug ist ausreiched. Erst achdem auch der Reviewer sei OK abgegebe hat, gilt die Programmieraufgabe offiziell als erledigt. Bei Fehler bzw. Mägel, die im Nachhiei auftrete, trägt der Reviewer eie ebeso große Veratwortug wie der Autor des Codes. Uterstütze lässt sich diese Vorgehesweise durch das (leider ur auf GIT ud Jekis basierede) Tool Gerrit (vgl. [Ger13]). Diese Vorgehesweise hat folgede füf Vorteile: Abb. 5: Das TCC-Startup-Kid (DoD = Defiitio of Doe, DoC = Defiitio of Clea). Legislative/Weiteretwicklug des Regelwerks I de frühe Phase eies Projekts reiche die projektuspezifische Grudregel zuächst aus, um effektiv im Team zu arbeite. Jedes Projekt stellt jedoch eie eigee kleie oder große Welt dar, die spezifische Umstäde ud Situatioe mit sich brigt. Deshalb dauert es i der Regel icht lage, bis die Notwedigkeit ach projektspezifische Regel ud Prozesse deutlich wird. Es gibt immer wieder Phase im Projekt, i dee die Komplexität wächst ud mit dem Projekt etwickel sich auch die TM weiter. Aus diesem Grud ist es wichtig, die bestehede Regel ud Prozesse städig zu reflektiere ud gegebeefalls zu optimiere. Die im Abschitt Parlamet/Meiugsaustausch agesprochee Möglichkeite zur Diskussio ud zum Iformatiosaustausch führe bei de TM zu eier Meiugsbildug, die sich da immer wieder i der Überarbeitug der bestehede Regel ud Prozesse oder i der Formulierug euer Regel ud Prozesse maifestiert. Der Verfassugsschutz/ Vier-Auge-Review Das Vier-Auge-Review prüft die Eihaltug der Defiitio of Doe (DoD), beruht auf dem Vier-Auge-Prizip ud stellt ei bewährtes Review-Verfahre dar: die Stellugahme (vgl. [Poh10]). Betrachtet ei TM eie Programmieraufgabe (Bugfix oder eues Feature) als vollstädig umgesetzt, bittet es ei aderes TM seier Wahl, ei Vier-Auge-Review für diese Programmieraufgabe durchzuführe (siehe Abbildug 3). Der Reviewer prüft Folgedes: Alle fuktioale ud icht-fuktioale Aforderuge wurde umgesetzt. Mit folgeder Sytax köe Codestelle, die i irgedeier Form och eie Überarbeitug beötige, markiert werde: <Tag> <Datum> <Autor des Tags> <Beschreibug> Folgede Tags stehe zur Verfügug: FIXME: Diese Codestelle muss och bearbeitet ud der Tag etfert werde, um die DoD zu erreiche. TODO: Diese Codestelle (ud der Tag) dürfe für die DoD ur verbleibe, we dafür im verwedete Issue- Tracker ei Issue agelegt wurde. REFACTORME: Diese Tags zeige a, dass eie Codestelle icht optimal gelöst wurde. Sie sid aber icht DoD-relevat ud sollte sparsam verwedet werde. Kaste 6: Das TCC-Code-Taggig- System. 1) Alle Softwarefehler, die der Reviewer fidet, köe sofort ud zeitah vom Autor behobe werde. Ohe das Review falle diese Fehler meistes erst ach der ächste Auslieferug auf oft erst ach Woche ud Moate. Das macht zusätzliche Verwaltugsaufwad dieses Bugs i eiem Issue- Tracker ud eie häufig lagwierige achträgliche Aalyse otwedig. 2) Trotz Eisatz vo automatische Code- Aalyse bleibt der meschliche Code- Review das eizig sichere Mittel, die Verstädlichkeit vo Quellcode festzustelle. 3) Für Besuch macht ma zu Hause i der Regel grüdlicher sauber als für sich allei. Das Gleiche gilt beim Programmiere: Wer möchte scho, dass ei TM Schmutz im selbst geschriebee Code fidet? 4) Kostruktive Kritik ist für viele Etwickler motiviereder als Desiteresse a geleisteter Arbeit. 5) Fidet ei Reviewer weig oder keie Kritikpukte, stellt dieses Review-Ergebis für de Autor ei uausgesprochees Lob dar eie wortlose Aerkeug für gute Arbeit. Das Lob darf aber auch gere offe ausgesproche werde. Die Judikative/die 1-Euro-Regel Fehler zu mache, ist meschlich. Fehler wiederholt zu mache, reduziert aber die Effiziez der Softwareetwicklug (siehe Kaste 5). Immer wiederkehrede Fehler, die adere behider, schaffe schlechte Teamstimmug, die ebefalls die Effiziez reduziert. Hier ei Beispiel: Zum Feier 22