Wie lerne ich den richtigen Ansatz, um eine halbe Funktion zu implementieren? [geschlossen]

12

Ich leite ein Entwicklungsteam und möchte unser Produkt so oft wie möglich veröffentlichen (Continuous Delivery).

In vielen Fällen müssen wir eine Funktion implementieren, deren Implementierung länger dauert als die Zeit zwischen den Releases. Ich möchte immer noch, dass die Leute ihren Code täglich schreiben (Continuous Integration).

Bei der Implementierung eines neuen Features muss häufig das vorhandene Feature geändert werden, und die vorhandenen Features müssen natürlich noch funktionieren, auch wenn das neue Feature noch nicht fertig ist.

Wenn der Entwickler den richtigen Ansatz verwendet , kann er vorhandene Funktionen sorgfältig anpassen, und all das ist kein Problem.

Was ist eigentlich der richtige Ansatz? Mein eigener, auf die Programmierung abgestimmter Verstand sagt mir, was ich für jeden Einzelfall tun soll, aber ich muss mehr lernen und ich benötige Lesematerial, das ich lesen und Teammitglieder zum Lesen überweisen kann. Oder irgendeine andere Methode, um den richtigen Weg zu erlernen, um diesen Ansatz zu erlernen, wird genügen.

Das ist also die Frage. Wie stelle ich sicher, dass die Teammitglieder den richtigen Ansatz zur Implementierung einer halben Funktion kennen?

Ich habe nach Leuten gesucht, die behaupten, diesbezügliche Strategien zu haben, habe diese aber noch nicht gefunden, außer dass Leute ein paar zufällige Gedanken zu dem Thema geschrieben haben. Vielleicht verwende ich nicht die richtigen Suchbegriffe, oder vielleicht hat niemand maßgebliche Richtlinien dazu aufgestellt.

Niels Brinch
quelle
"Vorhandene Funktionen müssen natürlich noch funktionieren" - je nach Kontext könnte der Begriff für eine solche Anforderung Abwärtskompatibilität oder das Fehlen von Regressionsfehlern sein
gnat
1
Verschiedene Arten von automatisierten Tests können das Risiko von Fehlern bei Codeänderungen verringern. Prüfen. Ich bin auf der Suche nach einem Ansatz, den ich als Entwickler verwenden kann, um eine große Funktion zu implementieren, bei der 75% des vorhandenen Codes und 26% des neuen Codes geändert werden müssen.
Niels Brinch,
1
@Niels: Sie müssen einige großartige Entwickler haben, damit sie am Ende eines jeden Tages über Arbeitscode verfügen können, der in den Hauptzweig eingecheckt werden kann und alle Tests besteht. Entweder das oder sie bekommen nur ein Minimum an Arbeit, damit sie in der Lage sind, ihren Code bis zum Ende des Tages einzuchecken.
Eintauchen
würden sie das nicht "Feature Branch" nennen. Sie nehmen Ihre Änderungen in der Verzweigung vor und führen die Verzweigung nach Abschluss der Funktion wieder in der Hauptverzweigung zusammen. Sie sollten keine halb implementierten Funktionen in Demos präsentieren, daher verstehe ich nicht, warum dies nicht funktionieren würde.
Deltree

Antworten:

14

Ich sehe das schon anders als die anderen Antworten hier. Ich stimme Ihnen zu, dass Sie Änderungen von Entwicklern so schnell wie möglich integrieren und den kombinierten Codemix weiter testen möchten.

Ich bin jedoch nicht damit einverstanden, dass das Recht, Code zu versenden, heute Morgen entwickelt wurde, nur weil wir heute Nachmittag veröffentlichen. Das ist ein Rezept für enttäuschte Kunden.

Die Lösung besteht darin, Zweige in Ihrem Versionskontrollbaum zu haben und dass Sie einen separaten Prozess haben, um verifizierte Deltas vom Entwicklungszweig zum Freigabezweig zu befördern.

So bekommen Sie das Beste aus beiden Welten. Sie haben Entwickler, die eine kontinuierliche Integration durchführen, und die Vorteile, die sich daraus ergeben, bestehen darin, dass sie regelmäßig stabilen Code an den Kunden senden. Außerdem verfügen Sie über einen neuen Prozess, mit dem abgeschlossene Funktionen in der Entwicklerbranche getestet werden. Wenn sie die Tests bestehen, werden sie Teil des freigegebenen Produkts .

