Zwischen Entwicklungsumgebung, Tests und altem Code

Natürlich kann ich bei einer Programmiersprache wie Java in einem Editor coden und meinen Code dann per Kommandozeile kompilieren und aufrufen (im Studium habe ich so Java gelernt). Das macht aber selten jemand so. Die meisten Programmierer nutzen eine Entwicklungsumgebung. Manche Umgebungen sind so komplex, dass man eigens für sie geschult werden muss. Das liegt auch daran, dass über die jeweiligen Entwicklungsumgebungen noch eine Quellcodeverwaltung und andere Features dabei sind bzw. angeboten werden.

Zur Entwicklung von Code kommt dann noch das automatisierte Testen. Nehmen wir die einfache Methode isEven als Beispiel, die bei einer übergebenen Zahl prüft, ob diese gerade ist. Die Methode besteht aus einer Zeile Code, die wirklich interessant ist. Will ich sie automatisiert testen, brauche ich mindestens zwei Testmethoden. Ich schreibe also schon bei diesem einfachen Beispiel mehr Code, der nicht produktiv geht, als solchen, der produktiv geht. Die Tests haben spätestens bei der nächsten oder übernächsten Änderung ihren Wert, wenn ich so in kurzer Zeit überprüfen kann, ob die Umsetzung neuer Anforderungen alte Codestellen unerwartet geändert hat.

Und natürlich findet das alles nicht auf der sprichwörtlichen grünen Wiese statt, es gibt bereits älteren Code, mit dem der neue zusammenarbeiten soll. Dafür muss der alte Code (auch Legacy Code genannt) analysiert und verstanden werden. Enthält er noch Fehler, müssen diese gefunden, analysiert und behoben werden.

Wenn also Entwicklungsteams an der Entwicklungsumgebung sitzen, dann ist nur eine ihrer Aufgaben, Code für Produktion zu schreiben. Zu den drei bisher aufgezählten weiteren Tätigkeiten (sicherlich ist die Liste noch unvollständig) kommen noch weitere. Ich fasse sie mit Lesen, Schreiben und Kommunikation zusammen.

Abseits der Entwicklungsumgebung ...

Unter Lesen fällt alles, was gelesen werden sollte: Das geht bei den Anforderungen der Aufgaben los, zieht sich über die Spezifikationen und kann bis zu Programmierrichtlinien, good practices und Anleitungen im Netz gehen. Und natürlich müssen diese Texte nicht nur gelesen, sondern auch verstanden und Schlüsse müssen daraus gezogen werden.

Unter Schreiben fällt unter anderem all die Dokumentation, die außerhalb des Codes stattfindet. Das können Schnittstellenbeschreibungen sein oder alle verschriftlichten Informationen, die an Dritte (inner- und außerhalb der Firma) gehen müssen.

Bei Kommunikation geht es um die Verständigung im Team, mit Führungskräften, anderen Teams (technisch oder nicht) und mit den Personen, von denen die Anforderungen gestellt wurden. Und diese Kommunikation kann vor, während und nach der Umsetzung stattfinden. Beispiele wären an dieser Stelle Nachfragen zu Anforderungen, Abstimmungen von Schnittstellen, Schätzungen für den Aufwand abzugeben und anzupassen oder auch das Onboarding neuer Teammitglieder. Die Übergänge zwischen Lesen, Schreiben und Kommunikation sind fließend.