Wie kann man ein Programm von In-Development auf Release umstellen?

67

Irgendwann ist ein Programm in der Entwicklung. Features werden ständig hinzugefügt, entfernt oder geändert. Jede Version ist nichts anderes als ein Prototyp. Daher verschwende ich zu diesem Zeitpunkt nicht viel Zeit damit, super sauberen Code zu schreiben, da ich nie weiß, wie lange etwas dauert. Natürlich versuche ich, die Codequalität auf einem bestimmten Standard zu halten, aber Zeit ist immer ein Problem.

Dann kommt der Punkt, an dem das Programm beendet ist und die Entscheidungsträger sagen "das war's". Momentan habe ich einen funktionierenden Prototyp, aber der Code im Inneren ist während der Entwicklungsphase ein bisschen chaotisch. Es wird erwartet, dass ich mit dem Testen / endgültigen Debuggen beginne, aber mein Bauch sagt, ich sollte jetzt irgendwie aufräumen und / oder Dinge neu schreiben, um eine korrekte Architektur zu erhalten, die die Wartung usw. erleichtert.

Sobald das Zeug getestet und genehmigt wurde, macht es keinen Sinn, es dann umzuschreiben. Ich stehe regelmäßig mit einem funktionierenden 'fertigen' Prototyp da und bekomme während des Testens einen Fehler und ich sehe, dass es ein Ergebnis von nicht intelligenter Codierung ist, das das Ergebnis des gesamten Entwicklungsprozesses ist. Ich bin mitten im Testen und der Bugfix wäre ein Umschreiben ... es ist ein Chaos!

Es gibt bessere / lehrbuchartige Wege, da bin ich mir sicher. Aber ich muss in einer realen Arbeitsumgebung arbeiten, in der nicht alles Lehrbuch ist.

Wie kann ich meinen funktionierenden Prototyp auf eine Release-Version mit einer stabilen Codebasis umstellen? Vielleicht sollte ich die Entwicklung nicht als abgeschlossen betrachten und sie tatsächlich als Aufräumphase betrachten ... Ich weiß nicht, ich brauche hier Hilfe.

BEARBEITEN

Ich möchte ein paar Dinge klarstellen.

  • Ich bin zu 100% auf der Seite, es direkt davor und nicht danach zu tun, Code sauber und lesbar. Aber ich muss auch Dinge erledigen und kann nicht von der Schönheit des Codes träumen, der alle sauber und glänzend ist. Ich muss einen Kompromiss finden.

  • Oft ist eine neue Funktion nur etwas, das wir ausprobieren möchten, um herauszufinden, ob es sinnvoll ist, so etwas zu implementieren. (va in mobilen Apps, um ein echtes Look-and-Feel auf einem tatsächlichen Gerät zu erhalten) Es ist also etwas Kleines, das (imho) nicht zu viel Arbeit in einer ersten Iteration "mal sehen" rechtfertigt. Manchmal stellt sich jedoch die Frage, WANN ich diese Technologie zahle. Darum geht es in dieser Frage.

Wenn ich weiß, dass die Hälfte der Features einen Tag später gelöscht wird (inzwischen genug Erfahrung in unserem Unternehmen), fällt es mir wirklich schwer zu glauben, dass der beste Weg, mein Problem anzugehen, darin besteht, zusätzliche Zeit zu investieren, um alles sauber zu schreiben, auch wenn Das meiste davon wird kurz danach fallen gelassen. Ich habe das Gefühl, dass ich Zeit sparen werde, wenn ich eine große Bereinigung vornehme, sobald die Sache solide ist, daher meine Frage.

