Agile Entwicklung bei world4you – aus Idee wird Code

Gemeinsam haben wir als Backend-Entwicklerteam von world4you in den letzten Jahren einen Prozess geschaffen, der sich zeigen lässt und eine Kultur etabliert, auf die wir stolz sind. Unsere Zusammenarbeit basiert auf gegenseitigem Respekt, Transparenz und Wissenstransfer, verfeinert mit modernem Tooling zur Effizienzsteigerung und Fehlerminimierung. Dazu nutzen wir die agile Entwicklung.

Lies weiter, wenn du wissen möchtest, wie und womit wir arbeiten, mit welchen Strategien wir uns auf die wichtigen Aspekte unserer Arbeit konzentrieren können, und was passiert, wenn doch einmal etwas in die Hose geht.  

Anforderungen, Architektur und Abstimmungen

Agile Entwicklung bei world4you

Wir arbeiten mit dem Projektmanagementframework Scrum. Nach dem “People over Process”-Grundsatz des Manifests der agilen Entwicklung haben wir den Ablauf unserer Sprints so angepasst, dass er bestmöglich für unser Team funktioniert.

Bei gemeinsamen Plannings schätzen und planen wir die Aufgaben für unseren nächsten Sprint, und in zweiwöchentlichen Reviews zum Sprintabschluss präsentieren wir unseren Output an Stakeholder und andere Kolleginnen sowie Kollegen. Bei den Retrospektiven haben wir als Team beschlossen, sie weiterhin regelmäßig zu machen, aber dafür nur jeden zweiten Sprint. Frisch erkannte Probleme sprechen wir meist direkt oder im Standup an. So leben wir agile Entwicklung.

Think First, Code Later

Guter Code beginnt mit guter Architektur. Größere Aufgaben splitten wir in mehrere Teile und räumen dafür ausreichend Zeit für die Analyse und Ausarbeitung der benötigten Softwarearchitektur ein. Geplant wird je nach persönlicher Vorliebe mittels Whiteboard, UML-Diagramm, klassischem Schmierzettel oder anderen Tools. Manche von uns brainstormen gerne im Team, andere basteln sich schnelle Prototypen zur frühzeitigen Validierung und Ideenfindung.

Egal welcher Ansatz hier gewählt wird, eines haben alle gemeinsam: wir behandeln unsere Architekturentwürfe wie Code und unterziehen jeden einzelnen von ihnen einem Peer Review. Damit können wir die verschiedenen Stärken unserer Kolleginnen und Kollegen kombinieren sowie von theoretischer Expertise und praktischer Erfahrung gleichermaßen profitieren, um langlebige und hochqualitative Systeme zu entwerfen.

Unsere Tools und Methoden

PhpStorm, PyCharm und Co

Allen unseren Entwicklerinnen und Entwicklern stehen die IDEs (integrierte Entwicklungsumgebung, von englisch integrated development environment) von JetBrains zur Verfügung. Features wie Code-Vervollständigung, automatisches Formatieren, und Refactoring-Tools helfen uns, unseren Fokus auf die wichtigen Dinge zu konzentrieren. Fragen wie Tabs oder Spaces (und deren richtige Anzahl) klären sich damit ganz von selbst.

Der Code in all unseren Projekten folgt neben den üblichen Industrie-Standards (z.B. PSR für PHP-Code) auch unserem firmeninternen Style Guide. Natürlich wird auch dieser so weit wie möglich direkt von der IDE geprüft und angewendet. Die JetBrains-Lizenzen dürfen wir selbstverständlich auch privat verwenden.

Tests, Tests, Baby

Wir könnten hier jetzt mit unserer monumentalen Testabdeckung angeben, aber wir wollen ehrlich sein: aus historischen Gründen wir haben nicht so viele Tests, wie wir gern hätten – aber wir arbeiten dran! Ein paar unserer Projekte haben bereits Testabdeckungen von über 90%, und dort wollen wir auch mit unseren anderen Projekten hin. 

Ein großer Teil unseres Teams hat Zertifikate als Softwaretester:innen erworben, dementsprechend entwickeln wir auch. Neu geschriebener Code wird so weit wie möglich durch automatisierte Unit- und Integrationtests abgedeckt. So stellen wir die korrekte Funktionsweise unserer Arbeit sicher und garantieren, dass der Code auch in Zukunft so funktioniert, wie er soll. Mocking, TDD (testgesteuerte Programmierung; von englisch test-driven development), Regressionstests – nicht nur leere Worte, sondern Teil unserer täglichen Arbeit.

Automate The Boring Stuff

Die besten Tests oder Style Guides nützen nichts, wenn sie nicht verwendet werden. Wir wissen, dass Menschen Fehler machen und manchmal Dinge schleifen lassen – jeder einzelne von uns mit eingeschlossen. Hier kommen unsere automatisierten CI/CD-Pipelines – diese stehen für Continuous Integration / Continuous Delivery – ins Spiel: ohne den mehrstufigen Prozess in unserer GitLab-Pipeline erfolgreich abzuschließen, kann kein Stück Code gemerged werden. Ganz egal wer ihn geschrieben hat, vom Junior zum Lead Developer müssen sich diesem Prozess alle beugen.

Unsere Pipelines variieren natürlich von Projekt zu Projekt, bestehen aber immer aus mehreren Stufen, die verschiedene Aspekte des Codes prüfen. Diese sind zum Beispiel: Syntaxchecks für alle verwendeten Sprachen im Projekt, Linting, statische Security- und Code-Quality-Analyse, automatisierte Unittests, gemockte Integrationtests und so weiter.

