Kein Startup beginnt mit einem Tester. Dann, zwei Jahre später, kann dieses Startup kein neues Feature für seinen größten Kunden aller Zeiten veröffentlichen, es sei denn, es schreibt das Ganze mit einem großen Knall neu. Es ist schmerzhaft, das immer und immer wieder anzusehen. Es gibt einfache Dinge, die Sie tun können, um die hygienische Qualität unserer Software aufrechtzuerhalten, damit Sie nicht in diese Situation geraten. Akzeptieren Sie zunächst Ihre Ängste. Ingenieure sind mutige Menschen, und wir geben nicht ohne weiteres zu, dass wir Bedenken haben. Aber wir haben es getan, und je früher wir diese Bedenken zugeben und teilen, desto eher werden wir uns darauf vorbereiten, uns ihnen zu stellen. Wie wir heute Software entwickeln Wir haben es so eilig, dass wir immer zu spät kommen. Es bleibt keine Zeit zum Testen. Für Unit-Tests bleibt keine Zeit. Es bleibt keine Zeit für Refactoring. Nun, wir werden nie genug Zeit haben, es richtig zu machen, während wir uns als Ingenieurteams weiterhin selbst sabotieren. Wir werden gefragt, wie lange es dauern wird, und wir schließen weiterhin Unit-Tests, manuelle Tests und sogar API-Tests und Refactoring aus unseren Schätzungen aus. Also erstellen wir Software wie diese: Schnell und dreckig Nicht schnell, immer noch dreckig Schneller und glücklicher diagonaler Weg getestet Alles andere gilt als Randfall. (Es gibt keinen Randfall.) Nur wenige von uns sind noch mutiger, „Nein“ zu „Quick or Dirty“ zu sagen und Software schnell und stabil zu entwickeln. Was Sie von Ihren Schätzungen abziehen sollten, ist der Umfang, nicht die Qualität. Was wissen Sie über die Qualität der Komponente, an der Sie arbeiten? Sie wissen, dass es zerbrechlich ist, aber Sie möchten es nicht berühren, weil es sehr zerbrechlich ist. Sie haben das schon vor langer Zeit gemacht, Sie berühren es kaum, es sollte funktionieren. Du weißt nicht, dass es zerbrechlich ist. Es gibt keine Tests und niemanden, der prüft und aufdeckt, wie zerbrechlich es tatsächlich ist. Haben Sie Freude daran, jeden Tag mit dieser schmutzigen Software umzugehen? Machen Sie jeden Tag gerne Kompromisse bei der Qualität Ihrer Arbeit, obwohl Sie wissen, dass diese alles andere als gut ist? Mit der Aussage „Wir haben keine Zeit zum Putzen“ zurechtzukommen und trotzdem zu spät zu kommen, weil es schmutzig ist und man unmöglich weitermachen kann, ohne es aufzuräumen. Sie stehen bei Ihrem nächsten Vorstellungsgespräch. Womit werden Sie in Ihrem aktuellen Job prahlen? Dass Sie auch unter Druck Leistung erbringen und bis spät in die Nacht Korrekturen durchführen können? Sie werden dich dafür lieben, aber sie werden dich auch fragen, warum du nichts dagegen unternommen hast. Vielleicht war es nicht deine Aufgabe. Stellen Sie sich vor, Es gab Teamleiter und technische Manager, die diese Entscheidungen trafen. Wenn es nach dir gegangen wäre, hättest du etwas getan. Sie haben ihnen gesagt, dass der Code überarbeitet werden muss und dass Sie bei jedem Retro-Vorgang Zeit für die Technikabteilung einplanen müssen, aber niemand hat zugehört. Nun, wissen Sie was – Sie brauchen keine Erlaubnis. Die Qualität Ihrer Arbeit hängt nur von Ihnen ab. Niemand kann Sie zwingen, beschissenen Code zu schreiben. Zeitdruck ist eine kurzfristige Ausrede. Schnelle und schmutzige Lösungen verzögern das gesamte Projekt und kosten mehr, als wenn man es gleich beim ersten Mal richtig macht. Sie werden es später nie mehr reparieren Sind Sie bereit, diesen Unterschied zu machen? Dann ist Folgendes zu tun: Seien Sie diszipliniert. Es tut mir leid, aber es gibt keinen anderen Weg. Und das sollte auf allen Ebenen der Fall sein. Was sollten Ihre ersten Schritte zur Erstellung von Code mit höherer Qualität sein? Implementieren Sie Protokollierung und Warnungen Es gibt unzählige Tools zur Protokollierung und Warnung. Dies ist das Erste, was zu tun ist. Ihre Software stürzt ab und Sie merken es überhaupt nicht. Finden Sie eine Lösung, mit der Sie ganz einfach Tickets aus Ausnahmewarnungen erstellen und diese als „bekannt“ markieren oder nach der Meldung gruppieren können. Erstellen Sie eine Teamroutine, um die Warnungen zu beobachten und zu melden Wenn Sie denken, dass es langweilig ist, möchte ich Sie fragen: Sind Sie während Ihres gesamten Arbeitstages tief in der Zone? Nach all den Meetings und der schweren Programmierarbeit müssen Sie Ihre Konzentration ein wenig lockern. Nun, das Durchsuchen des Benachrichtigungskanals ist viel besser als das Durchsuchen jedes anderen Kanals. Klicken Sie einfach auf die Schaltfläche „Ticket melden“ oder auf die Schaltfläche „Als bekannt markieren“. Und wenn Sie neugierig wären, würden Sie wahrscheinlich ein oder zwei davon reparieren. Hier kommt das größte Argument: Wir können ein paar reparieren, aber wir schreiben Tests, die jemand bestätigen muss, die wir bereitstellen müssen, und das erzeugt mehr ungeplante Arbeit für das Team. Der Premierminister wird uns anschreien, dass wir nicht an den Punkten mit hoher Priorität arbeiten, sondern kleine Warnungen überarbeiten. Darüber ist sich das Team mit allen „M“-Rollen einig. Veröffentlichen Sie eine Faustregel: „Wenn es klein und risikoarm aussieht und absolut keine anderen Arbeiten in Arbeit sind, machen Sie es einfach und beheben Sie es.“ Wir können pro Sprint ein oder zwei kleine Alarme bearbeiten, die „außerhalb des Rahmens“ behoben wurden.“ , zusammen mit den geplanten.“ Das ist es, ganz einfach. Beginnen Sie mit der Bereinigung der Protokolle und Warnungen nacheinander Planen Sie neben den gelegentlichen Korrekturen auch die Aufräumarbeiten richtig. Beachten Sie, dass ich mit Planung die Zuweisung täglicher/wöchentlicher Zeit für die Behebung dieser Probleme meine . Sie verschwenden mehr Zeit damit, ihre Priorität zu bewerten, als die ersten 5 zu reparieren. Beginnen Sie also einfach mit der Reparatur. , unabhängig von ihrem Schweregrad oder ihrer Priorität Stellen Sie sicher, dass es für jeden Entwickler eine Benachrichtigung gibt. Wenn Sie die meiste Zeit mobben, legen Sie ein tägliches Zeitfenster für Benachrichtigungen fest. Und ich würde es gleich am Morgen tun, weil man es sonst nie tun würde. Auch hier handelt es sich nicht um eine neue Funktion, und es könnte den Anschein haben, als würde sie die Zeit Ihrer kritischen Prioritäten verschlingen, aber Ihre kritischen Prioritäten sind aufgrund dieser versteckten Probleme bereits zu spät. Du bist schon zu spät! Entfernen Sie alle leeren Try-Catch-Anweisungen und lassen Sie es abstürzen! Während durch Warnungen und Protokollierung vieles offengelegt wird, können sie nicht protokollieren, was Sie verbergen. Hören Sie also auf, Ihre Probleme unter den Teppich zu kehren. Was vor 2 Jahren abgestürzt ist und man nicht wusste warum, ist heute ganz anders. Lass es abstürzen und repariere es. Es wird wahrscheinlich nicht einmal auf die gleiche Weise abstürzen, oder es stürzt nicht einmal ab, also wird Ihr Code auf die eine oder andere Weise ohne diese in einem besseren Zustand sein. Beginnen Sie jetzt mit dem Schreiben von Unit-Tests Ich meine es. Sie arbeiten gerade an Code. Dann hält Sie nichts mehr davon ab, einen Unit-Test zu schreiben. Oh, ich verstehe! Es gibt keine Infrastruktur, die für Unit-Tests bereit ist, oder? Aufleuchten! Du wirst dieses Möchtegern-Feature sowieso verzögern. Sie benötigen nicht mehr als einen Tag, um das Unit-Test-Framework und Ihr CI zum Ausführen der Tests einzurichten. Tun Sie es einfach. Starten Sie TDD für Fehlerbehebungen „Wir wissen nicht, wo das Problem liegt und wie wir es beheben können. Wir können keine Tests für Code schreiben, der noch nicht existiert.“ Mein lieber Entwickler, der Zweck des Testens besteht darin, eine Hypothese zu überprüfen. Das gilt für Tests im Allgemeinen, nicht nur für Softwaretests. Wofür Sie also einen Test schreiben müssen, ist nicht der Code. Sie benötigen das erwartete Verhalten und Ergebnis. Wenn User Stories vage und unklar sind und Sie noch nicht bereit sind, Tests anhand der User Stories zu schreiben, habe ich auch hierfür eine Lösung, aber vorher sollten Sie mit dem Schreiben von Test-First-Code für Fehler beginnen. Es gibt eine Komponente der Fehlerbeschreibung namens „Erwartetes Ergebnis“, und die zu reproduzierenden Schritte sind Ihr Testfall. Sie haben also bereits den Testfall vor sich. Codieren Sie es nun zuerst, bevor Sie mit dem Codieren des Fixes beginnen. Bei der testgetriebenen Entwicklung wird ein Test geschrieben, der bestätigt, dass Sie die richtige Arbeit geleistet haben, und nicht, dass Sie sie richtig gemacht haben. Unit-Tests überprüfen, ob Sie es richtig gemacht haben. Zeichnen Sie eine Abdeckungs-Roadmap Testautomatisierung und Tech-Schulden haben ein ähnliches tragisches Schicksal – sie werden nie in Angriff genommen, weil „wir nie alles abdecken können, wir können nie alles bereinigen, es ist ein zu großer Aufwand. Dafür haben wir keine Zeit.“ Hören Sie mir zu: Sie müssen nicht alles automatisieren! Aber Sie müssen auf jeden Fall Ihre geschäftskritischen Elemente automatisieren – Anwendungsfälle mit hoher Priorität, kritische Infrastruktur und Kernfunktionen. Nennen Sie es, wie Sie möchten, aber das Unternehmen verlässt sich auf 20 % Ihres Codes und Ihrer Infrastruktur, und Ihre Kunden nutzen 20 % Ihrer Funktionen. Sie sehen, wohin ich damit will. Sie müssen jetzt noch nicht einmal damit beginnen, automatisierte Tests für diese Funktionen zu schreiben. Zunächst müssen Sie sie priorisieren. Treffen Sie sich als Team vor Ihren High- und Low-Level-Architekturdiagrammen. Es gibt keine, oder? Oder handelt es sich bei den vorhandenen um ein Foto eines Whiteboards, das vor 2,5 Jahren aufgenommen wurde? Ich weiß. Ja, Sie müssen einen halben Tag damit verbringen, diese auf den neuesten Stand zu bringen. Die gute Nachricht ist, dass es unterhaltsame Tools gibt, die Ihnen dabei helfen, sodass Sie es nicht manuell pflegen müssen. Recherchiere. Sie sind schließlich ein F&E-Team, oder?! Streben Sie nicht nach vollständiger Abdeckung, sondern streben Sie stattdessen nach geringem Risiko und hohem Vertrauen Fügen Sie beim Diagramm Ihrer aktuellen Architektur und Infrastruktur Notizen oder Kreise hinzu oder fetten oder zeichnen Sie alle Stellen rot aus, die: Von entscheidender Bedeutung für Ihr Unternehmen und Ihre Software Sie benötigen dringend eine Umgestaltung, sonst verschieben Sie diese andere geschäftskritische Funktion ständig. Ständig kaputt zu gehen und die Zeit zu verschlingen, sie zu reparieren, ist ziemlich vergeblich, weil sie in ein paar Tagen wieder kaputt gehen. Wenn die Zeichnungen fertig sind, setzen Sie sich mit Ihrem Team zusammen und überlegen Sie, was für all diese eingekreisten Komponenten getestet werden muss. Tappen Sie nicht in die Falle: „Das ist zu viel! Wir müssen alle anderen Arbeiten einstellen, um das alles abzudecken!“ Sie müssen nicht alles auf einmal abdecken. Aber Sie brauchen einen Plan. Öffnen Sie nun ein weiteres Forum und beginnen Sie mit dem Schreiben Ihrer Testziele. Beispiele: Decken Sie alle API-Anfragen zum Abrufen von Daten auf Erfolg und Misserfolg ab, damit Sie sicher sein können, dass Sie keine fehlerhaften Anfragen senden, und wenn sie fehlschlagen, scheitern sie am Anbieter. Skizzieren Sie die geschäftskritische Benutzerreise. Teilen Sie es in Einheiten auf. Schreiben Sie die Unit-Tests. Als die Testpyramide erfunden wurde, bedeutete eine Einheit eine Komponente, nicht eine Methode, sodass sie die Funktionalität abdeckte, nicht Methoden und Klassen. Identifizieren Sie die Staus und entscheiden Sie, wie Sie sie entwirren möchten. Planen Sie, es richtig zu machen. Ihr Quick-and-Dirty-Code bleibt durch Dirty-Tests schmutzig. Ich habe absichtlich eine Abdeckungskarte und nicht die Testpyramide verwendet, weil ... zu diesem Zeitpunkt, wenn Sie keine manuellen oder automatisierten Tests durchgeführt haben, Sie nicht für die Pyramide bereit sind. Viele Teams haben den falschen Eindruck, dass sie zunächst eine Unit-Test-Abdeckung von 96 % erreichen müssen und dann mit den Integrationstests usw. fortfahren müssen. Das Problem bei der modernen Unit-Test-Abdeckung besteht darin, dass wir Methoden und Klassen testen, nicht Funktionalitäten. Noch mehr Teams beginnen mit der UI-Automatisierung, was ebenso falsch ist. Das ist tatsächlich das Schlimmste, was man tun kann, und es ist zum Scheitern verurteilt. Beginnen Sie also nicht am oberen oder unteren Ende der Pyramide, sondern erstellen Sie stattdessen eine Risikokarte. Einige Funktionen erfordern möglicherweise umfassende Integrationstests, andere erfordern möglicherweise umfangreiche UI-Tests, und der nächste Teil könnte tatsächlich eine Kernfunktion sein, von der alles abhängt (allerdings ein weiteres Warnsignal), und Sie müssen sie von oben bis unten vollständig abdecken. Oder es handelt sich um einen Datenerfassungsdienst, bei dem Sie sich beispielsweise auf die Leistung der APIs konzentrieren müssen. Erstellen Sie eine Karte Ihrer Software-Hotspots, die umfangreiche Tests erfordern. Denken Sie dann darüber nach, wie Sie diese Tests automatisieren können. Im Treibsand kommt man nicht weiter und nur man selbst kann da wieder herauskommen Lass es uns einwickeln. Wenn Sie die Hälfte Ihres Lebens damit verbringen, an einem Ort ohne Tests zu arbeiten, der Code in einem schlechten Zustand ist und Sie keine Zeit haben, gehen Sie ständig Kompromisse ein, weil „Sie keine Zeit haben“. Du bist nicht ganz zufrieden oder zumindest ziemlich gleichgültig – sie zahlen, es ist ihre Entscheidung und es ist nicht deine Entscheidung. Das ist einfach traurig. Ich bin mir sicher, dass Sie nicht stolz auf Ihren Job sind. Und vielleicht warten Sie sogar darauf, dass das nächste Einhorn Sie rekrutiert, weil Ihnen der Job und die Sache gefallen werden. Nun ja, letztes Jahr hat sich einiges verändert, nicht wahr?! Wir haben wieder einmal gelernt, dass es keine Einhörner gibt. Sie müssen ein herausragender Entwickler sein, um eingestellt zu bleiben. Die Unternehmen haben herausgefunden, dass sie Menschen unabhängig von ihrem Beitrag wegwerfen können. Dennoch gibt es Ingenieure, für deren Erhalt ein Unternehmen alles tun wird. Um einer von ihnen zu sein, müssen Sie den Wandel vorantreiben und ständig beweisen, dass das Unternehmen von Menschen wie Ihnen abhängt. Jeder kann schlechte Software schreiben, aber die wirklich Guten schreiben nicht nur mit Freude exzellente Software, sondern inspirieren auch andere und verbreiten die Kultur der Codequalität. Im Treibsand kommt man nicht weiter und nur man kann sich selbst herausziehen.

Dieses Audio ist in der Originalsprache der Geschichte produziert!

Zu lang; Lesen

Making security fun one episode at a time

Sie werden es später nie mehr reparieren – So ziehen Sie Ihr Team aus dem Treibsand

Zu lang; Lesen

Hris Koleva

About Author

Hängeetiketten

Languages

DIESER ARTIKEL WURDE VORGESTELLT IN...

Sie werden es später nie mehr reparieren – So ziehen Sie Ihr Team aus dem Treibsand

Zu lang; Lesen

Hris Koleva

About Author

Hängeetiketten

Languages

DIESER ARTIKEL WURDE VORGESTELLT IN...

ÄHNLICHE BEITRÄGE