NikkyD
quelle
68
Ihre Frage lautet: "Ich habe mich in ein Loch gegraben. Wie komme ich raus?" Die Standardantwort ist natürlich Schritt eins, STOP DIGGING DEEPER. Ihr Entwicklungsprozess kann wie folgt zusammengefasst werden: "Generieren Sie enorme technische Schulden und ignorieren Sie diese, wenn sie fällig werden." Wenn dies ein Problem ist, ändern Sie Ihre Entwicklungsprozesse. Checken Sie nur sauberen, funktionierenden, debuggten und sorgfältig überprüften Code ein, der den sorgfältig geschriebenen Spezifikationen entspricht. Verschulden Sie sich nicht und Sie müssen sich nicht aus der Verschuldung befreien.
Eric Lippert
11
@NikkyD Wenn Sie nicht die Zeit für eine ordnungsgemäße Implementierung haben, müssen Sie mit Ihrem Manager über die Auswirkungen auf die Qualität der Software sprechen. Verstehen Sie, was alle hier sagen: Wenn Sie nicht die Zeit im Voraus investieren , können Sie später nicht mehr effizient arbeiten. Ein weiteres Thema, das Sie ansprechen möchten: Wenn Sie das Unternehmen verlassen (oder von einem Bus überfahren werden), wäre es für neue Entwickler extrem teuer, sich mit dem Code vertraut zu machen. Das Geld, das sie jetzt zu sparen glauben, wird sie später kosten.
jpmc26
32
Wenn Sie eine kleine Feature-Verzweigung erstellen, um eine vorgeschlagene Benutzeroberfläche für ein Feature zu verspotten, ist das großartig. Machen Sie das so schnell und schmutzig, wie Sie möchten, zeigen Sie es dem Client und löschen Sie dann diesen Zweig . Wenn Autohersteller Autos aus Ton und Papier herstellen, um sich über ein neues Design lustig zu machen, versuchen sie nicht, einen Motor in das Tonmodell einzubauen. Der Prozess, um festzustellen, ob sich die Funktion lohnt, sollte kostengünstig sein. Sobald Sie sich entschieden haben , um die Funktion zu tun, stellen Sie sicher , dass Sie beginnen , von sauberem Code und immer produzieren sauberen Code, da dieser Code jetzt Produktionscode .
Eric Lippert
10
"Ich kann nicht von der Schönheit des Codes träumen, der sauber und glänzend ist" Dies ist ein grundlegendes Missverständnis dessen, was "sauberer Code" bedeutet. Sauberer Code bedeutet nicht, dass Sie einen Nachmittag damit verbringen, Ihre Registerkarten auszurichten, damit Sie den Code drucken und ihn rahmen können. Sauberer Code ist guter Code und guter Code ist sauberer Code. Clean Code ist Code, der ordnungsgemäß funktioniert, debuggt und verstanden werden kann. Wenn Sie von Anfang an keine Zeit haben, sauberen Code zu schreiben, haben Sie definitiv keine Zeit, unordentlichen Code zu schreiben und ihn dann auch später zu reparieren. So lange dauert die Aufgabe.
GrandOpener
8
"Ich muss auch Dinge erledigen und kann nicht von der Schönheit des Codes träumen, der sauber und glänzend ist. Ich muss einen Kompromiss finden." Ein Kompromiss bedeutet einen Mittelweg, der für beide Seiten "gut genug" ist. Wenn Ihr Code unordentlich ist - insbesondere, wenn er so unordentlich ist, dass Sie Probleme bei der Pflege haben -, ist er nicht "gut genug", und Sie müssen einen besseren Kompromiss finden.
Anaximander

Antworten:

98

Daher verschwende ich zu diesem Zeitpunkt nicht viel Zeit damit, super sauberen Code zu schreiben, da ich nie weiß, wie lange etwas dauert.

Nicht zu wissen, wie lange etwas dauert, sollte niemals eine Entschuldigung für Schlamperei sein - im Gegenteil. Der sauberste Code ist IMHO derjenige, der Ihnen nicht in den Weg kommt, wenn Sie etwas ändern müssen. Meine Empfehlung lautet daher: Versuchen Sie immer, den saubersten Code zu schreiben, den Sie können - insbesondere beim Codieren eines Prototyps. Weil es viel einfacher sein wird, es anzupassen, wenn etwas geändert werden muss (was sicherlich passieren wird).

