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

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.

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".

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.

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.

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).

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".

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.

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.