Viele Projekte, mit denen ich gearbeitet habe, große Projekte, wurden zu Vermächtnissen, einem enträtselten Bart, und infolgedessen wurde die Entwicklung äußerst schwierig. Es gab Fälle, in denen Projekte aufgrund der höllischen Schwierigkeit, Änderungen vorzunehmen, gerade gestorben sind. Heute erzähle ich Ihnen von meinen Erfahrungen mit der Arbeit mit Projekten und warum ich Ihnen das alles überhaupt schreibe. Natürlich ist alles sehr subjektiv.
Also arbeitete ich und versuchte es wie ein Seemann, der Wasser herausharken und verhindern will, dass das Schiff sinkt, aber die Qualität des Projekts nahm stetig ab, und es gab mehrere Gründe.
Sie werden sie leicht erkennen, sie sind regelmäßige Patienten, ich werde Sie nur daran erinnern:
- Die Architektur ist lahm, es ist schwierig, eine neue Lösung zu implementieren
- Codierungsfehler
- Es gibt keine automatischen Tests
Infolgedessen wird nach den Ergebnissen der Entwicklung des Projekts in den ersten 1-2 Jahren eine Mischung aus Vermächtnis, beschissenem Code, verworrenen Tunneln mit Geheimgängen und Felsmalereien erhalten, die "so funktioniert, warum ich nicht weiß".
Ich gehe nicht so viel darauf ein, dies ist das Hauptthema beim Refactoring, also direkt zu den Schlussfolgerungen, die ich gezogen habe.
Das entwickelte Produkt ist eine kollektive Expertise
Wenn das Team 1 Mega-Entwickler hat, der wirklich gepumpt ist und gut funktioniert, wird er es nicht alleine bereinigen, da das Team ständig Fehler macht und das Projekt ausnahmslos nach unten zieht.
Sie können natürlich versuchen, dem aktuellen Team eine Refactoring-Aufgabe zu geben, und dann werden diejenigen, die es geschweißt haben, ihr eigenes Arbeitsergebnis wiederholen und das Gleiche geben, na ja, vielleicht ein bisschen besser als beim ersten Mal.
Daher sollten Sie ohne ein Team-Upgrade kein radikales Qualitäts-Upgrade erwarten.
Dies ist ein Teufelskreis Nummer 1 - das Fachwissen des Teams reicht nicht aus, aber das Refactoring beginnt, und die gleichen Posons, die es geschrieben haben, tun es.
Alternativ können Sie einen guten Lead setzen, der eine Überprüfung durchführt und diese Fehler beseitigt (obwohl er es versuchen wird), aber am Ende wird es Kopfschmerzen für diejenigen geben, die schlecht arbeiten, und dann entweder den Ersatz der Entwickler oder sie werden gehen und wieder erhalten Sie einen Ersatz für Entwickler.
Es wird eine Art natürliche Selektion des Projekts sein.
Die Leute haben Angst, den Code zu ändern
Willkommen, dies ist eine Psychologie-Sitzung für Programmierer.
Programmierer haben wirklich Angst, den Code zu ändern, und sie können verstanden werden:
- Nicht genug Tests oder nicht
- Wie der Code funktioniert, ist nicht klar
- Die Daten sind am
- Keine Ressourcen
- Das Management wird es nicht verstehen (normal, aber wenn das Management in Flammen steht, ist alles in Ordnung)
Infolgedessen wird der alte verwirrende Legacy-Code, der das Projekt nach unten zieht, als "es ist besser, nicht zu berühren" wahrgenommen. Infolgedessen hält dieses "nicht berühren" für immer an und zwingt Sie, noch schlimmer, dazu, Code auf eine bestimmte Weise zu schreiben, was zu anderen technischen Problemen führt dann ziehen sie auch das Projekt nach unten.
Wir nehmen ein Projekt, einen beschissenen Code, die Ängste eines Teams, multiplizieren es mit der Zeit, und wir bekommen eine enorme technische Verschuldung, die direkt steigt und es dem Team nicht ermöglicht, das Projekt normal schnell zu bewegen und weiterzuentwickeln.
Das Projekt beginnt auseinanderzufallen, die Fristen werden unterbrochen, neue Funktionen werden für das Projekt extrem teurer, Entwickler werden nervös, einige gehen, neue sind schwerer zu finden, Sie haben die Idee ...
Ich denke, das ist Problem Nummer 1, Angst vor dem Code und Risiken.
Aus Erfahrung wurde festgestellt, dass wenn Sie technische Schulden hinterlassen, dies eine potenzielle Bombe oder zumindest ein Rechen ist. Lassen Sie sie 100, 1000, und Sie erhalten ein Minenfeld, auf das Sie nicht nur gehen (das Projekt entwickeln), sondern auch nicht kriechen können.
Daher ist die einzige Möglichkeit, die durchschnittliche Geschwindigkeit der Projektentwicklung zu sparen und die Qualität nicht zu beeinträchtigen, dank der Obergrenze, auf Qualität und Refactor zu achten.
Ratsfeuer, jeder weiß davon, aber tatsächlich ist die obige Liste nirgendwo hingegangen, so dass Sie es nicht einfach nehmen und umgestalten können, weil Sie ein Projekt bekommen, das auseinander fällt, und warum?
Da es keine Tests gibt, ist die Funktionsweise des Codes nicht klar, und als Ergebnis, anstatt die Zeichnungen und die Montage des Autos zu ändern, haben Vasya und Petya eine Mühle genommen, Solaris gesägt und nach Tavria zurückgebracht, aber es geht nicht. Warum? - oh, aber weil wir nicht über diesen Einfluss / dieses Verhalten / diese Aufgaben Bescheid wussten
Ja, Sie können ohne Tests umgestalten und dann stabilisieren, aber viele Benutzerskripte oder erforderliche Codeausführungsskripte können verloren gehen oder die Stabilisierung kann sehr lange dauern.
Daher noch ein Teufelskreis: Sie können den Code nicht alleine lassen, aber Sie können ihn auch nicht sozusagen umgestalten, da es enorme Risiken gibt.
Es stellt sich heraus, dass wir Legacy nicht brauchen, aber es ist beängstigend und gefährlich, es loszuwerden. Daher verlassen Teams Legacy oft als "am wenigsten gefährliche Option", um später eine noch gefährlichere Lösung für das Projekt zu erhalten.
Tests sind der Schlüssel
Es stellt sich heraus, dass Sie, um das Refactoring freizuschalten und sicher zu machen, zuerst alle Fälle mit Tests abdecken müssen. Wenn wir dann unser Solaris schneiden und es zu Tavria zusammenbauen, hört das Schweißen auf und sagt: "Hallo, wir brauchen ein Solaris, Sie haben es hier vermasselt."
Mit Tests können Sie Fehler beim Refactoring vermeiden, d. H. Um es sicher zu machen, können Sie das Projekt so schneiden, wie Sie es möchten und brauchen, ohne befürchten zu müssen, dass Risiken funktionieren und es Probleme gibt.
Daher erhalten wir eine Kette:
Tests -> Refactoring -> Auf Wiedersehen Bart und Vermächtnis
Es klingt einfach, schön, aber in der Praxis gibt es nur wenige Tests. Oder es passiert überhaupt nicht und es gibt wie üblich mehrere Gründe dafür:
- Entwickler betrachten Tests als separates Thema und investieren nicht in Bewertungen, sondern schreiben getrennt von der Entwicklung. Noch schwieriger ist es, wenn das Projektmanagement dies glaubt und Tests kürzen möchte, um die Fristen einzuhalten.
- Tests sind Zeit, und das Projekt muss jetzt übergeben werden. Es ist keine Zeit, Tests für uns zu schreiben (theoretisch ist dies dasselbe wie Punkt 1).
- Das Projekt / die Komponente ist einfach, warum gibt es Tests, alles ist extrem einfach und funktioniert dort?
- Zuerst schreiben wir den Code, dann decken wir ihn mit Tests ab. Aber nein, meine Hände haben nicht erreicht, das Projekt stand nicht still, es war keine Zeit. Diese Aufgabe liegt also für immer in der Black Box.
Es gibt tatsächlich eine Million Gründe, aber Tatsache ist, dass es das Refactoring blockiert und infolgedessen nicht zulässt, dass Qualität wächst.
Tests sind daher eine wichtige Aufgabe, und ohne sie wird die langfristige und qualitativ hochwertige Entwicklung des Projekts erheblich schwierig, wenn nicht unmöglich sein.
Was tun, Houston?
Ich schreibe diesen Artikel nur, weil nicht jeder das versteht, und es gibt zumindest jemanden, der ihn liest und Tests schreiben möchte, Refactor, was bedeutet, dass ich diesen Artikel nicht umsonst geschrieben habe.
Daher alle Hausaufgaben - nehmen Sie ein schlecht geschriebenes Modul, eine schlecht geschriebene Komponente, etwas, finden Sie dort das Refactor, schreiben Sie Tests für dieses Modul oder diese Komponente und refactor.
Als Ergebnis werden Sie verstehen, dass Tests sind:
- Ein Weg, um Code zu lernen. Es kann sogar viel effizienter sein, als es nur zu lesen.
- Stabilität
- Alter Code kann wirklich überarbeitet und die Qualität des Projekts verbessert werden
Ich habe alles in einem Atemzug geschrieben, sehr subjektiv, und vielleicht irre ich mich, das ist nur meine Erfahrung. Vielleicht bin ich nur auf solche Projekte gestoßen, ich weiß es nicht, aber die Informationen sind immer noch nützlich, und wenn Sie nach dem Lesen darüber nachdenken, ist dies auch gut.
Ich wünsche allen guten Code, Tests und Qualitätsbewegungen nach oben - deshalb werden wir eingestellt, lassen Sie uns gut arbeiten.
PS Wenn Sie möchten, schreiben Sie Ihre Refactoring-Erfahrung in die Kommentare, jeder wird interessiert sein.