Verstehen Sie mich nicht falsch - mein Verständnis von "dem saubersten Code" hat nichts damit zu tun, Code der Schönheit zuliebe schön zu machen. Das ist in der Tat etwas, das Sie verlangsamen kann. Aus meiner Sicht ist sauberer Code ein Code, der sich größtenteils von selbst erklärt (es ist nicht erforderlich, so viele Dokumente zu schreiben - dies führt zu einer Beschleunigung), der leicht zu verstehen ist (weniger Fehler, weniger Debugging - Beschleunigung, weniger Zeit für die Suche nach dem richtigen Code Platz zum Ändern - Beschleunigen), löst das gegebene Problem mit der geringsten Menge an notwendigem Code (weniger Code zum Debuggen - offensichtliche Beschleunigung), ist TROCKEN (nur ein Platz zum Ändern, wenn etwas geändert werden muss - Beschleunigen - und weniger Risiko einzuführen neue Bugs, indem man vergisst, einen zweiten Platz zu wechseln), folgt Codierungsstandards (weniger umständliche Dinge, über die man nachdenken muss - Beschleunigung), verwendet kleine,

Es wird erwartet, dass ich mit dem Testen / endgültigen Debuggen beginne, aber mein Bauch sagt, ich sollte jetzt irgendwie aufräumen und / oder Dinge neu schreiben, um eine korrekte Architektur zu erhalten, die die Wartung usw. erleichtert

Das anschließende "Aufräumen" funktioniert nie. Betrachten Sie Bereinigung , bevor Sie ein neues Feature implementieren, oder wenn es um die Umsetzung beginnen, aber nicht danach. Wenn Sie beispielsweise eine Methode für ein Feature berühren und feststellen, dass sie länger als 10 Zeilen ist, überlegen Sie, sie in kleinere Methoden umzuwandeln - unmittelbar bevor Sie das Feature fertigstellen. Wenn Sie einen vorhandenen Variablen- oder Funktionsnamen erkennen, wissen Sie nicht genau, was er bedeutet, finden Sie heraus, wozu er gut ist, und benennen Sie die Sache um, bevor Sie etwas anderes tun. Wenn Sie dies regelmäßig tun, halten Sie Ihren Code mindestens in einem ausreichend sauberen Zustand. Und Sie sparen Zeit - weil Sie viel weniger Zeit für das Debuggen benötigen.

Ich bin mitten im Testen und die Fehlerbehebung wäre ein Umschreiben

... das ist der eigentliche Beweis für das, was ich oben geschrieben habe: "Dirty" quält dich sofort zurück, wenn du anfängst, deinen Code zu debuggen, und wird dich langsamer machen.

Sie können dies fast vollständig vermeiden, wenn Sie die Bereinigung sofort durchführen. Dann bedeuten Fehlerkorrekturen meistens kleine Änderungen am Code, aber niemals eine größere architektonische Änderung. Wenn Sie beim Testen tatsächlich Hinweise auf eine Verbesserung der Architektur feststellen, verzögern Sie diese, fügen Sie sie in Ihr Fehlerverfolgungssystem ein und implementieren Sie sie, wenn Sie das nächste Mal eine Funktion implementieren müssen, die von dieser Änderung profitiert ( bevor Sie mit dieser Funktion beginnen).

Dies erfordert natürlich etwas Disziplin und Erfahrung im Programmieren. Es ist eine ähnliche Idee wie die Idee hinter "Test Driven Development", diese Dinge vorher zu tun, anstatt sie später zu tun (TDD kann auch helfen, aber was ich geschrieben habe, funktioniert auch, wenn Sie TDD nicht verwenden). Wenn Sie dies konsequent tun, benötigen Sie vor der Freigabe keine spezielle "Aufräumphase".

