it-swarm.com.de

Ist es jemals in Ordnung, nicht funktionierenden Code festzuschreiben?

Ist es eine gute Idee, nur Arbeitscode festzuschreiben?

Dieses Commit muss das Repository nicht wie folgt belassen:

  • ... wir befinden uns in einem frühen Entwurfsstadium, der Code ist noch nicht stabil.
  • ... Sie sind der einzige Entwickler des Projekts. Sie wissen, warum die Dinge nicht funktionieren. Darüber hinaus stoppen Sie die Arbeit von niemandem, indem Sie fehlerhaften Code festschreiben.
  • ... der Code funktioniert derzeit nicht. Wir werden eine große Änderung daran vornehmen. Lassen Sie uns festlegen, um einen Punkt zu finden, auf den wir zurückgreifen können, wenn die Dinge hässlich werden.
  • ... die Kette ist lang, kein Problem, wenn defekter Code in der lokalen Niederlassung vorhanden ist. Das heißt,.

    1. lokale Dateien
    2. bühnenbereich
    3. commits in der lokalen Niederlassung
    4. commits im Remote-Zweig für persönliche Funktionen
    5. mit Remote-Zweig develop zusammenführen
    6. mit Remote-Zweig master zusammenführen
    7. mit Remote-Zweig release zusammenführen
  • ... früh begehen, oft begehen.

In der oben verlinkten Frage heißt es in den meisten Antworten, dass das Festschreiben von nicht kompilierbarem Code in lokalen Zweigen und Feature-Zweigen kein Problem darstellt. Warum? Was ist der Wert eines fehlerhaften Commits?


Hinzugefügt: Es gibt ein paar hochstimmige Kommentare, die besagen, dass man auf einem lokalen Brach tun kann, was man will. Die technische Seite der Frage interessiert mich jedoch nicht. Vielmehr möchte ich die besten Praktiken kennenlernen - die Gewohnheiten, die Menschen, die viele Jahre in der Branche gearbeitet haben, am produktivsten verfolgen.


Ich bin erstaunt über die vielen tollen Antworten! Sie führen mich zu dem Schluss, dass ich nicht in der Lage bin, Zweige zum Organisieren meines Codes zu verwenden.

40
Vorac

Eine der Verzweigungsphilosophien (Abschnitt Entwickeln von Verzweigungsstrategien und Codeline-Richtlinien in Erweiterte SCM-Verzweigungsstrategien - lesen Sie auch Perforce Best Practices , es ist ein PDF, geht aber auf einige andere Details ein) dass Sie auf inkompatiblen Richtlinien verzweigen.

Eine Codeline-Richtlinie legt die faire Verwendung und die zulässigen Check-ins für die Codeline fest und ist das wesentliche Benutzerhandbuch für Codeline SCM. In der Richtlinie einer Entwicklungscodeline sollte beispielsweise angegeben werden, dass sie nicht zur Veröffentlichung vorgesehen ist. Ebenso sollte die Richtlinie einer Release-Codeline Änderungen an genehmigten Fehlerkorrekturen beschränken. Die Richtlinie kann auch beschreiben, wie Änderungen dokumentiert werden, die eingecheckt werden, welche Überprüfung erforderlich ist, welche Tests erforderlich sind und welche Erwartungen an die Stabilität der Codeline nach dem Einchecken bestehen. Eine Richtlinie ist eine wichtige Komponente für einen dokumentierten, durchsetzbaren Softwareentwicklungsprozess, und eine Codeline ohne Richtlinie ist aus SCM-Sicht außer Kontrolle geraten.

(aus Perforce Best Practices)

Angenommen, Sie haben die Zweige "Release" (oder "Master"), aus denen ein Release erstellt wird, und "Trunk" (oder "Dev"), in denen Entwickler Arbeitscode einchecken. Dies sind die Richtlinien der Niederlassungen. Wenn man feststellt, dass der 'Arbeitscode' Teil der 'dev'-Zweigrichtlinie ist, sollte man niemals defekten Code an den dev-Zweig übergeben. Oft gibt es Dinge wie CI-Server, die an diese Zweige angeschlossen sind, und das Einchecken von fehlerhaftem Code in dev kann den Zweig aller durcheinander bringen und den Build unterbrechen.

Es gibt jedoch Situationen, in denen es angebracht ist, Teilcode einzuchecken, der nicht funktioniert. In diesen Fällen sollte man verzweigen - eine inkompatible Richtlinie mit Trunk. In diesem neuen Zweig kann man die Richtlinie festlegen ('defekter Code ist in Ordnung') und dann Code festschreiben.