Es gibt zwei mir bekannte Tools, die diese Art von Prozessen gut unterstützen. Wenn Ihre Entwicklungsstruktur einfach ist, implementiert git mit git-flow eine gute Verzweigungsstruktur, die in kleinen bis mittelgroßen Teams (vielleicht 20 Entwickler) gut funktioniert.

Für größere Entwicklungsteams oder wenn eine komplexere Verzweigungsstrategie zur Unterstützung mehrerer "Spins" Ihres Produkts erforderlich ist, ist accurrev das Beste, was es gibt. Die Entwickler, die nicht an der Verwaltung der Änderungen beteiligt sind, werden sich darüber beschweren, dass es schwieriger ist als eine Unterversion usw., aber komplexe Entwicklungsumgebungen unterstützt.

Michael Shaw
quelle
Es würde mich sehr interessieren, mehr über die Verzweigungsstrategie zu erfahren, auf die Sie sich beziehen. Haben Sie einen Link zu einem Artikel oder etwas anderem, das das Konzept, auf das Sie sich beziehen, ausführlicher erklärt?
Niels Brinch
2
Hier ist nvie.com/posts/a-successful-git-branching-model für Git Flow
Michael Shaw
Das Hauptmerkmal von Git Flow ist seine klar definierte Verzweigungsstrategie, die es zu einer guten Wahl für ein Produkt macht, das nur eine Freigabe zu produzieren hat. Accurrev erzwingt keine Verzweigungsstrategie, verfügt jedoch über die Flexibilität und die Tools, um einen viel komplexeren Zweigbaum effektiv zu verwalten.
Michael Shaw
6

Hier gibt es zwei Probleme: eines implementiert eine halbe Funktion; Das andere ist, das Versandprodukt während der kontinuierlichen Entwicklung am Laufen zu halten.

Ein halbes Feature implementieren

Ein starkes übergreifendes Design wird dabei helfen. Auf diese Weise können Sie das Feature mit seinen klar definierten Grenzen implementieren - z. B. APIs für benachbarte Codebits, Erwartungen an Datenstrukturen und das Verständnis, wie und wann der implementierte Code aufgerufen wird.

Das Testen kann nachgebildete Versionen des Codes für die anderen Teile der Funktion umfassen. Dies erleichtert den Übergang bei der Implementierung der zweiten Hälfte.

Halten Sie das Versandprodukt funktionsfähig

Hier gibt es eine Handvoll Optionen:

  1. Schalten Sie die Funktion im ausgelieferten Produkt aus. Nur weil der Code im Produkt enthalten ist, muss er nicht ausgeführt oder den Benutzern präsentiert werden. Der Nachteil ist, dass Sie Ihren Nutzern keinen Mehrwert bieten und kein Feedback erhalten.
  2. Zeigen Sie Ihren Benutzern die Kanten des Features an. Zeigen Sie, was Sie haben, und geben Sie an, was noch kommt.
  3. Ermöglichen Sie Benutzern den Wechsel zwischen neuer und alter Funktionalität. Dies erfordert manchmal die Verwaltung von zwei Codepfaden, die für den Endbenutzer bereit sind.

Wenn Sie Probleme mit einer dieser Lösungen haben, prüfen Sie, ob Sie das Feature an den richtigen Grenzen aufgeteilt haben. Wenn Sie die Dinge auf eine andere Weise in Scheiben schneiden würden, wäre es dann einfacher, sie auseinander zu ziehen?

Alex Feinman
quelle
Es ist einfach genug, eine neue Funktion auszuschalten, die noch nicht vollständig bereit ist. Das ist ein guter Rat. Das Kernproblem des ausgelieferten Produkts besteht darin, dass EXISTIERENDE Funktionen möglicherweise nicht mehr funktionieren, wenn Benutzer beim Ändern des vorhandenen Codes nicht den richtigen Ansatz verwenden.
Niels Brinch
2
Hier kommen gute Tests ins Spiel. Wenn Sie keine ausreichende Abdeckung für Ihre Codebasis haben, könnte dies möglicherweise ein Auslöser für diese Bemühungen sein?
Alex Feinman
Aber kann die Antwort auf meine Frage einfach lauten: "Gute Code-Praxis durchführen und Komponententests durchführen" usw.?
Niels Brinch
1