Doc Brown
quelle
40
@ NikkyD Die Vorschläge von Doc Brown sind Gewohnheiten, die den Zeitaufwand verringern und auf lange Sicht sehr realistisch sind. Überlegen Sie, wie viel Zeit Sie sparen, wenn Sie Ihren Code nicht jedes Mal überprüfen müssen, um herauszufinden, wie er nicht beschädigt werden kann, wenn Sie ihn ändern müssen . Die Zuwächse sind ähnlich wie beim Wechseln von "Jagen und Picken" zum Erlernen des Tippens. Es kann anfangs länger dauern, während Sie lernen, aber sobald die Gewohnheit da ist, ist es zweifellos besser und wird Ihnen für den Rest Ihrer Karriere zugute kommen. Wenn Sie es nicht versuchen, werden Sie niemals dorthin gelangen.
Daniel
44
@ NikkyD: Es bläht den Zeitrahmen nicht auf. Der Zeitrahmen war bereits aufgebläht; Sie hat einfach nicht Konto für die aufblasen , wenn Sie die Software geschrieben und bekam in technische Schulden , die Sie für nicht budgetiert hatte.
Eric Lippert
7
@ NikkyD: Ich präsentiere Ihnen das Idol mit Feet of Clay und das Konzept der technischen Schulden . Ersteres bedeutet, dass Sie Sound-Software auf schwankenden Fundamenten erstellen können. Letzteres betrifft das "Interesse" (zusätzliche Kosten) an Features, die Sie versuchen, zu beheben, wenn die Struktur nicht solide ist.
Matthieu M.
10
@NikkyD: Nein, ich schlage vor, Ihren Code so zu schreiben, wie ein Billard-Experte seine Bälle spielt: Jeder Schuss sieht für den Außenstehenden einfach aus, da die Bälle nach dem Schuss für einen neuen "einfachen Schuss" anhalten. Und beim Billard oder Codieren dauert das einige Jahre ;-)
Doc Brown
16
@NikkyD: Nach meiner Erfahrung ist das Hinzufügen eines kleinen Features eine Menge Umgestaltung erforderlich. Der Code ist bereits ein Chaos, und das Erfordernis einer Menge Umgestaltung ergibt sich aus der Tatsache, dass Sie eine Funktion oder Klasse ändern müssen, die Sie vorgenommen haben in der Vergangenheit nicht sauber genug zu halten. Lass die Dinge nicht so weit kommen. Aber wenn Sie in dieser Situation sind, finden Sie einen Kompromiss. Befolgen Sie mindestens die "Boyscout-Regel" und lassen Sie den Code in einem besseren Zustand als vor dem Hinzufügen der Funktion zurück. Selbst wenn das Feature nächste Woche entfernt wird, sollte der Code in einem besseren Zustand sein als zuvor.
Doc Brown
22

Sie haben zwei separate Probleme, beide mit demselben Symptom (fehlerhafter Code):

Problem Nr. 1: Unzureichende Anforderungskontrolle Ich meine nicht, dass Ihre Stakeholder Ihre Anforderungen zu häufig ändern. Ich meine, dass Sie Anforderungsänderungen während eines Bugfix- / Testzyklus zulassen. Selbst die agilen Methoden unterstützen das nicht. Sie bauen, Sie testen, Sie liefern, Sie stellen neue Anforderungen.

Problem Nr. 2: Sie glauben, dass das, was Sie schreiben, "nur für den Augenblick" ist. In der Softwareentwicklung ist "nur für den Augenblick" Code wirklich extrem selten. Sie haben selbst festgestellt, dass es nach der Erfüllung einer Benutzeranforderung aufgrund der Strenge von Angebot und Nachfrage sehr schwierig ist, das Zurückgehen und die Neuimplementierung eines "Fertig" -Features zu rechtfertigen. Also, was tun? Schreiben Sie immer den Seriencode. Funktionell bedeutet dies, dass Ihre Schätzungen gegenüber Ihren Stakeholdern wesentlich größer sein müssen, damit Sie etwas Zeit haben, um es richtig zu machen.

Bitte haben Sie auch Verständnis dafür, dass Sie als Entwickler in der schwierigsten Position arbeiten: Lesen Sie, wie Joel Spolsky das Leben eines internen Entwicklers übernimmt . Sie müssen also besonders wachsam sein, wenn Sie mit intakter geistiger Gesundheit durchkommen möchten.

Gus
quelle
21

Dies ist ein häufiges Problem, insbesondere bei der Erstellung einer Art Software- Test-Sprechblase .

