Bringen Sie Ihrem Team eine gesunde Denkweise zur Codeüberprüfung

Eine „Codeüberprüfung“ ist ein Moment im Entwicklungsprozess, in dem Sie (als Entwickler) und Ihre Kollegen zusammenarbeiten und nach Fehlern in einem aktuellen Codestück suchen, bevor es veröffentlicht wird. In einem solchen Moment können Sie entweder der Code-Autor oder einer der Reviewer sein.

Bei einer Codeüberprüfung sind Sie sich möglicherweise nicht sicher, wonach Sie suchen. Auf der anderen Seite wissen Sie beim Einreichen einer Codeüberprüfung möglicherweise nicht, worauf Sie warten müssen. Dieser Mangel an Empathie und falschen Erwartungen zwischen den beiden Seiten kann unglückliche Situationen auslösen und den Prozess beschleunigen, bis er in einer unangenehmen Erfahrung für beide Seiten endet.

In diesem Artikel zeige ich Ihnen, wie dieses Ergebnis geändert werden kann, indem Sie Ihre Denkweise während einer Codeüberprüfung ändern:

• Als Team
• Als Autor
• Als Rezensent

Als Team arbeiten

Fördern Sie eine Kultur der Zusammenarbeit

Bevor wir beginnen, ist es wichtig zu verstehen, warum Code überprüft werden muss. Wissensaustausch und Teamzusammenhalt sind für alle von Vorteil, aber wenn sie mit einer schlechten Denkweise durchgeführt werden, kann ein Code-Review einen enormen Zeitaufwand mit unangenehmen Ergebnissen bedeuten.

Die Einstellung und das Verhalten des Teams sollten den Wert einer vorurteilsfreien Zusammenarbeit mit dem gemeinsamen Ziel des Lernens und Teilens umfassen – unabhängig von der Erfahrung anderer.

Beziehen Sie Code-Reviews in Ihre Schätzungen ein

Eine vollständige Codeüberprüfung braucht Zeit. Wenn es eine Woche gedauert hat, bis eine Änderung vorgenommen wurde, erwarten Sie nicht, dass die Codeüberprüfung weniger als einen Tag dauert. Es funktioniert einfach nicht so. Versuchen Sie nicht, eine Codeüberprüfung zu beschleunigen, und betrachten Sie sie nicht als Engpass.

Code-Reviews sind genauso wichtig wie das Schreiben des eigentlichen Codes. Denken Sie als Team daran, Codeüberprüfungen in Ihren Workflow einzubeziehen und Erwartungen darüber festzulegen, wie lange eine Codeüberprüfung dauern könnte, damit alle synchronisiert sind und sich auf ihre Arbeit verlassen können.

Sparen Sie Zeit mit Richtlinien und Automatisierung

Ein effektiver Weg, um konsistente Beiträge zu gewährleisten, ist die Integration einer Pull-Request-Vorlage in das Projekt. Dies wird dem Autor helfen, eine gesunde PR mit einer vollständigen Beschreibung einzureichen. Eine PR-Beschreibung sollte erklären, was der Zweck der Änderung ist, den Grund dafür und wie man sie reproduziert. Screenshots und Referenzlinks (Git-Problem, Designdatei usw.) sind der letzte Schliff für eine selbsterklärende Einreichung.

Wenn Sie all dies tun, werden frühe Kommentare von Prüfern verhindert, die nach weiteren Details fragen. Eine andere Möglichkeit, Code-Reviews weniger pingelig erscheinen zu lassen, besteht darin, Linters zu verwenden, um Codeformatierungs- und Codequalitätsprobleme zu finden, bevor ein Reviewer überhaupt involviert ist. Wenn Sie während des Überprüfungsprozesses einen sich wiederholenden Kommentar sehen, suchen Sie nach Möglichkeiten, ihn zu minimieren (durch bessere Richtlinien oder Codeautomatisierung).

Bleib Student

Jeder kann eine Codeüberprüfung durchführen, und jeder muss eine Codeüberprüfung erhalten – unabhängig von der Dienstaltersstufe. Nehmen Sie jedes Feedback dankbar an, um zu lernen und Wissen zu teilen. Betrachten Sie jedes Feedback als offene Diskussion und nicht als Abwehrreaktion. Wie Ryan Holiday sagt:

„Ein Amateur ist defensiv. Der Fachmann findet das Lernen (und gelegentlich sogar das Auftauchen) angenehm; Sie mögen es, herausgefordert und gedemütigt zu werden, und engagieren sich für Bildung als fortlaufenden und endlosen Prozess. (...)“

— Ryan Holiday, Ego ist der Feind

Bleiben Sie bescheiden, denn sobald Sie aufhören, ein Student zu sein, wird Ihr Wissen brüchig.

Die Kunst der Gutachterauswahl

Meiner Meinung nach ist die Auswahl der Reviewer eine der wichtigsten Entscheidungen für ein effektives und gesundes Code-Review als Team.

Angenommen, Ihr Kollege reicht eine Codeüberprüfung ein und beschließt, „jeden“ zu markieren, weil er/sie unbewusst den Prozess beschleunigen, den bestmöglichen Code liefern oder sicherstellen möchte, dass alle über die Codeänderung Bescheid wissen. Jeder der Rezensenten erhält eine Benachrichtigung, öffnet dann den PR-Link und sieht viele Personen, die als Rezensenten markiert sind. Der Gedanke „jemand anderes wird es tun“ taucht in ihren Köpfen auf, was dazu führt, dass sie die Codeüberprüfung ignorieren und den Link schließen.

Da noch niemand mit der Begutachtung begonnen hat, wird Ihr Kollege jeden der Begutachter daran erinnern, dh Druck auf ihn ausüben. Sobald die Gutachter damit beginnen, dauert der Überprüfungsprozess ewig, weil jeder seine eigene Meinung hat und es ein Albtraum ist, eine gemeinsame Einigung zu erzielen. In der Zwischenzeit wird jeder, der sich entschieden hat, den Code nicht zu überprüfen, mit Millionen von E-Mail-Benachrichtigungen mit allen Überprüfungskommentaren zugespammt, wodurch seine Produktivität beeinträchtigt wird.

Das ist etwas, das ich öfter sehe, als mir lieb ist: Pull Requests mit einer Gruppe von Leuten, die als Reviewer gekennzeichnet sind und ironischerweise in einer unproduktiven Codeüberprüfung enden.

Bei der Auswahl der Gutachter gibt es einige gemeinsame effektive Vorgehensweisen: Ein möglicher Ablauf besteht darin, zwei bis drei Kollegen auszuwählen, die mit dem Code vertraut sind, und sie zu bitten, Gutachter zu sein. Ein anderer Ansatz, der vom Gitlab-Team erklärt wird, besteht darin, einen verketteten Überprüfungsablauf zu haben, bei dem der Autor einen Prüfer auswählt, der einen anderen Prüfer auswählt, bis mindestens zwei Prüfer mit dem Code einverstanden sind. Unabhängig vom gewählten Ablauf sollten Sie vermeiden, zu viele Prüfer zu haben . In der Lage zu sein, dem Urteil Ihrer Kollegen zu vertrauen, ist der Schlüssel zu einer effektiven und gesunden Codeüberprüfung.

Empathie haben

Das Erkennen verbesserungswürdiger Codeteile ist nur ein Teil einer erfolgreichen Codeüberprüfung. Genauso wichtig ist es, dieses Feedback auf gesunde Weise zu kommunizieren, indem Sie Empathie gegenüber Ihren Kollegen zeigen.

Bevor Sie einen Kommentar schreiben, denken Sie daran, sich in die Lage der anderen zu versetzen. Es ist leicht, beim Schreiben missverstanden zu werden, also überprüfe deine eigenen Worte, bevor du sie abschickst. Auch wenn ein Gespräch hässlich beginnt, lassen Sie sich davon nicht beeinflussen – bleiben Sie immer respektvoll. Gut mit anderen zu sprechen ist nie eine schlechte Entscheidung.

Wissen, wie man Kompromisse eingeht

Wenn eine Diskussion nicht schnell gelöst wird, führen Sie sie zu einem persönlichen Anruf oder Chat. Analysieren Sie gemeinsam, ob es sich lohnt, den aktuellen Änderungsantrag zu lähmen, oder ob es in einem anderen behandelt werden kann.