Wie stelle ich sicher, dass die Teammitglieder den richtigen Ansatz zur Implementierung einer halben Funktion kennen?

Indem ich sie unterrichte. (duh)

Das Lernen umfasst eine Iteration: Probieren Sie etwas aus, sehen Sie, wie es funktioniert, und ändern Sie dann den Ansatz, um bessere Ergebnisse zu erzielen. Für diese Art von Dingen würde ich Design- / Code-Reviews befürworten. Sie können sehen, wie das halbe Feature entworfen / implementiert ist, und haben die Möglichkeit, Feedback zu geben. "Dies und das wird nicht funktionieren, weil sie unser CI brechen werden; wie wäre es mit XYZ?", "Gute Arbeit hier, das ist wirklich sauber."

Wenn Sie die Reviews als Team durchführen, können alle lernen, was Sie bereits intuitiv wissen.

Telastyn
quelle
Ich bin voll dabei. Aber genauso wie ich jemandem beibringen kann, wie man Komponententests durchführt, ODER sie auf das Buch "Die Kunst des Komponententests" verweisen kann - gibt es eine ähnliche Ressource, auf die ich für dieses Thema verweisen kann?
Niels Brinch
1

Das Wichtigste, was Ihnen dabei helfen wird, ist eine gute Trennung der Bedenken, damit sich ein Codebereich so weit wie möglich nicht auf einen anderen auswirkt.

Dies ist ein Ort, an dem die Verwendung von Dependency Injection und die Programmierung der Benutzeroberfläche wirklich hilfreich sind, damit Sie Ihre aktuelle Implementierung von ISupportingFeature auf der Site haben können. Wenn Sie dann INewFeature erstellen müssen, das von einer anderen Implementierung abhängt, können Sie einfach mit dem entwickeln Neuimplementierung und Beibehaltung der vorhandenen Implementierung in der Produktion, bis sie gut getestet und einsatzbereit ist. Angenommen, Ihre DI arbeitet an einem Konfigurationssystem, dann können Sie denselben Code parallel in Ihrem System verwenden und jederzeit stabilen Code verwenden.

Tatsächlich wird dieser Konfigurationsansatz von Martin Fowler als Feature Toggle beschrieben.

Das Problem tritt natürlich nur auf, wenn Sie den gesamten Code ständig bereitstellen. Dies ist genau die Art von Szenario, für die Feature-Zweige entworfen wurden, und obwohl ich anerkenne, dass Mr. Fowler sie missbilligt, weiß ich nicht, dass sie alle so schlimm sind, besonders wenn sie in einem geplanten und durchdachten Prozess erstellt und verwendet werden. durch den Weg.

Glenatron
quelle
Ich habe den Eindruck, dass es Teil einer guten Strategie der kontinuierlichen Integration ist, den gesamten Code in der gleichen Branche zu speichern und den gesamten Code ständig bereitzustellen.
Niels Brinch
Das Lesen von Continuous Delivery ist sicherlich ein Teil davon. Bei dem Gedanken daran zucke ich ein wenig zusammen - möchten Sie halbgeschriebenen Code bereitstellen, auch wenn er deaktiviert werden sollte ? Vielleicht funktioniert es in einem Szenario, in dem Sicherheit nicht wichtig ist, aber es klingt nach einem risikoreichen Ansatz für viele Anwendungsbereiche. Dies kennzeichnet mich wahrscheinlich als einen altmodischen, sicherheitsliebenden, blöden Typen.
Glenatron
Es scheint zwei konkurrierende Strategien zu geben, bei denen eine einen einzigen Hauptzweig und eine andere einen Zweig für jede Aufgabe und viele Zusammenführungen hat. Ich bin nicht sicher, was am besten oder richtig ist - oder ob es den Kern meiner Fragen trifft.
Niels Brinch
Ich denke, es hängt sehr von der Art der Dinge ab, die Sie machen. Ich würde eher zu Branchen tendieren, wenn ich der Sicherheit Priorität einräumen würde und nicht riskieren wollte, ungetesteten Code dort zu implementieren, wo ihn jemand finden könnte oder versehentlich aktiviert. Wenn ich also eine Bank-Site betreiben würde, wäre CD meiner Meinung nach nicht das Richtige, aber wenn ich eine umsatzstarke Website für gelegentliche Besucher betreiben würde, wäre dies möglicherweise ideal.
Glenatron