Es gibt eine Reihe von Ansätzen, die helfen können. Erstens kann der TDD- Ansatz helfen, die Codebasis auf das zu reduzieren, was unbedingt erforderlich ist. Wenn Ihre Tests mit Ihrem Code Hand in Hand gehen, können Sie sich zumindest darauf verlassen, dass sich Ihr Code so verhält, wie er sollte.

Nehmen Sie sich Zeit für die Umgestaltung. Wenn Sie einen Prototypen haben und der Kunde sehr darauf aus ist, ihn in die Hand zu bekommen, ist es schwierig zu sagen, dass Sie Zeit brauchen, um die Vollständigkeit zu verbessern. Ich möchte täglich einchecken, gefolgt von einem Refactor-Check-in, aber YMMV.

Entwickler, die schnell Code schreiben, sind oft gefragt - wir hatten einen solchen Entwickler in meiner letzten Abteilung. Jedes Team wollte ihn, weil er super schnell arbeitete. Sobald die Zeit gekommen war, seinen Code zu testen und freizugeben, lösten sich die Räder jedoch schnell. Überall hartcodiertes Zeug, Hacks und Shortcuts. Sein Bestand fiel bald - massiv.

Das Schneiden von Produktionscode von Anfang an kann wie ein Hemmschuh erscheinen, aber je nach Ihrer Umgebung gibt es viele Tools, die die Entwicklung vereinfachen können, z. B. Ghostdoc und Stylecop .

Es lohnt sich, von Anfang an die richtige Einstellung zur Entwicklung zu haben. Sie wären überrascht, wie viele Back-of-a-Fag-Paketsysteme, die eigentlich nur Stop-Gap-Lösungen sein sollten, zu Eckpfeilern für Anwendungen werden.

Robbie Dee
quelle
Du meinst jede Stop-Gap-Lösung, die jemals geschrieben wurde, oder?
RubberDuck
4
Ein großartiger Punkt zur Rechtfertigung für den Kunden. Ich habe viel Erfahrung mit Kunden, die glauben, dass die Anwendung auch fertig ist, wenn die Benutzeroberfläche fertig aussieht. Ich habe gelernt, die GUI unvollständig aussehen zu lassen, während der Code im Hintergrund noch nicht fertig ist, und daher nur das zu lassen, was der Kunde als poliert ansieht, wenn der Code (und die Geschäftslogik) korrekt sind. Es ist sehr schwer zu erklären, dass es noch ein oder zwei Monate dauern wird, bis der Kunde das Ergebnis sieht.
Luaan
11

Ständig

Die Geschwindigkeit der Entwicklung ist der Hauptgrund, um sauberen, lesbaren und testbaren Code zu schreiben. Es ist weder für die Schönheit noch für andere abstrakte Werte gemacht. Warum sollte ich das mir selbst verweigern und es später nur für einen zukünftigen Programmierer tun?

Sicher, es kann Änderungen geben, die hauptsächlich kosmetischer Natur sind und daher nicht unbedingt erforderlich sind. Ich würde argumentieren, dass es weitaus nützlicher ist, im Moment während der Entwicklung mäßig guten Code zu haben, als im Moment ein Durcheinander zu haben und zu hoffen, es später zu perfektionieren (was, seien wir ehrlich, es wird niemals passieren, selbst wenn Sie es getan haben die Zeit).

