"...das hat schon mal funktioniert!" - Wie refactoring trotz Code & Teams im ständigen Fluss langfristig gelingen kann.
Wir haben in den letzten Jahren etliche Softwareprojekte miterlebt - darunter Neuentwicklungen, oft aber auch den Umbau oder die Migration von bestehen Codebases. Wir haben in diversen Teams gearbeitet, nach mehr oder weniger agilen Ansätzen. Wir haben Erfolge erlebt - ebenso wie Fehler und Projekte, die schlecht gelaufen sind.
Das, was unsere Arbeit aber immer prägt, ist refactoring. Eine Softwarelösung ist stets im Fluss. So steht die Frage nach Wartung und Weiterentwicklung ständig an erster Stelle.
Leichter gesagt als getan - denn damit beschäftigt sich die Softwareindustrie seit jeher. Unser Fokus waren und sind immer die Menschen. Im Team wie im Fachbereich gehören klare und gute Kommunikation sowie strukturierter Aufbau von Know-How zu den wichtigsten Grundprinzipien.
Dadurch kann einerseits ein zeitlich und budgetär eingeschränktes Projekt erfolgreich abgeschlossen und gleichzeitig schwankende Human Resources abgefedert werden. Denn nicht jeder ist als Entwickler geboren oder hat am Anfang den entsprechenden Ausbildungspfad gewählt. Menschen im Team, die sich von selbst ständig neu ausrichten und einlernen?
Eine fast unrealistische Erwartung.
Die nächsten Abschnitte beschreiben im Detail, nach arc42 strukturiert, welche Ansätze und Tools wir nutzen, damit das menschliche Element im breiten Softwareuniversum seine Stärken voll entfalten und einsetzen kann - und dass immer wieder neu.
Unser Zeil ist, dass mit jedem refactoring die Qualität1 des Codes steigt und das Team ein Stück schlauer wird.
Damit Projekte geligen und refactoring sicher gemacht werden kann, glauben wir:
Welche Ziele verfolgen wir mit unserem Ansatz?
| Id | Ziel | Erwartung |
|---|---|---|
| Q1 | erflogreiches Projekt | sollte in den gegeben Constraints (Zeit, Budget) machbar sein |
| Q2 | Wartbarkeit des Codes | Changes müssen vorgesehen werden, Entwicklungsmuster und Prinzipien (z.B. Open-closed principle) sind Standar |
| Q3 | Jeder ist im Team Willkommen | Das Team kann flexibel neue Mitgleider aufnehmen und verlieren, ohne dass das Projekt groß leidet |
| Q4 | Standards werden eingehalten | Regeln sind einfach, klar und nachvollziehbar kommuniziert und im Team veränderbar |
Welche Erwartungen haben diverse Stakeholder an refactoring?
| Role | Erwartung |
|---|---|
| Fachbereich | will neue Features schnell implementiert haben (und Bugs gefixed), ohne den Satz “das hat schon mal funktioniert” nutzen zu müssen |
| Entwickler | will für eine kleine Anpassung wenig Zeit benötigen, sich nicht wiederholen und wiederkehrende Aufgaben (z.B. Testing) automatisieren |
| Quereinsteiger | will verstehen, was der Unterschied zwischen int und Integer in Java ist und welche Konsequenzen das mit sich bringt |
| Software Architekt | will modulares, skalierbares und sauberes Design das von anderen Stakeholdern mitgetragen wird |
| Projekt Manager | will Budget und Zeitconstrainst eingehalten haben |
| Quality Engineer | will die Qualität der Software bei jeder inkrementelen Erweiterung steigern |
| Betrieb | will schnelle Reaktionszeiten durch Development |
Die Qualitätsziele beschreiben Aspekte der Zusammenarbeit, auf die wir besonderen Fokus legen.
Clean Code verstehen).Letztlich wird dadurch ein weiteres Qualitätsziel erreicht, nämlich die Wartbarkeit des Codes (Q2). Im Allgemeinen öffnen sich dadurch die Wegen zum kontinuierlichen refactoring.
Qualität kann natürlich beliebig definiert sein, wir verstehen darunter aber eine Qualität, die gemessen werden kann, sei es durch statische Codeanalyse, Team Velocity unsw. ↩