Seien Sie flexibel, aber pragmatisch und wissen Sie, wie Sie Effizienz (Lieferung) und Effektivität (Qualität) in Einklang bringen können. Es ist ein Kompromiss, den man als Team eingehen muss. In diesen Momenten stelle ich mir eine Codeüberprüfung eher als Iteration denn als endgültige Lösung vor. Es gibt immer Raum für Verbesserungen in der nächsten Runde.

Persönliche Codeüberprüfungen

Es kann sehr effektiv sein, den Autor und den Rezensenten in einem Paar-Programmierstil zusammenzubringen. Ich persönlich bevorzuge diesen Ansatz, wenn die Codeüberprüfung komplexe Änderungen beinhaltet oder die Gelegenheit für einen großen Wissensaustausch besteht. Obwohl dies eine Offline-Codeüberprüfung ist, ist es eine gute Angewohnheit, Online-Kommentare zu den durchgeführten Diskussionen zu hinterlassen, insbesondere wenn nach dem Meeting Änderungen vorgenommen werden müssen. Dies ist auch nützlich, um andere Online-Rezensenten auf dem Laufenden zu halten.

Lernen Sie aus den Ergebnissen der Codeüberprüfung

Wenn ein Code-Review viele Änderungen erlitten hat, zu lange gedauert hat oder bereits zu viele Diskussionen geführt hat, versammeln Sie Ihr Team und analysieren Sie die Ursachen und welche Maßnahmen daraus abgeleitet werden können. Wenn die Codeüberprüfung komplex ist, erleichtert das Aufteilen einer zukünftigen Aufgabe in kleinere Aufgaben jede Codeüberprüfung.

Wenn die Erfahrungslücke groß ist, ist die Einführung von Paarprogrammierung eine Strategie mit unglaublichen Ergebnissen – nicht nur für den Wissensaustausch, sondern auch für die Offline-Zusammenarbeit und -Kommunikation. Was auch immer das Ergebnis sein mag, streben Sie immer ein gesundes, dynamisches Team mit klaren Erwartungen an.

Als Autor

Eines der Hauptanliegen bei der Arbeit an einem Code-Review als Autor ist es, die Überraschung des Reviewers beim ersten Lesen des Codes zu minimieren. Das ist der erste Schritt zu einem vorhersehbaren und reibungslosen Code-Review. Hier ist, wie Sie es tun können.

Etablieren Sie eine frühe Kommunikation

Es ist nie eine schlechte Idee, mit Ihren zukünftigen Reviewern zu sprechen, bevor Sie zu viel programmieren. Wann immer es um einen internen oder externen Beitrag geht, könnte man am Anfang der Entwicklung gemeinsam eine Verfeinerung oder ein bisschen Pair Programming machen, um Lösungen zu diskutieren.

Es ist nichts Falsches daran, als ersten Schritt um Hilfe zu bitten. Tatsächlich ist die Zusammenarbeit außerhalb der Überprüfung ein erster wichtiger Schritt, um frühe Fehler zu vermeiden und eine erste Einigung zu gewährleisten. Gleichzeitig werden Ihre Reviewer auf eine zukünftige Codeüberprüfung aufmerksam gemacht.

Befolgen Sie die Richtlinien

Wenn Sie einen Pull-Request zur Überprüfung einreichen, denken Sie daran, eine Beschreibung hinzuzufügen und die Richtlinien zu befolgen. Dadurch ersparen sich die Prüfer Zeit, um den Kontext des neuen Codes zu verstehen. Auch wenn Ihre Rezensenten bereits wissen, worum es geht, können Sie diese Gelegenheit nutzen, um Ihre Schreib- und Kommunikationsfähigkeiten zu verbessern.

Seien Sie Ihr erster Rezensent

Wenn Sie Ihren eigenen Code in einem anderen Kontext sehen, können Sie Dinge finden, die Sie in Ihrem Code-Editor vermissen würden. Führen Sie eine Codeüberprüfung Ihres eigenen Codes durch, bevor Sie Ihre Kollegen fragen. Haben Sie eine Rezensenten-Mentalität und gehen Sie wirklich jede Codezeile durch.

Persönlich kommentiere ich gerne meine eigenen Code-Reviews , um meine Reviewer besser zu führen. Das Ziel hier ist es, Kommentare zu einem möglichen Mangel an Aufmerksamkeit zu verhindern und sicherzustellen, dass Sie die Beitragsrichtlinien befolgt haben. Versuchen Sie, eine Codeüberprüfung so einzureichen, wie Sie eine erhalten möchten.