Thanos Tintinidis
quelle
6
+1 und aus persönlicher Sicht fand ich es zu schwierig, den Gang zu wechseln, wenn ich zu Hause persönliche Projekte hackte und in meinem täglichen Job Produktionscode schrieb. Das Schreiben von professionellem Code in meinen Hobbyprojekten zahlte sich sofort aus - Code war leichter zu lesen und es gab weit weniger Fehler.
Robbie Dee
Ein Grund, warum es niemals passieren wird, ist, dass Sie (besser) besser werden, was Sie im Laufe der Zeit tun. Wenn Sie also ein halbes Jahr warten, um etwas zu "bereinigen", werden Sie nicht nur alle für die sichere Bereinigung erforderlichen Minuten vergessen, sondern auch ein besserer Programmierer als zuvor sein und wahrscheinlich in Versuchung geraten einfach alles wegwerfen und von vorne anfangen. Und da das so viel Arbeit ist (und oft ohnehin eine schlechte Idee ist), werden Sie wahrscheinlich die Bereinigung einfach wieder überspringen.
Luaan
"Warum sollte ich das mir selbst verweigern und es später nur für einen zukünftigen Programmierer tun?" Offenbarung! Und rate was? Sie sind manchmal (und manchmal oft) dieser zukünftige Programmierer.
Radarbob
@RobbieDee, Beobachtung der Superlative! In einem Interview sagte Malcom Gladwell - der Typ, der die "10.000-Stunden-Regel" (im Buch " Ausreißer" ) bekannt gemacht hat -, dass es "absichtliches Üben" sein müsse oder dass es nur Zeitverschwendung sei. Das bedeutet, sich auf die Verbesserung zu konzentrieren, Besonderheiten zu üben, um diesen speziellen Aspekt einer Fertigkeit zu verbessern usw.
radarbob
@ThanosTintinidis, dann gibt es das Problem "keine gute Tat bleibt unbestraft". Wenn jemand so sauberen Code geschrieben hat, wird er unweigerlich kaputt gehen. Stellen Sie sicher, dass Sie der Codeüberprüfer sind, wenn jemand anderes Ihren sauberen Code berührt. Eine einfach hinzugefügte Methode hat die Einkapselung und Kohärenz , die sogar inline dokumentiert wurde, durchgebrannt . Ich war eine Woche lang wütend; und ein Jahr später, jedes Mal, wenn ich diesen Code sehe.
Radarbob
4

Sie tun dies, indem Sie zwischen dem Code "Ich versuche nur, zu sehen, wie er funktioniert" und dem Code "Dies wird in den Produktcode übernommen" unterscheiden. Es gibt verschiedene Möglichkeiten, dies zu tun.

Eine ist Verzweigung oder was auch immer das Wort in Ihrem Quellcodeverwaltungssystem ist. Sie machen eine Verzweigung für den neuen Bericht oder das neue Importlayout oder was auch immer. Wenn die Leute es mögen, ist die Aufgabe, es wieder in die Hauptniederlassung zu bringen, eine separate, nachverfolgbare Aufgabe. Es kann jemandem zugewiesen und gemeldet werden, und es ist nicht zu erwarten, dass der Tag, an dem das Management (oder der Vertrieb) zustimmt, dass die Funktion zum Produkt gehört, einfach magisch verläuft.

Ein anderer ist Spikes. Diese Änderung nehmen Sie am Produkt nicht vor. Du gehst in eine separate App, super einfach, die nur für dich existiert, um einen Platz zum Einfügen von Code zu haben. Sie können so chaotisch sein, wie Sie möchten, weil Sie nur die neue API erkunden oder was auch immer. Und wieder, wenn Sie zurückkommen und melden "Ja, das können wir, ich habe herausgefunden, wie" es eine verfolgbare, berichtbare, zuweisbare Aufgabe gibt, in das Produkt produktfertigen Code zu schreiben, um das zu tun, was Sie wollen.

In beiden Fällen bedeutet "Produktbereit", lesbar, ordentlich, gemäß den Namensstandards, mit Tests und unter Einhaltung Ihres Codestils und Ihrer Leistungsziele. In beiden Fällen machen Sie diese Arbeit sichtbar. Ich bin damit einverstanden, dass Sie diese Arbeit nicht jedes Mal ausführen möchten, wenn es sehr wahrscheinlich ist, dass jemand die Funktion wieder aus dem Produkt entfernt. Aber Sie wollen auch nicht, dass diese Arbeit unsichtbar wird. Wenn Sie in separaten Kopien des Produkts oder in einem nicht verwandten Produkt arbeiten, das kaum mehr als ein Testgurt ist, können Sie die Arbeit aufdecken, um produktfertigen Code zu erstellen, sobald jemand entscheidet, dass er etwas möchte.