Es gibt eine einfache Regel, um zu bestimmen, ob eine Codeline verzweigt werden soll: Sie sollte verzweigt werden, wenn ihre Benutzer unterschiedliche Eincheckrichtlinien benötigen. Beispielsweise benötigt eine Produktfreigabegruppe möglicherweise eine Eincheckrichtlinie, die strenge Tests erzwingt, während ein Entwicklungsteam möglicherweise eine Richtlinie benötigt, die häufiges Einchecken von teilweise getesteten Änderungen ermöglicht. Diese Richtliniendivergenz erfordert einen Codeline-Zweig. Wenn eine Entwicklungsgruppe keine andere sehen möchte

(aus Perforce Best Practices)

Stellen Sie fest, dass dies von einem zentralen serverbasierten SCM mit einer starken Unternehmensphilosophie kommt. Die Kernidee ist immer noch gut. Diese werden oft implizit in Betracht gezogen - Sie checken keinen ungetesteten Entwicklungscode in den Release-Zweig ein. Das ist eine Politik.

Verzweigen Sie also, sagen Sie, dass dieser Zweig fehlerhaften Code haben und wegschreiben kann.

20
user40980

Eine der von Linus Torvalds vorgeschlagenen Philosophien ist, dass kreatives Programmieren wie eine Reihe von Experimenten sein sollte. Sie haben eine Idee und folgen ihr. Es klappt nicht immer, aber zumindest hast du es versucht. Sie möchten Entwickler dazu ermutigen, kreative Ideen auszuprobieren, und um dies zu tun, muss es billig sein, dieses Experiment auszuprobieren, und billig, sich zu erholen. Dies ist die wahre Kraft von Git Commits, die so billig sind (schnell und einfach). Es eröffnet dieses kreative Paradigma, das es Entwicklern ermöglicht, Dinge auszuprobieren, die sie sonst möglicherweise nicht haben. Dies ist die Befreiung von Git.

40
WarrenT

Ja, solange es sich nicht um einen Release-Zweig handelt.

In persönlichen Zweigen geht alles und kann dann verworfen werden, wenn das Experiment nicht funktioniert hat. Das ist einer der Hauptvorteile von DVCS: Freiheit

Der Wert des Festschreibens von fehlerhaftem Code?: Zusammenarbeit und Experimentieren

10
dukeofgaming

Ja, es ist in Ordnung und ich mache viel.

Der Punkt beim Festschreiben von nicht kompilierbarem Code (zumindest in Zweigen) besteht darin, dass Ihr Code manchmal in Arbeit ist, dass es sich jedoch lohnt, die bisher geleistete Arbeit zu speichern und/oder mit anderen zu teilen

Meine Praktiken sind:

  • schreibe zuerst Tests
  • wip (Work-in-Progress) Commits sind gut
  • häufig (mehrere innerhalb eines Tages) und früh festlegen (Arbeitsschritte speichern)
  • Drücken Sie nach jedem Commit (falls Ihre Festplatte abstürzt oder der Bus Sie trifft).
  • arbeiten Sie immer zuerst in Filialen
  • wenn möglich nur im Arbeitscode zum Master zusammenführen
  • interaktive Rebase in Git, um Wips vor dem Master-Merge zu quetschen

Das Hauptproblem und vielleicht das, das Sie ansprechen, ist, wenn Sie eine Funktion haben, die im Grunde funktioniert und vom Unternehmen dringend benötigt wird (und daher in "Master" sein muss), aber einige fehlgeschlagene Tests hat. Eine Möglichkeit besteht darin, einen ausstehenden Test durchzuführen, mit dem Sie vorerst fortfahren können. Dies ist jedoch mit Gefahren behaftet, da der Test möglicherweise nie repariert wird und in anderen Bereichen ein Muster festgelegt werden kann, bei dem fehlerhafte Tests einfach "ausstehen", anstatt sie zu reparieren.

Eine andere Möglichkeit wäre, den Zweig vorübergehend zu verwenden und bereitzustellen. Dies kann in bestimmten Situationen hilfreich sein, wird jedoch im Allgemeinen nicht empfohlen und ist nicht nachhaltig.

Vielleicht ist die beste Option, im Grunde genommen einen professionelleren Ansatz für die Softwareentwicklung zu wählen und wirklich Arbeitstests für jeden festgeschriebenen Code zu erfordern. Dies ist häufig der "schwierige" Teil der Softwareentwicklung, nicht die Codierung, die sich viele Menschen vorstellen. Ein besserer Ansatz erfordert wahrscheinlich bessere anfängliche Schätzungen, Ressourcenzuweisung, Prioritätensetzung usw. sowie während der agilen Entwicklung ausreichend Zeit und Disziplin, um Probleme sowohl zum Zeitpunkt ihres Auftretens als auch während der Pflege-Pointing-Sitzungen zu beheben.