Sei geduldig

Nachdem Sie eine Codeüberprüfung eingereicht haben, springen Sie nicht direkt in eine neue private Nachricht, in der Sie Ihre Prüfer bitten, „einen Blick darauf zu werfen, es dauert nur ein paar Minuten“ und sich indirekt nach diesem Daumen-hoch-Emoji sehnen. Der Versuch, Ihre Kollegen dazu zu drängen, ihre Arbeit zu erledigen, ist keine gesunde Denkweise. Vertrauen Sie stattdessen dem Arbeitsablauf Ihrer Kollegen, da sie darauf vertrauen, dass Sie eine gute Codeüberprüfung einreichen. Warten Sie in der Zwischenzeit darauf, dass sie sich bei Ihnen melden, wenn sie verfügbar sind. Betrachten Sie Ihre Rezensenten nicht als Engpass. Denken Sie daran, geduldig zu sein, denn schwierige Dinge brauchen Zeit.

Sei ein Zuhörer

Sobald eine Codeüberprüfung eingereicht wurde, werden Kommentare kommen, Fragen gestellt und Änderungen vorgeschlagen. Hier gilt die goldene Regel, Feedback nicht als persönlichen Angriff zu verstehen. Denken Sie daran, dass jeder Code von einer Außenperspektive profitieren kann .

Betrachten Sie Ihre Rezensenten nicht als Feind. Nehmen Sie sich stattdessen diesen Moment, um Ihr Ego beiseite zu legen, akzeptieren Sie, dass Sie Fehler machen, und seien Sie offen dafür, von Ihren Kollegen zu lernen, damit Sie beim nächsten Mal einen besseren Job machen können.

Als Rezensent

Planen Sie Ihrer Zeit voraus

Wenn Sie gebeten werden, ein Rezensent zu sein, unterbrechen Sie die Dinge nicht sofort. Das ist ein häufiger Fehler, den ich immer wieder sehe. Das Überprüfen von Code erfordert Ihre volle Aufmerksamkeit, und jedes Mal, wenn Sie den Codekontext wechseln, verringern Sie Ihre Produktivität, indem Sie Zeit mit der Neukalibrierung Ihres Fokus verschwenden. Planen Sie stattdessen im Voraus, indem Sie Zeitfenster Ihres Tages für Codeüberprüfungen zuweisen.

Ich persönlich ziehe es vor, morgens oder nach dem Mittagessen als erstes Code-Reviews durchzuführen, bevor ich andere meiner Aufgaben auswähle. Das funktioniert am besten für mich, weil mein Gehirn noch frisch ist, ohne einen vorherigen Codekontext, von dem ich abschalten kann. Außerdem kann ich mich nach dem Review auf meine eigenen Aufgaben konzentrieren, während der Autor den Code basierend auf dem Feedback neu bewerten kann.

Unterstützend sein

Wenn ein Pull-Request nicht den Beitragsrichtlinien entspricht, seien Sie unterstützend – insbesondere gegenüber Neulingen. Nehmen Sie diesen Moment als Gelegenheit, den Autor anzuleiten, seinen Beitrag zu verbessern. Versuchen Sie in der Zwischenzeit zu verstehen, warum der Autor die Richtlinien überhaupt nicht befolgt hat. Vielleicht gibt es Verbesserungsmöglichkeiten , die Ihnen vorher nicht bewusst waren.

Überprüfen Sie den Zweig und führen Sie ihn aus

Während Sie den Code überprüfen, lassen Sie ihn auf Ihrem eigenen Computer ausführen – insbesondere, wenn es sich um Benutzeroberflächen handelt. Diese Angewohnheit hilft Ihnen, den neuen Code besser zu verstehen und Dinge zu erkennen, die Sie möglicherweise übersehen, wenn Sie nur ein Standard-Diff-Tool im Browser verwendet haben, das Ihren Überprüfungsbereich auf den geänderten Code beschränkt (ohne den vollständigen Kontext wie in Ihrem Code-Editor zu haben). .

Fragen Sie, bevor Sie annehmen

Wenn Sie etwas nicht verstehen, scheuen Sie sich nicht, es zu sagen und Fragen zu stellen. Denken Sie bei der Frage daran, zuerst den umgebenden Code zu lesen und keine Annahmen zu treffen.