Wenn wir in unseren Reviews oder durch unser Monitoring (mehr dazu weiter unten) eine Fehlerquelle entdecken, die sich leicht automatisch aufdecken lässt, erweitern wir einfach unsere Pipelines. So stellen wir sicher, dass wir uns auf das fokussieren können, was wirklich zählt und verschwenden keine Zeit mit Dingen, in denen ein Computer ohnehin effektiver ist als wir.

Qualitätssicherung und Codereviews

Codereviews für alles und jeden

Kein Merge Request erreicht unsere Codebase, ohne ein Code Review durch mindestens eine Kollegin oder einen Kollegen durchlaufen zu haben. Hier gilt keinesfalls die weit verbreitete Regel, dass Senior-Entwickler:innen den Code aller anderen Kolleginnen und Kollegen abschließend kontrollieren. Unser Prozess ist inklusiver und unserer Meinung nach auch langfristig effektiver.

Dass ein:e Junior-Mitarbeiter:in den Code eines Seniors reviewt, ist bei uns keine Besonderheit. Wir schätzen alle unsere Mitarbeiter:innen, unabhängig vom Erfahrungslevel, und wissen, dass jeder von uns andere Talente und Qualitäten mitbringt, und man von jedem einzelnen etwas lernen kann. Zusätzlich haben sich Codereviews als effektives Mittel zum Wissenstransfer etabliert. Durch wechselnde Reviewer können wir so einerseits unsere Qualitätsstandards aneinander angleichen, und andererseits Inselwissen bei bestimmten Themen von Anfang an vermeiden.

Dein Code, mein Code, unser Code

Wir wissen: sobald Code einmal gemerged ist und unser System erreicht hat, sollten wir alle damit arbeiten können. Und wir sollten dies im Idealfall auch gerne tun. Das funktioniert aber nur, wenn wir gemeinsam an einem Strang ziehen und unsere Codequalität kontinuierlich hoch halten – niemand arbeitet gerne mit Spaghetticode. Unnötig verschachtelte Codestrukturen wollen wir so vermeiden.

Wir versuchen, uns diesen Gedanken der Zusammenarbeit am gemeinsamen Projekt bei jedem Review im Hinterkopf zu behalten. Kritik an der eigenen Arbeit bringt auch immer das Potential für Konflikt mit sich. Aus genau diesem Grund können unsere durchgehenden Code Reviews für neue Mitarbeiter:innen, die diesen Prozess so noch nicht kennen, am Anfang ganz schön einschüchternd sein. Wir versuchen uns deshalb an die Code Review Guide von Google zu halten, um die Zusammenarbeit für Entwickelnde und Reviewende so respektvoll, reibungslos und angenehm wie möglich zu machen.

Und was, wenn etwas schiefgeht?

Mindestens einmal im Leben jeder Entwicklerin oder jedes Entwicklers wird es passieren: man macht einen Fehler und zerstört das Produktivsystem. Ursprünglich wollte ich hier eine Liste von solchen Vorfällen einbauen, die unserem Team in den letzten Jahren passiert ist, kann mich aber an keinen einzigen, außer meinen eigenen, erinnern. Ich weiß, dass solche Fehler (mit den entsprechenden Auswirkungen) passiert sind, aber bei bestem Willen nicht, wer an was beteiligt war.

Ich weiß allerdings, dass jeder einzelne dieser Vorfälle zu Verbesserungen in unserem Prozess geführt hat. Sei es durch automatische Checks in der Pipelines, neue Code-Guidelines, oder der Priorisierung des Rewrites eines Legacy-Teils unserer Codebase. Unsere Fehlerkultur kennt keine Schuldigen. Wenn es zu gravierenden Fehlern kommt, hat unser Prozess versagt und wir arbeiten gemeinsam daran, wie wir ihn verbessern, und Fehler in Zukunft vermeiden können.

Deployment, Monitoring, Security

Release Early, Release Often

Wir haben gemerkt, dass unser bester Code in Projekten entsteht, in denen wir “nur” entwickeln müssen. Lange Build- und Rolloutprozesse gehen uns auf die Nerven, ein eigentlich dringend benötigtes Refactoring wird zum Beispiel immer weiter verschoben, weil es den Aufwand des Rollouts dann doch nicht wert ist. Solche Arbeitsweisen erfüllen aber nicht die Ansprüche, die wir als Team an uns selbst stellen.

Nahezu alle unsere Build und Rolloutprozesse sind daher voll automatisiert, um einen schnellen Release, und die damit indirekt verbundene hohe Qualität zu erreichen. Je nach Projekt setzen wir auf CI/CD-Pipelines in GitLab, Deployments über Foreman, oder Ansible für gestaffelte Rollouts auf hunderte Server.

Error-Monitoring und Security

Um nicht mehr wie früher Logfiles mit grep durchsuchen zu müssen, oder Stacktraces im E-Mail-Postfach zu finden passiert unser Error Monitoring mittlerweile zentralisiert durch eine selbstgehostete Instanz von Sentry. Hier sind wir gerade noch dabei, unser Logging mit Releasetags und anderen Tools zu optimieren.

Auch wenn (oder gerade weil) wir Entwickler:innen, die in Security-Themen geschult und zertifiziert sind, im Team haben, laden wir einmal im Jahr professionelle Penetration-Tester:innen für Security-Audits zu uns ein. Dadurch können wir möglicherweise vorhandene technisch gefinkelte Sicherheitslücken aufdecken und durch die abschließenden Reports das Security-Fachwissen unserer Teammitglieder steigern. Neben den jährlichen Penetration-Tests analysieren wir unsere Projekte regelmäßig durch spezialisierte Security-Analyse-Software.