Konzentrieren Sie sich darauf, was "erledigt" bedeutet - es bedeutet, dass der Code UND die Tests geschrieben wurden, überarbeitet wurden und funktionieren. Wenn Sie Kommentare wie "Meistens erledigt, müssen nur Tests schreiben/reparieren/umgestalten" hören, dann wird dies NICHT getan. Zu sagen, dass eine Funktion ausgeführt wird, ohne dass sie technisch vollständig ist, ist einer der häufigsten Fehler von Junior-Programmierern.

6
Michael Durrant

Der Wert eines Commits, ob fehlerhaft oder nicht, ist, dass der Code an einen Server festgeschrieben wird. In professionellen Umgebungen ist dieser Server sicher, redundant und führt Sicherungen aus. Wenn ich den ganzen Tag arbeite, ist das Festschreiben eine Form, um sicherzustellen, dass mein Code alles überlebt, was mit meinem lokalen Computer passiert. Festplatten sterben. Laptops gehen verloren oder werden gestohlen. Backups des Repository-Servers sind auch dann verfügbar, wenn das Gebäude niederbrennt.

3
nvoigt

Denken Sie so darüber nach. Als Entwickler ist es eines der störendsten Dinge, die Sie tun, andere Entwickler in Ihrem Team daran zu hindern, an ihren Aufgaben zu arbeiten.

Die Philosophie, nur Arbeitscode festzuschreiben, stammt von Entwicklungsteams, die an demselben einzelnen Trunk im Repository arbeiten. Es mag jetzt wie Wahnsinn erscheinen, aber vor 10 Jahren war dies die normale Arbeitsweise. Ein Zweig wurde angezeigt, wenn Sie eine stabile Version erstellen wollten, aber der Gedanke an einen Entwickler, der in einem Zweig arbeitet, um eine neue Funktion zu implementieren, war fast unbekannt.

Wenn Ihre Umgebung bedeutet, dass Ihre Commits andere Entwickler nicht sofort betreffen, setzen Sie sie häufig fest. Es gibt Ihnen mehr Sicherheit in Ihrem Code, was das Zurücksetzen eines Codefehlers erleichtert, und viele Versionsverwaltungssysteme bieten Ihnen einen gewissen Codeschutz für festgeschriebenen Code (wenn auch nicht alle).

Stellen Sie nun sicher, dass Ihre Zusammenführungen mit Zweigen, die mit anderen Entwicklern geteilt wurden, funktionieren und dass jeder Code, den Sie auf dieser Ebene bewerben, alle Komponententests und andere teambasierte Überprüfung der Integrität besteht. Dies ist wichtig, wenn Sie dies nicht möchten kaufe das Bier weiter in der Kneipe ...

3
Michael Shaw

Bevor Sie dogmatisch werden, wie Sie mit Ihrer Versionskontrolle arbeiten, sollten Sie sich überlegen, warum Sie mit der Versionskontrolle arbeiten.

Wenn Sie sich zur Versionskontrolle verpflichten, wird der Status Ihres Codes zum späteren Nachschlagen eingefroren - alles andere fällt daraus heraus. Wenn Sie sich Unterschiede ansehen und Patches erstellen, sehen Sie nur, wie sich der Code zwischen den Snapshots geändert hat. Zweige und Tags sind nur Möglichkeiten zum Organisieren von Schnappschüssen. Wenn Sie Code mit anderen Entwicklern teilen, können sie sich nur einen bestimmten Schnappschuss ansehen.

Wann sollten Sie sich verpflichten? Wenn eine vernünftige Chance besteht, werden Sie in Zukunft den Status Ihres Codes (oder die Festschreibungsnachricht, die eine Änderung erklärt) überprüfen.

Git bietet Ihnen viel Flexibilität bei der Organisation Ihrer Schnappschüsse. Es gibt kein zentrales Repository, sodass Sie Ihren Code für andere Entwickler freigeben können, ohne Ihren Status in das Haupt-Repository zu verschieben. Sie können Zweige einfach erstellen, zusammenführen und löschen, um die Details einer Reihe von Zuständen von der Erzählung des Hauptcodes zu isolieren. Sie können ein lokales Commit durchführen, um die Verfolgung Ihrer aktuellen Entwicklung rückgängig zu machen, und dann alles zu einem einzigen Commit zusammenfassen, bevor Sie es für andere sichtbar machen. Sie können bestimmte Revisionen mit Tags versehen, damit sie später leicht gefunden werden können.

KUSS . Was für einen einzelnen Entwickler in den frühen Phasen der Entwicklung eines kleinen Projekts am besten funktioniert, wird völlig anders sein als das, was Sie tun müssen, wenn hundert Entwickler an einem zehn Jahre alten, geschäftskritischen System arbeiten. In jedem Softwareentwicklungsprozess sollten Sie vermeiden, unnötige Artefakte zu erstellen, nur weil Ihnen jemand anderes gesagt hat, dass Sie dies tun sollen.