Die meisten Fragen passen in diese zwei Arten von Kategorien:

1. „Wie“-Fragen
   Wenn Sie nicht verstehen, wie etwas funktioniert oder was es tut, prüfen Sie mit dem Autor, ob der Code klar genug ist. Verwechseln Sie einfachen Code nicht mit Unwissenheit. Es gibt einen Unterschied zwischen schwer lesbarem Code und Code, dessen Sie sich nicht bewusst sind. Seien Sie offen für das Erlernen und Verwenden einer neuen Sprachfunktion, auch wenn Sie sie noch nicht genau kennen. Verwenden Sie es jedoch nur, wenn es die Codebasis vereinfacht.
2. „Warum“-Fragen
   Wenn Sie das „Warum“ nicht verstehen, scheuen Sie sich nicht, vorzuschlagen, den Code zu kommentieren, besonders wenn es sich um einen Grenzfall oder eine Fehlerbehebung handelt. Der Code sollte selbsterklärend sein, wenn es darum geht zu erklären, was er tut. Kommentare sind eine Ergänzung, um das Warum hinter einem bestimmten Ansatz zu erklären. Das Erklären des Kontexts ist sehr wertvoll, wenn es um die Wartbarkeit geht, und es wird jemanden davor bewahren, einen Codeblock zu löschen, der für nutzlos gehalten wurde. (Ich persönlich kommentiere den Code gerne, bis ich mich sicher fühle, ihn später zu vergessen.)

Konstruktive Kritik

Wenn Sie ein Stück Code finden, von dem Sie glauben, dass es verbessert werden sollte, denken Sie immer daran, die Bemühungen des Autors anzuerkennen, zum Projekt beizutragen, und sich auf empfängliche und transparente Weise auszudrücken.

• Offene Diskussionen.
  Formulieren Sie Ihr Feedback nicht als Befehl oder Anklage wie „Sie sollten…“ oder „Sie haben vergessen…“. Bringen Sie Ihr Feedback als offene Diskussion statt als obligatorische Bitte zum Ausdruck. Denken Sie daran, den Code zu kommentieren, nicht den Autor. Wenn sich der Kommentar nicht auf den Code bezieht, sollte er nicht in eine Codeüberprüfung gehören. Wie gesagt, sei unterstützend. Das Passiv zu verwenden, im Plural zu sprechen, Fragen oder Anregungen zu äußern, sind gute Ansätze, um die Empathie für den Autor zu betonen.
  

Statt „Diese Methode von hier extrahieren…“ bevorzugen Sie „Diese Methode sollte extrahiert werden…“ oder „Was halten Sie davon, diese Methode zu extrahieren…“

• Klar sein.
  Ein Feedback kann leicht falsch interpretiert werden, insbesondere wenn es darum geht, eine Meinung zu äußern, anstatt eine Tatsache oder eine Richtlinie zu teilen. Denken Sie immer daran, dies sofort bei Ihrem Kommentar zu löschen.

Unklar: „Dieser Code sollte … sein.“

Meinung: „Ich glaube, dieser Code sollte …“

Fakt: „Nach [unseren Richtlinien] sollte dieser Code … sein“.

• Erkläre warum.
  Was für Sie offensichtlich ist, ist es für andere möglicherweise nicht. Es ist nie zu viel, die Motivation hinter Ihrem Feedback zu erklären, sodass der Autor nicht nur versteht, wie man etwas ändert, sondern auch, welchen Nutzen es hat.

Meinung: „Ich glaube, dieser Code könnte …“

Erklärt: „Ich glaube, dieser Code könnte (…) sein, weil dies die Lesbarkeit verbessert und die Unit-Tests vereinfacht.“

• Geben Sie Beispiele.
  Wenn Sie eine Codefunktion oder ein Muster teilen, mit dem der Autor nicht vertraut ist, ergänzen Sie Ihren Vorschlag mit einer Referenz als Anleitung. Gehen Sie nach Möglichkeit über die MDN-Dokumentation hinaus und teilen Sie ein Snippet oder ein funktionierendes Beispiel, das an das aktuelle Codeszenario angepasst ist. Wenn das Schreiben eines Beispiels zu komplex ist, seien Sie unterstützend und bieten Sie persönlich oder per Videoanruf Ihre Hilfe an.

