Lassen Sie uns die Methoden der Softwareerstellung durchgehen, die in etwa 70 Jahren ihres Bestehens erfunden wurden. Es gibt nicht so viele, wie es scheint. Aber genug, um ratlos zu sein.
Sprichwort
Der Mensch ist von Natur aus anpassungsfähig. Sie gehen zum Beispiel in die Küche, wo sich Hühnchen auf dem Grill dreht. Der Duft trifft die Nase und wenn Sie hungrig werden, werden Sie sogar Speichelfluss. Nach ungefähr fünf Minuten hören Sie auf zu riechen. Das einzige, was an Essen erinnert, ist ein Stück Fleisch, das sich mit ausgebreiteten Flügeln hinter dem Glas des Ofens dreht. Der Geruch ist immer noch da, Sie können ihn messen, aber die Informationen von den Rezeptoren werden vom Gehirn blockiert.
Dies geschieht überall, und Software-Engineering ist keine Ausnahme. Wir beginnen mit „wunderbaren Entdeckungen“, die „der Geist der Erleuchtung für uns vorbereitet“, und gehen reibungslos zu Routine, Scham und Gedränge, Sprints, Minzkapselung, Polymorphismus-Nationalität und, oh Scheiße, ein Stück Fleisch über Drehen im Ofen, droht trotz regelmäßiger Materialstimulation über dem Krankenhausdurchschnitt bis zum Ende zu brennen.
In den 1960er Jahren stellte ein neugieriger Mann namens Richard B. Doss fest, dass in Amerika, gesättigt mit protestantischem Workaholismus, 70-80% der Menschen weit unter ihrer Arbeitsfähigkeit arbeiten. Darüber hinaus kann ein Proteinarbeiter im Gegensatz zu einem Robotermanipulator schnell durchschneiden. Die Studien wurden in "Null" und "Zehntel" mit dem gleichen Ergebnis wiederholt. Eine solche Situation wirkt sich auf die Gesundheit aus, um es milde auszudrücken, es spielt keine Rolle.
Der Zweck des Textes besteht nicht darin, Sie von unzureichender Produktivität abzubringen oder Ratschläge zu geben. Wir werden nur kurz auf die Methoden der Softwareerstellung eingehen, die in etwa 70 Jahren ihres Bestehens erfunden wurden.
Drei Wege
Ich werde nicht am Gummi ziehen, ich werde mit der Hauptsache beginnen. Es gibt nur drei Möglichkeiten, Software zu entwickeln. Ja, drei ist eine gute Zahl, schön. Also:
Top-Down-Methode . Dies ist der Fall, wenn sie zuerst global überlegen, was zu tun ist, dann, wie es zu tun ist, und dann tun sie es, wenn noch Zeit übrig ist.
Aufsteigender Weg . Dies ist der Zeitpunkt, an dem sie es nach und nach in kleinen Teilen tun. Sie denken "was, ja wie" nur über diesen Teil, ohne sich um das Globale und Dauerhafte zu kümmern.
Spiralweg . Wir fangen an, global zu denken, aber wenn der Alarm ertönt, wachen wir auf und rollen den Prototyp aus. Und so mehrmals Erfahrungen sammeln, bis eine Lösung entsprechend den Anforderungen erscheint.
Top-Down-Entwicklung
Im allgemeinen Sprachgebrauch werden alle Top-Down-Methoden als „Wasserfälle“ bezeichnet. Wenn Ihnen bereits von der Existenz mehrerer Ajiles berichtet wurde, sollte eine solche "Einfachheit schlimmer als Diebstahl" Verdacht erregen.
Der Abstieg der Methode zu den Massen erfolgt in den 1960er Jahren und ergänzt organisch die Anforderungen der strukturierten Programmierung zum Händewaschen vor dem Essen und zur Verwendung von Besteck und Servietten. Die globale Aufgabe wurde in kleinere Unteraufgaben unterteilt, die wiederum in noch detailliertere Aufgaben unterteilt sind, und zwar bis zur Ebene eines Strukturblocks, der direkt in einer Programmiersprache implementiert werden kann. Tests für diese Blöcke werden übrigens parallel geschrieben, hallo zu TDDs aus den 1960er Jahren.
Das russische Sprichwort „Siebenmal messen - einmal schneiden“ handelt von der Top-Down-Methode.
In der orthodoxen Version des "Wasserfalls" erfolgt die Rückmeldung des Kunden erst nach erfolgter Lieferung. Wir haben ein Jahr lang gearbeitet, das Klavier aus dem Gebüsch gerollt, es hat sich als "nicht ganz richtig" herausgestellt, einige Feinarbeiten sind erforderlich. Inzwischen hat der Kunde eine lange Liste neuer Funktionen ins Leben gerufen. Es ist ein wenig dumm, nicht daran gewöhnt zu sein, in einem solchen System zu arbeiten. Daher ist es in einer humanen Version möglich, von jedem Punkt zur vorherigen Stufe zur Klärung zurückzukehren, was zu einer "Kaskade mit Rückgaben" führt.
Die Vorteile der Methode liegen auf der Hand. Je durchdachter am Anfang, desto weniger unnötige Arbeit muss in der Mitte und am Ende geleistet werden. Mehrfache Neuerfindungen von Fahrrädern, doppelte Funktionen und Fehler sind ausgeschlossen.
Wenn es jedoch anfangs viele Funktionen gibt, ist es nicht einfach, die richtige Aufteilung zu gebären. Wir brauchen gute Analysten, Designer mit Erfahrung in diesen Themenbereichen. Und selbst in diesem Fall besteht die Gefahr, dass die Implementierungsplanung um einen unanständigen Zeitraum verzögert wird.
In Zukunft wurde die Methode wiederholt verbessert, beispielsweise die V-Methode , bei der die Entwicklungsstufen entlang der linken Steigung des Buchstabens "V" den Stufen der Tests und der Akzeptanz des Aufstiegs auf der rechten Seite entsprechen. Die horizontale Ebene zeigt sofort, welches Projektdokument des Auftragnehmers als Grundlage für das Abnahmeformular des Kunden dient.
Es ist klar, dass Verbesserungen die grundlegenden Einschränkungen der Methode nicht überwinden können. Deshalb sind sie prinzipiell. Dies bedeutet nicht, dass die Methode schlecht ist. Er hat nur Risiken dieser Art. Wenn Sie die Risiken abwehren können, ist alles in Ordnung. Wir denken nach und genießen die Vorteile auf dem Weg.
Upstream-Entwicklung
Tatsächlich ist die aufsteigende Methode sogar älter als die absteigende. In den 1950er Jahren existierten sowohl Fortran als auch Cobol bereits, aber es gab keine klare Vorstellung davon, wie Software erstellt werden sollte. Deshalb haben wir auf natürlichste Weise gehandelt: Heute werden wir eine Sache tun, morgen eine andere, und eines Tages werden wir sie in eine dritte kleben. Wenn Sie mehrere Aufgaben implementieren müssen, wählen wir die wichtigsten aus.
Manchmal wird die Methode auch als inkrementell bezeichnet, anscheinend in Analogie zu
i++
. Funktionsinkrement hinzugefügt. Wenn Sie den Globus auf die Mercator-Projektion strecken möchten, können Sie die Spiralmethode auch als inkrementell bezeichnen, aber dazu später mehr. Sie stellen die Methode auch gerne in Form eines Zyklus dar, obwohl für
i++
Die endgültigen Werte sind nicht definiert, daher müssen Sie von hier aus bis zur Mittagszeit "graben". Wenn wir das Thema der russischen Sprichwörter fortsetzen, haben wir das Sprichwort „dreht sich wie ein Eichhörnchen in einem Rad“ - hier geht es nur um die aufsteigende Methode.
Die Technik war und ist die typischste für die Eigenentwicklung. Ihre Programmierer müssen gestern das tun, was das Geschäft braucht. Um globaler zu denken, entstanden in den 1960er Jahren "Softwarehäuser" - große Designbüros für die Entwicklung kundenspezifischer Systeme, einschließlich Monster wie IBM .
All diese Aufwärtsentwicklung der Software wurde bis in die 1990er Jahre ohne wesentliche Änderungen fortgesetzt. Der Hauptkampf, um akademische Theorien mit der Ingenieurpraxis in Einklang zu bringen, hat den sicheren Hafen umgangen, weil er im Dschungel der Top-Down- und Spiralmethoden ausgetragen wurde.
In den neunziger Jahren gab es einen starken Trend, "Heim" -Programmierer durch externe Berater zu ersetzen. Einer der Gründe ist die Komplikation von Technologien und Spezialisierung, die innerhalb des Unternehmens, für das Software-Engineering eine nicht zum Kerngeschäft gehörende Aktivität ist, schwer zu erreichen ist. Heimsoftware wird jetzt von temporären Teams entwickelt
In einer solchen Situation erscheint wiederum eine einfache Funktion-für-Funktion-Methode angemessen. Die Arbeit mit einem Tageslohnunternehmen erfordert jedoch mehr Aufsicht als Vollzeitbeschäftigte. Der Ansatz muss angepasst werden, um bürokratische Verfahren zu vermeiden. In der Tat müsste man auf formale Top-Down- oder Spiralmethoden umsteigen, um "das Mandat herauszugeben", die eine allgemeine Planung und relevante Dokumente erfordern, dh vollensnolens. Und warum braucht es zum Beispiel ein Transportunternehmen oder ein Autohersteller? Die Leute wollen nur ein kleines internes Problem lösen, das Gehalt dort berechnen oder den Urlaubsplan reduzieren.
Nachfrage schafft Angebot, Ende der neunziger Jahre erschienen die sogenannten agilen Methoden, die es dem Kunden zumindest ermöglichten, am Puls der Zeit zu bleiben, und der Auftragnehmer verstand allmählich, was sie tatsächlich umsetzten.
Was ist verbessert:
- Die Planung ist noch kurz, deckt jedoch mehr als eine Funktion und ihre Gruppe ab, während die Laufzeit der Bühne streng begrenzt ist.
- es wird aufgezeichnet, was getan wurde;
- Theoretisch sollte Zeit zur Vereinfachung und Bereinigung des Codes bereitgestellt werden (Refactoring).
- Theoretisch sollten den Regressionsrisiken mit umfassenden Tests begegnet werden.
Warum schreibe ich "theoretisch"? In der Praxis werden diese beiden Punkte in erster Linie geopfert, wenn das Budget begrenzt ist oder Zeitprobleme auftreten. Die "heilige Kuh" in Ajiles ist nicht die Qualität des Codes, wie die Autoren beabsichtigt hatten, sondern die Frist für die nächste Funktion.
Vervielfältigung von Code, unnötige Komplikationen, Verschiebung "für spätere" ineffektive Implementierungen - Wenn Sie nicht bereinigen, was zuvor getan wurde, steigt die technische Verschuldung. Je später die Schulden zurückgezahlt werden, desto mehr müssen Sie am Ende bezahlen: Zeit, Manntage, Fehler, Misserfolge, langsame Arbeit usw.
Nach etwa 10 bis 15 Jahren begannen die Autoren des "Ajaila-Manifests" Alarm zu schlagen : "Leute, was machst du, wir haben etwas anderes gemeint." Sie sind etwas korrekt, die Bottom-up-Entwicklung ist so einfach und so überzeugend, dass all diese zusätzlichen Verfahren unnötig erscheinen.
Lassen Sie uns zusammenfassen, was an der Bottom-up-Entwicklung gut ist. Zunächst wird die Eintrittsschwelle stark reduziert. Um bei Null anzufangen, sind keine teuren Experten für Analyse und Design mit Erfahrung erforderlich. Obwohl der gesamte Bau unbegrenzt dauern kann, werden bald die ersten Baracken errichtet, in denen Sie sich niederlassen können. Es ist einfacher, den Prozess zu verwalten, Kontrollpunkte und lokale Ziele sind transparent.
Die Probleme, wie im Fall von „Wasserfällen“, sind von grundlegender Bedeutung. Es ist einfacher, den Prozess zu verwalten, aber fast unmöglich - das Endergebnis, da es nirgendwo eindeutig aufgezeichnet wird. Die Risiken werden an den Kunden weitergegeben: Lassen Sie den Produktbesitzer glauben, er habe einen großen Kopf. Wenn das Team mit Erfahrung, Tests und Refactoring (bis zu einer bestimmten Komplexitätsschwelle) mit der technischen Architektur fertig wird, ist die funktionale Architektur schlecht. Die Vereinfachung der Problemstellung, das eigentliche "Refactoring", jetzt das Domänenmodell, würde dazu beitragen, den ausgefallenen und teuren Code, der gewartet werden muss, loszuwerden, aber es gibt niemanden, der ihn erstellt. Und es gibt kein Modell, um ehrlich zu sein, die gesamte Semantik befindet sich in den Köpfen und im Code.
Aber es gibt keinen Grund, sich aufzuregen. Denken Sie an den katastrophalsten Sprint der Weltgeschichte: 5 Tage Schöpfung und eineinhalb Milliarden Jahre kontinuierliches Refactoring.
Spiraltechnik
Die oben genannten „Wasserfall“ -Beschränkungen wurden bereits in den 1970er Jahren nach der massiven Implementierung der entsprechenden Methoden wie SADT / IDEF deutlich . Gleichzeitig haben wir an Bottom-up-Methoden für „Heim“ -Projekte mit anderen Problemen gearbeitet, wodurch das Gefühl einer Sackgasse entstand. Daher verwirrten die Forscher das Problem (vor allem Barry Boehm ), kratzten sich an den Rüben und gaben Mitte der 1980er Jahre eine aktualisierte Vision des Software-Erstellungsprozesses in Form einer Spirale heraus .
Die Logik der "spiralförmigen" Argumentation ist ungefähr wie folgt. Ja, mit zunehmender Komplexität der Aufgaben verbringen wir immer mehr Zeit mit Analyse und Design. Das Fehlerrisiko in dieser Phase steigt. Bei der Implementierung einzelner Funktionen ohne allgemeinen Plan riskieren wir jedoch nicht weniger Fehler und erhalten ineffektive oder einfach inkompatible Teile. Daher werden wir das "Holy Cow" -Design in Ruhe lassen, aber a) wir werden den Zeitrahmen dafür begrenzen und b) wir werden die getroffenen Entscheidungen streng überprüfen und einen vollständigen Prototyp herausbringen.
Punkt "b" ist sehr wichtig. Mit der Bottom-up-Entwicklung produzieren Sie auch ständig etwas, Fehlerbehebungen und neue Funktionen. Es funktioniert jedoch, wenn das System bereits in Betrieb ist und gewartet wird. Und wenn nicht? Stellen Sie sich vor, ein Kunde möchte ein Zugverkehrskontrollsystem und in ein paar Wochen zeigen Sie ihm Bildschirme zur Eingabe von Informationen über das rollende Material und einen Fahrplansimulator. Nicht ernsthaft.
Der Prototyp sollte die meisten Funktionen enthalten, auch wenn sie nicht vollständig implementiert sind oder sogar mit "Stubs". Vom vollständigen Prototyp erhalten wir jeweils ein vollständiges Feedback: Hier haben sie es vermasselt, das Wesentliche der Anforderungen nicht verstanden, sie haben die Betriebsumgebung nicht berücksichtigt, dort stimmt das Ausgabeformat nicht mit dem Eingabeformat überein usw. Mit diesem wertvollen Feedback beginnen wir die zweite Runde der Spirale und gehen davon aus, dass die Chance groß ist, den nächsten Prototyp auf das Niveau eines fertigen Produkts zu bringen. Für mittelgroße Systeme (ungefähr bis zu einer Million Codezeilen) reichen zwei oder drei Iterationen aus.
Aus dem Gesagten geht hervor, dass es genauso lächerlich ist, die Spirale inkrementellen Methoden zuzuschreiben, wie Wale zu fischen, obwohl beide Schwänze haben.
Was ist gut an der Spirale? Wir reduzieren das Risiko einer Einführung beim Kunden anstelle eines Produkts drastisch, um ehrlich zu sein, aber gleichzeitig opfern wir nicht das Design. Das heißt, die globale Vision der Situation bleibt bestehen, das Endergebnis kann durch Berechnung des Budgets und des Gewinns verwaltet werden. Jeder, Kunde und Auftragnehmer, kann das Licht am Ende des Tunnels sehen. Der Kunde, wenn er seine Absichten ernst meint, wird auch nicht brüllen: "Warum ziehst du meinen Schwanz an und ziehst dann meinen Rüssel aus, zeig mir den ganzen Elefanten!" In jeder Runde ist der gesamte Elefant sichtbar.
Im Vergleich zum zunehmenden Software-Engineering ist es jedoch unmöglich, einen Zug von Programmierern und Technikern ohne Analysten und Designer zu verwalten, und Sie müssen dem Kunden diesen heiklen Moment erklären, um einen höheren Preis zu rechtfertigen. Nach der Entwurfsphase der ersten Runde stehen die Spezialisten nicht untätig, sondern beißen weiter in die Aufgabe und warten auf Feedback, aber in der letzten Runde werden sie höchstwahrscheinlich überhaupt nicht benötigt. Die Länge der Spule kann bis zu mehreren Monaten betragen, kostet aber normalerweise zwei bis drei. Es sieht nicht wie ein wöchentliches Sprint-Extrem aus, aber es sieht auch nicht wie eine jährliche Erwartung an ein Produkt aus. Es ist auch nicht einfach zu entscheiden, wann in diesem Stadium „es reicht zu entwerfen“ und es Zeit ist, mit dem Verlegen von Ziegeln zu beginnen.
Die bekannteste und erfolgreichste Implementierung der Spiraltechnik - MSF(Microsoft Solution Framework). Microsoft hatte später eine beschnittene Version, die für Bottom-up-Methoden geschärft und als MSF für Agile für relativ kleine Projekte und Teams vermarktet wurde.
Anstelle eines Nachworts
Opa Brooks hat in seinem Bestseller vier Arten von Software beschrieben, die die Leute entwickeln.
Das Bild zeigt, dass Sie irgendwann aufhören können, „nur ein Programm zu schreiben“ und „zu einem exorbitanten Preis“ es entweder zu einem Produkt (etwas, das an viele verschiedene Kunden geliefert wird) oder zu einem Komplex (etwas, das aus vielen besteht) machen möchten programmiert und nahtlos in die Umgebung des Kunden integriert, einschließlich Ausrüstung). Und wenn das "Schreiben eines Programms" im Großen und Ganzen eine der Soft-Building-Methoden sein kann, können Ihre hervorragenden Pläne für die weitere Entwicklung durch die Mängel der Top-Down- und Bottom-Up-Methoden gestört werden.
Unter den Bedingungen, in denen die Humanressourcen der Programmierer-Techniker übermäßig hoch sind und es an Schwierigkeiten und Schwierigkeiten mangelt, Designer und Analysten anstelle einer horizontalen Organisation einzustellen („Systemingenieure“ bilden eine Plattform für „Bewerber“), beginnen sie, eine vertikale zu verwenden , wo jedes Team seine Funktionen basierend auf seinen eigenen Fahrrädern implementiert. Aus Sicht des Managements sieht die zweite Methode einfacher aus, jedoch nur bis zu dem Zeitpunkt, an dem ein horizontaler Befehl „Architektur“ eingeführt wird, der durch lange Überzeugungsarbeit und Koordination das Risiko derselben sich wiederholenden Fehler verringert.
Hier können wir vielleicht aufhören, denn die anfängliche Orientierung im Informationsraum sollte ausreichen. Der Text enthält Schlüsselwörter und einige Links, damit Neugierige das Thema weiter vertiefen können.
Original Text auf der Website "Mechanik der Softwareentwicklung"