3

Zweige erstellen/freigeben

Sie sollten niemals absichtlich fehlerhaften Code in einen Build-Zweig übertragen. Jeder Zweig, der kontinuierlich integriert ist oder aus dem Releases oder tägliche Builds erstellt werden, sollte sich immer in einem potenziell freisetzbaren Zustand befinden.

Andere Zweige: Status häufig speichern

Für private oder Feature-Filialen sind die Ziele oft unterschiedlich. Ein häufiges Einchecken von Code (ob funktioniert oder nicht) kann wünschenswert sein. Im Allgemeinen möchten Sie jederzeit festlegen, wann immer Sie zum aktuellen Status zurückspulen müssen.

Betrachten Sie diese Beispiele, bei denen der gespeicherte Status einen erheblichen Vorteil bietet:

  • Sie können ein Commit ausführen, bevor Sie ein globales Suchen und Ersetzen ausführen, damit Sie Ihren Baum in einem einzigen Vorgang zurücksetzen können, wenn etwas schief geht.
  • Sie können eine Reihe von Zwischen-Commits ausführen, während Sie einen komplexen Code umgestalten, damit Sie ihn halbieren oder zurückspulen können, wenn Sie dabei etwas kaputt machen.
  • Sie können ein Commit durchführen, einen neuen Zweig starten oder ein Tag erstellen, wenn Sie etwas Experimentelles ausprobieren möchten, während Sie jederzeit zum Status des aktuellen Arbeitsbaums zurückkehren können.
2
CodeGnome

Ich denke nicht, dass es in Ordnung ist, fehlerhaften Code festzuschreiben.

Was passiert wenn

  • Ein dringender Hotfix ist erforderlich. Die Codebasis ist defekt. Sie müssen ein Rollback durchführen, Fehler beheben und bereitstellen.

  • Jemand anderes beginnt in derselben Branche zu arbeiten, ohne zu wissen, dass Sie fehlerhaften Code festgeschrieben haben. Sie könnten einem "roten Hering" nachjagen und denken, dass ihre Veränderungen etwas gebrochen haben.

  • Sie entscheiden sich, das Unternehmen zu verlassen, Urlaub zu machen oder aus irgendeinem Grund nicht zur Arbeit zu kommen. Ihre Kollegen müssen tief graben, um herauszufinden, was kaputt ist und warum es in einem kaputten Zustand begangen wurde.

  • Jemand stellt Ihren "kaputten Code" bereit? Dies kann ein "Spiel vorbei" sein, wenn Sie mit persönlichen Daten oder bei einem Zahlungsanbieter arbeiten.

Antwort an @WarrenT

Ich stimme Ihnen zu, dass in einer idealen Welt, in der jeder in einem Feature-Zweig arbeitet, das Festschreiben von nicht funktionierendem Code möglicherweise funktioniert. Ich habe an großen Projekten gearbeitet, und selbst dann gab es Fälle, in denen mehrere Personen in einem einzigen Feature-Zweig arbeiten mussten. Ich habe auch gesehen, dass Leute "nicht funktionierenden" Code für den Hauptzweig festschreiben, weil die Veröffentlichung Wochen entfernt war und sie planten, ihn am nächsten Tag zu reparieren. All diese Dinge sind Kandidaten für eine Katastrophe und ich bin der festen Überzeugung, dass sie um jeden Preis vermieden werden sollten.

0
CodeART

Das Festschreiben einer fehlerhaften Codebasis ist in Ordnung, solange es lokal ist.

Warum?

  • Es ist wichtig, das Festschreiben als Speicherpunkt für Ihre Entwicklung zu verwenden
  • Es zeigt Ihnen ein Denkmuster, das bei der Entwicklung des Produkts verwendet wird.
  • Es bricht die Zusammenarbeit nicht.

Wenn es jedoch ein Team von Programmierern gibt, ist die Philosophie des Programmierhauses von größter Bedeutung und ersetzt das Verhalten einzelner Commits. Einige Programmierhäuser beschließen, den gesamten Fortschritt zu protokollieren, während andere beschließen, nur Code festzuschreiben, der eine Funktion löst. In diesem Fall ist der Wert (Kosten aus Sicht der Softwareverwaltung) eines fehlerhaften Commits schrecklich:

  1. die Zeit, die für weitere Funktionen benötigt wird, wird jetzt für die Behebung von Fehlern aufgewendet ...
  2. der Entwicklungsschnitt wird nicht erreicht ...
  3. produkt wird nicht rechtzeitig versendet

Zu diesen drei Punkten können weitere Punkte hinzugefügt werden, die ihre Auswirkungen exponentiell in einen Unternehmenszusammenbruch umwandeln. Dies muss natürlich ein Effekt der chronischen Gewohnheit sein, schlechten Code zu begehen.

0
iGbanam