Der Nachteil ist, dass sie sich nicht entscheiden können, etwas zu wollen und es zu versenden (dh die halbherzige, chaotische, ungeprüfte, undokumentierte, möglicherweise langsame Halbversion, die Sie als Proof-of-Concept implementiert haben). Wenn Sie das erste Mal einen Pushback erhalten, fragen Sie einfach, ob Sie es jedes Mal auf die lange (teurere) Art und Weise tun sollten, um den Weg zu abgelehnten Funktionen zu verlangsamen. Wenn Sie richtig fragen, erhalten Sie ein "Nein".

Kate Gregory
quelle
1

Wirklich denke ich, dass Sie das Problem bereits verstehen. Das Problem ist, dass Ihr Codierungsstil zu viel Nacharbeit erfordert. Der Grund, warum es zu viel Nacharbeit erfordert, ist, dass (a) es mit unzureichender Voraussicht und Planung zusammengefügt wird und (b) die inkrementellen kurzfristigen Patches, die regelmäßig während der Entwicklung eingefügt werden, die Komplexität einer erforderlichen Nacharbeit kombinatorisch erhöhen.

Die Antwort lautet daher:

(a) Verschieben Sie Ihren Entwicklungsstil ein bisschen mehr in Richtung Wasserfall und ein bisschen weniger beweglich. Gehen Sie aber nicht den ganzen Weg, denn der klassische Wasserfall hat seine eigenen Gefahren. Es ist ein gesundes Gleichgewicht zu haben. Ich weiß, dass es manchmal darum gehen kann, nur ein paar Tage lang über Dinge nachzudenken, als würde keine Entwicklung durchgeführt, aber man muss dem Prozess vertrauen. In der Technik kann man nicht einfach Dinge zusammennageln und dann Dinge obenauf nageln und hoffen, eine elegante Lösung zu finden. Wenn es niemanden gibt, der Architektur und höheres technisches Design betreibt, dann ist das Ihre Aufgabe. Sie haben den Preis dafür bezahlt, diesen Job zu vernachlässigen.

(b) versuchen Sie zu vermeiden, Dinge zu flicken. Denken Sie nicht langfristig, wenn es darum geht, eine Qualitätssicherung durchzuführen. Eigentlich solltest du jedes kleine Stück, das du baust, die ganze Zeit testen und alle Eingabefälle abdecken, auch die, die nicht auf dem glücklichen Weg sind. Ein Patch / Hack ist per Definition ein kurzfristiger Fix, der durchaus langfristige Kosten verursachen kann und die Total Cost of Ownership des Kunden im System belastet. Der Druck, Code herauszubekommen, ist wieder groß, also muss ein Gleichgewicht herrschen. Aber versuchen Sie nicht, kurzfristige Korrekturen vorzunehmen. diejenigen, die Komponenten fest koppeln, die wirklich locker gekoppelt sein sollten. Es wird eine Überarbeitung geben, also tun Sie es FRÜH, um es viel einfacher zu machen, um die Hacks und Patches zu vermeiden, die sich im Laufe der Zeit ansammeln und unhandlich werden.