Sagen Sie nicht nur etwas wie „Die Verwendung von Filtern hilft uns bei [Motivation]“, sondern auch: „In diesem Fall könnte es so lauten: [Code-Snippet]. Sie können [ein Beispiel bei Finder.js] überprüfen. Im Zweifel kannst du mich gerne auf Slack anpingen.“

• Sei vernünftig.
  Wenn derselbe Fehler mehrmals gemacht wird, hinterlassen Sie lieber nur einen Kommentar dazu und denken Sie daran, dass der Autor ihn auch an den anderen Stellen überprüft. Das Hinzufügen redundanter Kommentare erzeugt nur Lärm und kann kontraproduktiv sein.

Behalten Sie den Fokus

Vermeiden Sie es, Codeänderungen vorzuschlagen, die nichts mit dem aktuellen Code zu tun haben. Bevor Sie eine Änderung vorschlagen, fragen Sie sich, ob dies in diesem Moment unbedingt erforderlich ist. Diese Art von Feedback ist besonders häufig in Refactors zu finden. Das ist einer der vielen Kompromisse zwischen Effizienz und Effektivität, die wir als Team eingehen müssen.

Wenn es um Refactoring geht, bevorzuge ich persönlich eher kleine, aber effektive Verbesserungen . Diese sind einfacher zu überprüfen und es besteht eine geringere Wahrscheinlichkeit, dass Codekonflikte auftreten, wenn der Zweig mit dem Zielzweig aktualisiert wird.

Erwartungen setzen

Wenn Sie ein Code-Review halb fertig hinterlassen, teilen Sie es dem Autor mit, damit die Zeiterwartungen unter Kontrolle sind. Teilen Sie dem Autor am Ende auch mit, ob Sie mit dem neuen Code einverstanden sind oder ihn später noch einmal überprüfen möchten.

Bevor Sie eine Codeüberprüfung genehmigen, fragen Sie sich, ob Sie mit der Möglichkeit einverstanden sind, diesen Code in Zukunft zu ändern. Wenn ja, ist das ein Zeichen dafür, dass Sie eine erfolgreiche Codeüberprüfung durchgeführt haben!

Erfahren Sie, wie Sie eine Codeüberprüfung ablehnen

Obwohl es niemand zugibt, muss man manchmal eine Codeüberprüfung ablehnen. In dem Moment, in dem Sie sich entscheiden, eine Codeüberprüfung zu akzeptieren, aber versuchen, sie zu überstürzen, wird die Qualität des Projekts sowie die Denkweise Ihres Teams beeinträchtigt.

Wenn Sie zustimmen, den Code einer anderen Person zu überprüfen, vertraut diese Person Ihren Fähigkeiten – es ist eine Verpflichtung. Wenn Sie keine Zeit haben, ein Gutachter zu sein, sagen Sie einfach nein zu Ihren Kollegen. Ich meine es ernst; Lassen Sie Ihre Kollegen nicht auf eine Codeüberprüfung warten, die niemals durchgeführt wird. Denken Sie daran, zu kommunizieren und die Erwartungen klar zu halten . Seien Sie ehrlich zu Ihrem Team und – noch besser – zu sich selbst. Was auch immer Sie wählen, tun Sie es gesund und richtig.

Fazit

Wenn Sie genügend Zeit und Erfahrung haben, werden Sie durch Code-Reviews viel mehr als nur technisches Wissen lernen. Sie lernen, Feedback von anderen zu geben und zu erhalten, sowie Entscheidungen mit mehr Überlegung zu treffen.

Jede Codeüberprüfung ist eine Gelegenheit, als Gemeinschaft und individuell zu wachsen. Denken Sie auch außerhalb von Code-Reviews daran, eine gesunde Denkweise bis zu dem Tag zu fördern, an dem es für Sie und Ihre Kollegen selbstverständlich wird. Denn Teilen macht uns besser!

Weiterführende Literatur zu SmashingMag:

• Zusammenarbeit: Wie Designer und Entwickler kommunizieren können, um bessere Projekte zu erstellen
• Bessere Zusammenarbeit durch Einbeziehung von Designern in den Code-Review-Prozess
• Welche Podcasts sollten Webdesigner und -entwickler hören?
• So erstellen Sie den perfekten Lebenslauf für Webentwickler