Brad Thomas
quelle
2
Nur eine Anmerkung - Agilität bedeutet nicht "häufige Änderungen ohne nachzudenken" oder "weniger Design". Tatsächlich finde ich, dass Agilität wesentlich mehr Design erfordert als das, was die Leute üblicherweise als Wasserfall bezeichnen. Das Fehlen eines guten Designs ist einer der Gründe, warum Wasserfälle in der Praxis nicht gut funktionieren. Wenn Sie tatsächlich richtig in das Design investieren, funktioniert es einwandfrei. es wird eben auch viel teurer als agil. Wenn Sie den Designteil in Agile überspringen, können Sie Code einfach unkompliziert zusammenfügen, und das wird nicht besser funktionieren als bei jeder anderen Methode, die Design vermeidet.
Luaan
Der agile Fokus auf kurze Iterationen, Sprints usw., das schnelle Herausbringen von Prototypen setzt zwangsläufig die Vernachlässigung ausreichenden Designs
Brad Thomas
Nein, es konzentriert sich auf das Entwerfen kleinerer Teile. Aber alles in allem, Sie müssen viel entwerfen, sonst sind Sie nur eine schreckliche Produkt zu produzieren gehen. Der Schlüssel ist, Dinge klein und gut gestaltet sowie austauschbar zu machen. Wenn Sie weniger agil gestalten, tun Sie sich selbst (und Ihren Kunden) einen schlechten Dienst. Kurze Iterationen sind der Vorteil der Verwendung von Agile, nicht die Voraussetzung oder nur ein Teil des Prozesses - sobald Sie alles gut genug bekommen, können Sie sich die kurzen Iterationen plötzlich leisten , nicht umgekehrt.
Luaan
Es ist ein großes Problem, die Konstruktion kleinerer Teile stärker in den Vordergrund zu rücken, wenn das Gesamtbild in der Regel die Hauptursache für Nacharbeiten ist. Ich habe auf einmal viel mehr Geld für das Geschäft verschwendet gesehen, als ich jemals bei der Änderung eines Designs von a gesehen habe kleine lose gekoppelte Komponente
Brad Thomas
Ja, aber zu diesem Zeitpunkt haben Sie bereits verloren (und unabhängig davon, ob Sie nach Agilität oder Wasserfall suchten). Wenn sich Ihr "Gesamtbild" aus vielen kleinen Teilen zusammensetzt, die relativ isoliert sind, ist die einzige umfassende Überholung, die Sie erhalten, wenn Sie so ziemlich alles ersetzen müssen. Welcher Ansatz bringt Sie nicht dazu, alles zu verlieren, wenn Sie von vorne anfangen müssen? Sogar das NASA-Designniveau führt hin und wieder dazu, dass "wir alles ändern müssen". Indem Sie sich flexibel und anpassungsfähig halten, erhalten Sie mehr Handlungsspielraum für kleine und große Änderungen.
Luaan
0

Du schreibst:

Jede Version ist nichts anderes als ein Prototyp. Daher verschwende ich zu diesem Zeitpunkt nicht viel Zeit damit, super sauberen Code zu schreiben, da ich nie weiß, wie lange etwas dauert. ...

Dann kommt der Punkt, an dem das Programm beendet ist und die Entscheidungsträger sagen "das war's". Momentan habe ich einen funktionierenden Prototyp, aber der Code im Inneren ist während der Entwicklungsphase ein bisschen chaotisch.

Bei einer eingecheckten Version kann es sich um einen "Prototyp" handeln, bei dem Features fehlen oder einige Features nicht vollständig sind. Der gesamte eingecheckte Code sollte jedoch ein Code für die Produktionsqualität sein, der nicht unbedingt bereinigt werden muss.

Ich denke, Sie verschieben Ihre "Aufräumarbeiten" zu sehr.

Meine Faustregel lautet:

  • Beginnen Sie mit (Unter-) Funktion
  • fühlen sich frei , unvollständig und inclomplete Sachen zu schreiben, vielleicht etwas c & p ein Gefühl dafür zu bekommen , was ich implementieren oder wenn ich die letzte Stunde kratzen (n) der Codierung (beachten Sie, dass dies kann Hand in Hand mit TDD / Tests gehen, Es ist nur so, dass alles ein wenig abgeschwächt ist, um ein schnelles Feedback zu dem Implementierungsbereich zu erhalten, den ich erkunde.
  • Unterfunktion "funktioniert" vorerst gut genug
  • Führen Sie jetzt die Bereinigung durch: Vor einem SCC-Commit .
    • Sehen Sie sich den Code an, um zu sehen, was offensichtlich ist
    • Führen Sie einen Vergleich mit dem letzten Commit durch, um Änderungen zu überprüfen und möglicherweise Probleme zu erkennen
    • Korrekturen, die ich auf meinem Notizblock notiert habe
  • Jetzt mache ich das Commit - diese Codequalität ist versandbereit

Zu diesem Zeitpunkt enthält der festgeschriebene Code möglicherweise noch einige Problemumgehungen oder "technische Probleme", die behoben werden sollten, und möglicherweise werde ich sie beheben, wenn dies für ein nachfolgendes Unterfeature selbstverständlich ist wird OK sein, wenn der Code so wie er ist freigegeben wird.

Martin Ba
quelle