Einchecken von "auskommentiertem" Code [geschlossen]


94

Ok, hier ist etwas, das bei meinem aktuellen Job zu Reibereien geführt hat, und ich habe es wirklich nicht erwartet. Die interne Softwareentwicklung ist hier ein neues Konzept, und ich habe einen ersten Entwurf einiger Codierungsrichtlinien erstellt.

Ich habe vorgeschlagen, dass "auskommentierter" Code niemals in das Repository eingecheckt werden sollte. Der Grund, warum ich dies angegeben habe, ist, dass das Repository einen vollständigen Verlauf der Dateien verwaltet. Wenn Sie den Funktionscode entfernen, entfernen Sie ihn vollständig. Das Repository speichert Ihre Änderungen, sodass Sie leicht sehen können, was geändert wurde.

Dies hat zu Reibereien geführt, da ein anderer Entwickler der Ansicht ist, dass dieser Weg zu restriktiv ist. Dieser Entwickler möchte in der Lage sein, Code zu kommentieren, an dem er arbeitet, der jedoch unvollständig ist. Dieser Code wäre dann noch nie eingecheckt und dann nirgendwo gespeichert worden. Wir werden TFS verwenden, daher schlug ich vor, dass das Zurückstellen der Änderungen die richtigste Lösung wäre. Es wurde jedoch nicht akzeptiert, da er Teiländerungen einchecken möchte, die möglicherweise bereitgestellt werden oder nicht.

Wir möchten irgendwann einen Punkt erreichen, an dem wir die kontinuierliche Integration voll ausnutzen und automatisch auf einem Entwicklungswebserver bereitstellen. Derzeit gibt es keine Entwicklungsversion von Webservern oder Datenbankservern, aber das wird bald geändert.

Wie auch immer, was denkst du? Glauben Sie, dass "auskommentierter" Code nützlich ist, um ihn im Repository zu haben?

Ich bin sehr daran interessiert, von anderen zu diesem Thema zu hören.

Bearbeiten: Aus Gründen der Übersichtlichkeit verwenden wir keine privaten Zweige. Wenn wir das tun würden, würde ich sagen, mach was du willst mit deiner privaten Filiale, aber füge niemals auskommentierten Code mit der Amtsleitung oder einer gemeinsam genutzten Filiale zusammen.

Bearbeiten: Es gibt keinen gültigen Grund, warum wir keine privaten oder Zweige pro Benutzer verwenden. Es ist kein Konzept, mit dem ich nicht einverstanden bin. Wir haben es einfach noch nicht so eingerichtet. Vielleicht ist das der mögliche Mittelweg. Im Moment verwenden wir TFS-Regale.


2
Stellen Sie sicher, dass Sie Ihre Entwickler umfassend in der richtigen Verwendung von TFS schulen. Meine Arbeitsgruppe hatte erhebliche Probleme mit TFS, was zu einem Codeverlust für mich geführt hat. Möglicherweise war ein "ID10T" -Fehler aufgetreten, aber ich vertraue TFS immer noch nicht.
James Schek

@ John: Gibt es Gründe, warum Sie keine privaten Filialen zulassen? Das würde das Problem lösen, er könnte dort gerne alles einreichen und speichern, und Sie würden sich in der Hauptniederlassung überhaupt nicht darum kümmern.
Frank

@null - wie in der Bearbeitung erwähnt, habe ich kein Problem mit ihnen, wir haben es nur noch nicht getan. Das Problem in diesem Szenario ist jedoch, dass wir nicht von einer privaten Niederlassung freigeben und er eine Teillösung bereitstellen möchte.
John


Antworten:


123

Es mag andere mit unterschiedlichen Erfahrungen geben, aber bei mir ist das Einchecken von halbfertigem Code eine schreckliche Idee, Punkt.

Hier sind die Prinzipien, die ich gelernt habe und die ich zu befolgen versuche:

  • Checken Sie häufig ein - mindestens einmal, vorzugsweise jedoch mehrmals täglich
  • Checken Sie nur die vollständige Funktionalität ein
  • Wenn der erste und der zweite Konflikt (z. B. dauert es mehr als einen Tag, bis die Funktionalität funktioniert), ist die Aufgabe zu groß - teilen Sie sie in kleinere abschließbare Aufgaben auf.

Das heisst:

  • Auskommentierter Code sollte niemals eingecheckt werden, da er nicht funktioniert
  • Das Kommentieren ist keine gültige Archivierungsstrategie. Unabhängig davon, ob es sich um noch ausstehenden Code handelt oder um Code, der in den Ruhestand versetzt wird, macht das Kommentieren und Einchecken keinen Sinn.

Also zusammenfassend NEIN! Wenn der Code nicht bereit ist, mit der nächsten Stufe fortzufahren (je nachdem, was für Sie bestimmt ist: IntTest / QA / UAT / PreProd / Prod), sollte er nicht an einen Trunk- oder Multi-Developer-Zweig gebunden werden. Zeitraum.

Bearbeiten: Nachdem ich die anderen Antworten und Kommentare gelesen habe, füge ich hinzu, dass ich es nicht unbedingt für eine gute Idee halte , kommentierten Code zu verbieten (nicht sicher, wie Sie das überhaupt durchsetzen würden). Was ich sagen werde, ist, dass Sie alle in Ihrem Team dazu bringen sollten, sich der oben beschriebenen Philosophie anzuschließen. Das Team, an dem ich arbeite, nimmt es von ganzem Herzen an. Infolgedessen ist die Quellcodeverwaltung ein reibungsloses Teammitglied, das uns hilft, unsere Arbeit zu erledigen.

Menschen, die diese Philosophie nicht akzeptieren, verursachen normalerweise zerbrochene Fenster und sind oft frustriert über die Quellcodeverwaltung. Sie sehen es bestenfalls als notwendiges Übel und im schlimmsten Fall als etwas, das sie vermeiden sollten. Dies führt zu seltenen Checkins, was bedeutet, dass Änderungssätze sehr groß und schwer zusammenzuführen sind, was die Frustration verstärkt, Checkins zu etwas macht, das noch mehr vermieden werden muss usw. Dies ist letztendlich eine Einstellungssache, nicht wirklich eine Prozesssache. Es ist leicht, mentale Barrieren dagegen zu errichten. Es ist leicht, Gründe zu finden, warum es nicht funktioniert, genauso wie es leicht ist, Gründe zu finden, warum man keine Diät macht, wenn man es nicht wirklich will. Aber wenn Menschen dies tun wollen und sich dazu verpflichten, ihre Gewohnheiten zu ändern, sind die Ergebnisse dramatisch. Es liegt an Ihnen, es effektiv zu verkaufen.


2
Ich stimme Ihrer Klarstellung zu - checken Sie niemals einen halbfertigen Code in den "Trunk" ein oder was auch immer das Äquivalent ist. Es sollte immer einen Zweig / Trunk geben, der die Version "Dieser Code funktioniert immer" hat. Gehen Sie voran und checken Sie halb fertig in einer privaten Entwicklungsabteilung, einem lokalen Spiegel, einem Regal usw. ein.
James Schek

2
@ Eddie-Kommentare sind per Definition nicht gezwungen, mit dem Rest der Codebasis synchron zu bleiben. Sie können abgestanden und irreführend werden und zu zerbrochenen Fenstern des Systems beitragen. All diese Dinge sind ein Risiko für die Zeit des Entwicklers. Davon haben wir schon genug. Es ist leicht genug, dies zu vermeiden
Rex M

2
@ Rex M: IMO, Kommentare sind ein wesentlicher Bestandteil des Codes. In jedem Code, den ich pflege, bleiben Kommentare garantiert mit dem Rest der Codebasis synchron. Code, bei dem Kommentare nicht synchron sind, ist fehlerhaft. Sie können es nur noch nicht wissen.
Eddie

2
@ John: Es hört sich so an, als ob dieser Defekt durch ein Versehen des Entwicklers verursacht wurde. Wie hätte ein Verbot des Eincheckens von auskommentiertem Code den Entwickler daran gehindert, dieses Versehen zu übernehmen? Das Verbot gibt Ihnen nur ZWEI Dinge, die Sie bestrafen müssen, anstatt eines. Es verhindert nicht das Versehen.
Eddie

9
Ich hätte fast dafür gestimmt, aber es kommt wirklich selten vor, dass ich an nur einem Arbeitstag etwas bekomme, an dem ich im Check-in-Zustand arbeite. Ich nehme an, es ist möglich, dass Sie ein viel besserer Entwickler sind als ich, aber ich entscheide mich zu glauben, dass ich an härteren Dingen arbeite als Sie. :-)
TED

43

"Nie" ist selten ein gutes Wort für Richtlinien.

Ihr Kollege hat ein gutes Beispiel dafür, wann es angebracht sein könnte, auskommentierten Code einzuchecken: Wenn er unvollständig ist und die Anwendung möglicherweise beschädigt, wenn er eingecheckt wird, während er aktiv ist.

In einem gut verwalteten, änderungsgesteuerten System ist das Auskommentieren von totem Code größtenteils nicht erforderlich. Aber nicht jeder kommentierte Code ist "tot".


9
Ich bin nicht einverstanden. Wenn der Code unvollständig ist, warum wird er überhaupt eingecheckt? Moderne Versionsverwaltungssysteme verfügen über Mechanismen zum Hochladen laufender Funktionen, ohne sich auf den Trunk festzulegen.
Rex M

9
+1, manchmal ist dies am besten geeignet. Nicht immer, aber auch nie . Nie ist leicht zu sagen, aber zu restriktiv.
Eddie

@Rex Ich glaube nicht, dass der ursprüngliche Beitrag genügend Informationen enthält, um den Unterschied zwischen dem Hochladen laufender Funktionen und dem Festschreiben an den Trunk festzustellen.
Jason Coco

Rex - was ist das? Nie unvollständig einchecken? Oder nie unvollständig in den Kofferraum einchecken? Das ist nicht dasselbe.
James Schek

@Jason "Entwickler möchte in der Lage sein, Code zu kommentieren, an dem er arbeitet, der jedoch unvollständig ist". Klingt so, als ob er laufende Funktionen für mich einchecken möchte.
Rex M

24

Auskommentierter Code sollte niemals eingecheckt werden, um den Verlauf aufrechtzuerhalten. Das ist der Punkt der Quellcodeverwaltung.

Hier wird viel über Ideale gesprochen. Vielleicht muss ich anders als alle anderen an mehreren Projekten mit mehreren Unterbrechungen arbeiten, wobei die "reale Welt" gelegentlich meinen Arbeitstag unterbrach.

In Wirklichkeit muss ich manchmal teilweise vollständigen Code einchecken. Es besteht entweder die Gefahr, dass der Code verloren geht oder dass unvollständiger Code eingecheckt wird. Ich kann es mir nicht immer leisten, eine noch so kleine Aufgabe zu "erledigen". Aber ich werde nicht meinen Laptop vom Netz trennen , ohne Check-in jedem Code.

Bei Bedarf werde ich einen eigenen Arbeitszweig erstellen, um teilweise Änderungen vorzunehmen.


4
@James dein letztes Bit ist der Schlüssel - wenn du keinen Arbeitscode einchecken kannst, dann finde einen anderen Ort, an dem du ihn ablegen kannst. Ob das ein Zweig oder ein Regalset ist oder was auch immer.
Rex M

Wenn ich dieses mehr als einmal positiv bewerten könnte, würde ich es tun. Meine Gefühle genau!
Ola Eldøy

23

Ein Fall, in dem ich auskommentierten Code weglasse:

// This approach doesn't work
// Blah, blah, blah

wenn das die offensichtliche Herangehensweise an das Problem ist, aber einen subtilen Fehler enthält. Sicher, das Repository würde es haben, aber das Repository würde in Zukunft niemanden warnen, diesen Weg nicht zu gehen.


6
Wenn es auf eine Zeile beschränkt wäre, könnte dies eine Ausnahme sein. Ich würde lieber einen kurzen Blockkommentar sehen (ein paar Zeilen oben), in dem die Gründe für einen Ansatz gegen einen anderen genannt werden. In diesem Fall würde ich das nicht als "auskommentiert", sondern als dokumentiert betrachten.
John

3
+1. Ein Beispiel, das ich gesehen habe, ist, wo etwas kaputt gegangen ist, weil der Code ein soTIMEOUT gesetzt hat. Das Update bestand darin, es zu entfernen. Wenn Sie nur die Codezeile entfernen, kann es sein, dass jemand sie später erneut einführt und denkt, dass er einen Fehler auf diese Weise behebt, aber tatsächlich führt er einen Fehler erneut ein.
Eddie

1
Ja, das ist meine Idee - sicherzustellen, dass der Fehler in Zukunft nicht wieder eingeführt wird. Wenn sie den eigentlichen Code verlassen, können sie sehen, dass es nicht nur ein Fehler in der Art und Weise war, wie das Original geschrieben wurde.
Loren Pechtel

In diesem Fall halte ich dies nicht für "auskommentierten Code", sondern für eine Dokumentation.
Hlovdal

1
Dies ist das einzige Beispiel, in dem ich auskommentierten Code live lassen habe. In diesem Fall ist es nicht die halbherzige Idee von jemandem, die die Wartungsprogrammierer verwirrt, sondern [hoffentlich] ein legitimes, funktionales Beispiel für Code, das die App vollständig kaputt macht, aber ansonsten der offensichtliche Ansatz ist.
Worc

19

Ich würde auf jeden Fall davon abraten, jemals auskommentierten Code einzuchecken. Ich würde es jedoch nicht absolut verbieten. Manchmal (wenn auch selten) ist es angebracht, auskommentierten Code in die Quellcodeverwaltung einzuchecken. "Mach das nie" zu sagen ist zu restriktiv.

Ich denke, wir sind uns alle in folgenden Punkten einig:

  • Überprüfen Sie niemals toten Code in der Quellcodeverwaltung
  • Überprüfen Sie niemals defekten (nicht funktionierenden) Code in der Quellcodeverwaltung, zumindest niemals in der Amtsleitung und nur sehr selten in einer privaten Zweigstelle, YMMV
  • Wenn Sie zu Debugging-Zwecken vorübergehend etwas auskommentiert oder beschädigt haben, checken Sie den Code erst ein, wenn Sie den Code in seiner korrekten Form wiederhergestellt haben

Einige von ihnen sagen, dass es andere Kategorien gibt, wie vorübergehend entfernten Code oder eine inkrementelle, aber unvollständige Verbesserung, die eine kleine Menge auskommentiertem Code als Dokumentation für das, was als nächstes kommt, oder einen sehr kurzen (idealerweise 1 Zeile) Ausschnitt aus Kommentaren enthält out Code, der etwas zeigt, das niemals wieder hinzugefügt werden sollte. Auskommentierter Code sollte IMMER von einem Kommentar begleitet werden, der angibt, warum er auskommentiert (und nicht nur gelöscht) wird und die erwartete Lebensdauer des auskommentierten Codes angibt. Beispiel: "Der folgende Code schadet mehr als er nützt, ist also auskommentiert, muss jedoch vor Release XXX ersetzt werden."

Ein Kommentar wie der oben genannte ist angemessen, wenn Sie einen Hotfix bereitstellen, um die Blutung eines Kunden zu stoppen, und Sie nicht sofort die Möglichkeit haben, den endgültigen Fix zu finden. Nach der Übermittlung des Hotfixes erinnert der auskommentierte Code daran, dass noch etwas repariert werden muss.

Wann checke ich auskommentierten Code ein? Ein Beispiel ist, wenn ich versuchsweise etwas entferne, von dem ich glaube, dass es mit hoher Wahrscheinlichkeit in naher Zukunft in irgendeiner Form wieder hinzugefügt werden muss. Der auskommentierte Code soll direkt daran erinnern, dass dies unvollständig ist. Sicher, die alte Version befindet sich in der Quellcodeverwaltung und Sie können einfach einen FIXME- Kommentar als Flag verwenden, dass etwas mehr benötigt wird. Manchmal (wenn nicht oft) ist Code jedoch der bessere Kommentar.

Wenn ein Fehler durch Entfernen einer Codezeile (oder seltener zwei Codezeilen) behoben wird, kommentiere ich die Zeile manchmal nur mit einem Kommentar aus, um diesen Code aus einem bestimmten Grund nie wieder zu aktivieren. Diese Art von Kommentar ist klar, direkt und prägnant.

Rex M sagte: 1) Nur die vollständige Funktionalität einchecken, 2) [Wenn] die Aufgabe zu groß ist - teilen Sie sie in kleinere abschließbare Aufgaben auf.

Antwort: Ja, das ist das Ideal. Manchmal ist keine der beiden Optionen erreichbar, wenn Sie an Produktionscode arbeiten und ein sofortiges, kritisches Problem zu beheben haben. Manchmal müssen Sie zum Ausführen einer Aufgabe eine Weile eine Codeversion in das Feld einfügen. Dies gilt insbesondere für Änderungen am Datenerfassungscode, wenn Sie versuchen, die Hauptursache eines Problems zu finden.

Für die spezifische Instanz, nach der in der allgemeineren Frage gefragt wird ... solange der Entwickler auskommentierten Code in einer privaten Zweigstelle eincheckt, die niemand außer diesem Entwickler (und möglicherweise jemandem, mit dem der Entwickler zusammenarbeitet) sieht, es schadet wenig. Aber dieser Entwickler sollte (fast) niemals solchen Code in Trunk oder einen gleichwertigen Code liefern. Kofferraum sollte immer bauen und immer funktionieren. Es ist fast immer eine sehr schlechte Idee, unfertigen Code an Trunk zu liefern. Wenn Sie einen Entwickler unfertigen oder temporären Code in eine private Zweigstelle einchecken lassen, müssen Sie sich darauf verlassen, dass der Entwickler nicht vergisst, den Code zu bereinigen, bevor er in den Trunk geliefert wird.

Um als Antwort auf Kommentare zu anderen Antworten zu verdeutlichen, wenn Code auskommentiert und eingecheckt ist, gehe ich davon aus, dass der Code funktioniert, wenn unkommentiert mit der Zeitspanne abfällt, in der der Code auskommentiert wurde. Offensichtlich enthalten Refactoring-Tools nicht immer Kommentare in ihrem Refactoring. Fast immer, wenn ich auskommentierten Code in die Produktion einbaue, dient der Code als verfeinerter Kommentar, etwas Spezifischeres als Prosa, dass dort etwas getan werden muss. Es ist nicht etwas, das ein langes Leben haben sollte.

Wenn Sie in jeder Quelldatei auskommentierten Code finden, stimmt etwas nicht. Das Ausliefern von auskommentiertem Code in den Trunk aus irgendeinem Grund sollte ein seltenes Ereignis sein. Wenn dies häufig vorkommt, wird es unübersichtlich und verliert seinen Wert.


4
@camh: Ein Problemverfolgungssystem bietet nicht den gleichen Kontext wie eine Erinnerung im Code selbst, im Kontext, mit einem kurzen Kommentar zum Problem. Die Problemverfolgung ist nicht so tief in die IDE integriert. Ihr Vorschlag verwirft viele Informationen aus Gründen des Dogmas.
Eddie

1
@ John: Nein, ich arbeite an Sachen mit Millionen von SLOC und Zehntausenden von Quelldateien. Wenn Sie der Meinung sind, dass die Art von Kommentar, auf die ich mich beziehe, Unordnung ist, bedeutet dies, dass Sie mich nicht verstehen und / oder dass ich nicht klar genug bin. Ich spreche von einem Randfall, der nicht häufig vorkommt, wie ich in Threads als Antwort auf Ihre Frage oft gesagt habe. Und hey, ist Ihr Geschäft nicht derjenige, der keine privaten Filialen betreibt? Sei nicht arrogant auf mich.
Eddie

1
@ John: Ein Beispiel finden Sie in meinem letzten Kommentar zu stackoverflow.com/questions/758279/… - und geben Sie mir eine bessere Möglichkeit , die erneute Einführung dieses Fehlers zu verhindern. Oder sagen Sie mir bei @camh, wie ein Problemverfolgungssystem die erneute Einführung dieses Fehlers verhindern würde. Wenn Sie an unternehmenskritischen 5-9-Geräten arbeiten, sind solche Dinge wichtig.
Eddie

1
@ John: Wie soll ich nicht beleidigt sein bei "Ich habe den deutlichen Eindruck, dass Sie hauptsächlich an kleinen Dingen arbeiten"? aka, nur weil wir uns über etwas ziemlich Kleines nicht einig sind, muss ich unerfahren sein? Sie haben natürlich immer ein Recht auf Ihre Meinung, und es ist in Ordnung, dass wir nicht einverstanden sind. Beachten Sie jedoch, dass ich Ihr Erfahrungsniveau nicht kritisiere, wenn ich mit Ihnen nicht einverstanden bin, nur weil wir die Dinge anders sehen. Tatsächlich stimme ich Ihnen zu 98% oder 99% zu. Ich mag Absolutismus einfach nicht.
Eddie

1
@Eddie - Die aktuelle Inkarnation Ihrer Antwort ist viel näher an der Übereinstimmung mit dem, was ich als Best Practice betrachten würde. Wie immer, wenn es um Best Practices geht, werden Sie niemals 100% ige Zustimmung von allen erhalten, dass irgendetwas eine legitime Best Practice ist. Ich hatte nicht damit gerechnet, als ich meine Frage gestellt habe :)
John

15

Ich denke nie ist eine zu starke Bedingung.

Ich neige dazu, Kommentare abzugeben, einzuchecken, Tests durchzuführen, nachzudenken und Kommentare nach der nächsten Veröffentlichung zu entfernen.


Wenn Sie die Tests noch nicht ausgeführt haben, sollten Sie sie noch nicht einchecken. Checken Sie keinen Code ein, der die Tests nicht besteht oder den Build auf andere Weise unterbricht.
John Saunders

@ John Saunders: Dies hängt davon ab, was das Einchecken in Ihrem Versionsverwaltungssystem bewirkt. Wenn Sie ClearCase mit UCM verwenden, befinden sich die Check-ins immer in einer privaten Zweigstelle, und es ist ein separater Schritt erforderlich, um zum Äquivalent von "TRUNK" zu wechseln.
Eddie

Genau, aber leider denken viele Entwickler, dass "Commit" dank CVS und SVN "Änderungen im Trunk einführen" bedeutet. Glücklicherweise lehren neue Systeme wie GIT neue Methoden ...
Pablo

@ John, ich meinte: auskommentieren, testen, einchecken ..! Du hast Recht.
Fortyrunner

14

Im Allgemeinen ist das Einchecken von auskommentiertem Code falsch, da dies zu Verwirrung bei denjenigen führt, die nicht der ursprüngliche Autor sind und den Code lesen oder ändern müssen. In jedem Fall ist der ursprüngliche Autor nach Ablauf von 3 Monaten häufig verwirrt über den Code.

Ich unterstütze die Überzeugung, dass der Code dem Unternehmen oder Team gehört und dass es in Ihrer Verantwortung liegt, Ihren Kollegen die Arbeit zu erleichtern. Das Einchecken von auskommentiertem Code, ohne auch einen Kommentar darüber hinzuzufügen, warum er beibehalten wird, bedeutet, Folgendes zu sagen:

Es macht mir nichts aus, wenn Sie am Ende verwirrt sind, warum dieses Zeug hier ist. Meine Bedürfnisse sind wichtiger als Ihre, weshalb ich dies getan habe. Ich habe nicht das Bedürfnis, Ihnen oder sonst jemandem zu rechtfertigen, warum ich das getan habe.

Auskommentierter Code wird für mich normalerweise als Zeichen der Respektlosigkeit eines weniger nachdenklichen Mitarbeiters angesehen.


3
Die letzte Zeile Ihres Beitrags ist tot. Ich wünschte, ich könnte dich mehr als einmal
abstimmen

2
Manchmal ist das, was für Sie bequem ist, nicht die einzige Überlegung. Natürlich besteht eine der wichtigsten Aufgaben eines Entwicklers darin, zukünftigen Entwicklern die Arbeit zu erleichtern, aber das muss mit anderen Interessen konkurrieren. Wenn Sie sich etwas sehr Unbequemes ansehen und sofort davon ausgehen, dass es hinzugefügt wurde, um Sie zu verärgern, zeigt sich eine sehr wichtige Einstellung von Ihrer Seite.
Andrew Shelansky

6

Ich stimme im Großen und Ganzen dem Grundsatz zu, dass auskommentierter Code nicht eingecheckt werden sollte. Das Versionsverwaltungssystem ist eine gemeinsam genutzte Ressource, und Ihr Kollege verwendet ihn bis zu einem gewissen Grad als seinen persönlichen Notizblock. Dies ist für die anderen Benutzer nicht sehr rücksichtsvoll, insbesondere wenn Sie die Idee des gemeinsamen Eigentums an der Codebasis abonnieren.

Der nächste Entwickler, der diesen auskommentierten Code sieht, hat keine Ahnung, dass er in Arbeit ist. Ist er frei, es zu ändern? Ist es toter Code? Er weiß es nicht.

Wenn sich die Änderung Ihres Kollegen nicht in einem Zustand befindet, in dem sie eingecheckt werden kann, muss er sie beenden und / oder lernen, kleinere, inkrementelle Änderungen vorzunehmen.

"Einchecken von Teiländerungen, die möglicherweise bereitgestellt werden oder nicht" - vermutlich bedeutet dies auch, dass sie getestet werden können oder nicht? Das ist ein rutschiger Hang zu einer sehr seiligen Codebasis.


6

Wenn Sie innerhalb der nächsten 3 Minuten eine kleine Funktion oder Fehlerbehebung wie JETZT hinzufügen müssen und eine Datei reparieren müssen, auf der Sie einen halb entwickelten Code haben, würde ich sagen, dass es in Ordnung ist, dass praktische Anforderungen über pragmatische Ideale auf dem Schlachtfeld herrschen.


Wo passt das Änderungsmanagement in dieses Szenario? Ich stimme zu, dass es Geschäfte gibt, in denen immer alles ein Großbrand ist, aber das bedeutet nicht, dass die Dinge so gemacht werden sollten. Ich würde auch vorschlagen, dass es ein Grund für das Problem sein könnte. Nicht genügend Kontrolle über die Codebasis.
John

1
Ich stimme voll und ganz zu, dass solche Dinge vermieden werden sollten, aber aus irgendeinem Grund scheint das Management nicht zuzustimmen :)
Robert Gould

5

Dies zeigt einen grundlegenden Unterschied zwischen zwei Denkrichtungen: Diejenigen, die nur Arbeitscode einchecken, mit dem sie zufrieden sind und der es wert ist, gespeichert zu werden, und diejenigen, die ihre Arbeit einchecken, damit die Revisionskontrolle dazu dient, sie gegen Datenverlust zu schützen.

Letzteres würde ich als "diejenigen bezeichnen, die ihr Revisionskontrollsystem gerne als Bandsicherung für arme Leute verwenden", aber das würde mir die Hand geben, in welchem ​​Lager ich mich befinde. :-)

Ich vermute, Sie gehören zum Lager des "guten Codes", und er gehört zum Lager des "Arbeitscodes".

[BEARBEITEN]

Aus den Kommentaren habe ich ja richtig geraten.

Wie gesagt, ich bin bei Ihnen, aber soweit ich das beurteilen kann, ist dies eine Minderheitsmeinung, sowohl hier zum Stackoverflow als auch dort, wo ich arbeite. Daher glaube ich nicht, dass Sie es wirklich in Ihren Entwicklungsstandards als einzige Möglichkeit zum Betrieb verankern können. Nicht, wenn Sie möchten, dass die Standards trotzdem eingehalten werden. Eine Sache, die ein guter Führer weiß, ist, niemals einen Befehl zu erteilen, von dem er weiß, dass er nicht befolgt wird.

Übrigens: Gut Editoren helfen dabei, alte Versionen . In Emacs habe ich beispielsweise alte Versionen und alte Versionen auf 10 gesetzt, wodurch die letzten 10 Speicherungen meiner Dateien beibehalten werden. Sie könnten dies als einen Weg betrachten, um Ihre Argumentation gegen die Menge der Revisionskontrolle als Backup zu unterstützen. Sie werden das Argument jedoch nie gewinnen.


1
Dies wurde auch hier angegeben. In meinen Augen ist das Repository jedoch kein Tool zur Verhinderung von Datenverlust. Es ist ein Revisionskontrollsystem. Da wir TFS verwenden, kann er Regale verwenden, um unvollständigen Code zu sichern. Er könnte auch ein Backup-Tool verwenden oder den Code auf eine gesicherte Freigabe setzen.
John

1
IDE-Sicherungen schützen nicht vor Datenverlust. Unternehmenssicherungssysteme erfüllen nicht immer die Anforderungen des Verlusts von Codedaten. Die Quellcodeverwaltung ist ein System, das beide Anforderungen problemlos erfüllen kann. Es ist relativ einfach, eine Politik zu entwickeln, die den Bedürfnissen beider Lager entspricht, anstatt das eine oder andere auszuschließen.
James Schek

Inwiefern schützen mich meine Emacs-Backups nicht, James? Übrigens: Ich stimme Ihrem letzten Satz voll und ganz zu.
TED

Emacs-Sicherungen dienen zum Zurücksetzen auf den vorherigen Status einer bestimmten Datei. Das Weiterleiten von Sicherungsdateien an einen Dateiserver ist standardmäßig nicht aktiviert und erfordert, dass ich den Systemadministrator um Speicherplatz auf einem Dateiserver bitte. Wenn ich einen FS hätte, würde ich einfach das gesamte Projekt an den FS senden und damit fertig sein. Darüber hinaus ist der vollständige "Status" eines Arbeitsbereichs / Projekts für mich wichtige "Daten". Emacs (und die meisten IDEs) haben keinen Mechanismus, um dies zu speichern.
James Schek

@ ted.dennison: Wenn ich mir die Ergebnisse der beiden besten Antworten anschaue, würde ich sagen, dass Ihre Meinung die Mehrheitsmeinung zu SO ist.
Eddie

4

Nach meiner Erfahrung sind Entwickler-Switches auskommentierter Code.

Manchmal werden parallel neue Back-Ends erstellt, wobei die aktivierenden Schalter in der Quellcodeverwaltung auskommentiert werden.

Einige bizarre Funktionen, die wir einmal auf einem blauen Mond benötigen, die aber kein Kunde jemals benötigen wird, werden häufig auf diese Weise implementiert. Diese Dinge bergen normalerweise ein hohes Risiko für die Umgehung der Sicherheit oder der Datenintegrität, sodass wir nicht möchten, dass sie außerhalb der Entwicklung aktiv sind. Die Anforderung eines Entwicklers, der den Code zuerst auskommentieren würde, scheint der einfachste Weg zu sein, ihn zu erhalten.


4

Ein weiterer Grund für den eingecheckten auskommentierten Code:

Sie ändern vorhandenen Code und haben einen subtilen Fehler gefunden, der leicht zu übersehen ist und möglicherweise auf den ersten Blick sogar richtig aussieht. Kommentieren Sie es aus, setzen Sie das Update an seine Stelle und fügen Sie Kommentare hinzu, was gerade passiert und warum es geändert wurde. Aktivieren Sie diese Option, damit sich Ihre Kommentare zum Fix im Repository befinden.


5
+1: Wenn der auskommentierte Code an Ort und Stelle bleibt - genau dann, wenn er präzise und unauffällig ist - wird verhindert, dass jemand vergisst, dass er dies nicht tut, und den Fehler erneut einführt. INSBESONDERE, wenn das Update das Entfernen von Codezeilen und nicht das Umschreiben von Codezeilen umfasst.
Eddie

Auf jeden Fall beim Entfernen von Codezeilen. Das ist ein guter Punkt.
Donnerstaggeek

1
Ich bin nicht einverstanden. Es ist notwendig, einen Kommentar zu hinterlassen, was vermieden werden soll, jedoch nicht in Codeform, anstatt ihn in Worten zu beschreiben.
thSoft

3

Vielleicht ist die eigentliche Frage hier, ob Entwickler unvollständigen Code einchecken dürfen?

Diese Praxis scheint Ihrem erklärten Ziel, eine kontinuierliche Integration zu implementieren, zu widersprechen.


3

Es hängt davon ab, ob. Wenn es zu Illustrationszwecken dort gelassen wird, vielleicht. Dies kann möglicherweise beim Refactoring hilfreich sein. Ansonsten und generell nein. Das Auskommentieren von unvollendetem Code ist sowohl fehleranfällig als auch zeitlich begrenzt. Besser, er zerlegt den Code in kleinere Teile und checkt sie ein, wenn sie funktionieren.


3

Meiner Ansicht nach: Wenn Entwickler an ihren eigenen Niederlassungen oder in ihrem eigenen Sandbox-Bereich arbeiten, sollten sie in der Lage sein, einzuchecken, was sie wollen. Wenn sie Code in einen gemeinsam genutzten Zweig (einen Feature-Zweig oder einen Team-Zweig oder natürlich MAIN / Trunk) einchecken, sollte der Code so makellos wie möglich sein (kein auskommentierter Code, keine FIXMEs mehr usw.).


3
Es gibt kein einziges bedeutungsvolles Projekt auf der Welt ohne TODOs und FIXMEs oder HACKs im Hauptstamm. Träum weiter.
Robert Gould

1
@ Robert nur weil es viel passiert, heißt das nicht, dass wir nicht versuchen sollten, es zu vermeiden.
Rex M

2
Wow, das ist wirklich ein Traum. Produktionscode ohne FIXMEs? Es muss absolut vollständig sein, ohne Fehler und ohne unerklärliches Verhalten. Oh warte, so ein Code existiert nicht! :)
Eddie

1
Ja, eindeutig ein Traum - ich wollte nur sagen, dass die Messlatte für das Festschreiben in einem gemeinsam genutzten Zweig viel höher ist als für das Festschreiben in Ihrem persönlichen Sandbox- / Work-in-Progress-Zweig.
Jean

@jean: Ja, da sind wir uns einig.
Eddie

2

Ich denke, "Nie" ist eine zu starke Regel. Ich würde dafür stimmen, einen persönlichen Spielraum zu lassen, ob Leute kommentierten Code in das Repository einchecken. Das ultimative Ziel sollte die Codiererproduktivität sein, nicht "ein makelloses Repository".

Um diese Nachlässigkeit auszugleichen, stellen Sie sicher, dass jeder weiß, dass auskommentierter Code ein Ablaufdatum hat. Jeder darf den kommentierten Code löschen, wenn er eine ganze Woche existiert und noch nie aktiv war. (Ersetzen Sie "eine Woche" durch das, was sich für Sie richtig anfühlt.) Auf diese Weise behalten Sie sich das Recht vor, Unordnung zu beseitigen, wenn Sie sie sehen, ohne den persönlichen Stil der Menschen zu direkt zu beeinträchtigen.


2

Ich stimme absolut zu, dass auskommentierter Code nicht in das Repository eingecheckt werden sollte, dafür ist die Quellcodeverwaltung gedacht.

Nach meiner Erfahrung ist ein Programmierer, der auskommentierten Code eincheckt, nicht sicher, was die richtige Lösung ist, und lässt die alternative Lösung glücklicher in der Quelle, in der Hoffnung, dass jemand anderes diese Entscheidung trifft.

Ich finde, dass es den Code kompliziert und das Lesen erschwert.

Ich habe kein Problem damit, halbfertigen Code einzuchecken (damit Sie den Vorteil der Quellcodeverwaltung erhalten), der vom Live-System nicht aufgerufen wird. Mein Problem besteht darin, Abschnitte mit kommentiertem Code ohne Erklärung zu finden. Das Dilemma bestand darin, dass der Code ausgeschlossen wurde.


2

Ich denke, das Einchecken von kommentiertem Code in ein Quellcode-Kontrollsystem sollte mit äußerster Vorsicht erfolgen, insbesondere wenn die zum Kommentieren des Codes verwendeten Sprach-Tags durch Blöcke geschrieben sind, dh:

/* My commented code start here
My commented code line 1
My commented code line 2
*/

Anstatt auf individueller Linienbasis wie:

// My commented code start here
// My commented code line 1
// My commented code line 2

(Du hast die Idee)

Der Grund, warum ich äußerst vorsichtig sein würde, ist, dass Sie je nach Technologie sehr vorsichtig mit dem von Ihnen verwendeten Diff / Merge-Tool sein sollten. Mit einem bestimmten Quellcodeverwaltungssystem und einer bestimmten Sprache kann das Diff / Merge-Tool leicht verwechselt werden. Das Standard-Diff / Merge von ClearCase ist beispielsweise für das Zusammenführen von XML-Dateien notorisch schlecht.

Wenn die Kommentarblockzeilen nicht ordnungsgemäß zusammengeführt werden, wird Ihr Code vorab im System aktiv, wenn dies nicht der Fall sein sollte. Wenn der Code unvollständig ist und den Build bricht, ist dies wahrscheinlich das am wenigsten Übel, da Sie ihn sofort erkennen werden.

Wenn der Code den Build besteht, wird er möglicherweise aktiv, wenn er nicht vorhanden sein sollte. Aus CM-Sicht kann dies ein Alptraumszenario sein. Die Qualitätssicherung testet im Allgemeinen, was vorhanden sein soll. Sie testet nicht auf Code, der nicht vorhanden sein soll, sodass Ihr Code möglicherweise in der Produktion landet, bevor Sie ihn kennen, und wenn erkannt wird, dass der Code vorhanden ist, wenn er vorhanden ist Sollte dies nicht der Fall sein, haben sich die Wartungskosten um ein Vielfaches vervielfacht (da der "Fehler" in der Produktion oder vom Kunden entdeckt wird, der schlechteste Ort oder die schlechteste Zeit aller Zeiten).


Ja, ich stimme zu. Wir haben außerdem ausdrücklich den / * * / -Stil des Kommentierens in allen unseren C # -Programmen verboten.
John

2

Die Idee, der Quellcodeverwaltungsgeschichte zu erlauben, die "alte Art" zu veranschaulichen, etwas zu tun, anstatt es zu kommentieren und das Kommentieren zusammen mit einer Erklärung einzuchecken, ist theoretisch eine gute Idee.

In der realen Welt betrachtet jedoch niemand den Verlauf der Quellcodeverwaltung für die Dateien, an denen er arbeitet, es sei denn, dies ist Teil eines offiziellen Überprüfungsprozesses (nur in regelmäßigen Abständen) oder wenn etwas nicht funktioniert, und der Entwickler kann nicht herausfinden warum.

Selbst dann passiert ein Rückblick auf mehr als 3 Versionen im Grunde nie.

Dies liegt zum Teil daran, dass Versionsverwaltungssysteme diese Art der gelegentlichen Überprüfung nicht einfach machen. Normalerweise müssen Sie eine alte Version auschecken oder sich von einer alten Version unterscheiden. Sie sehen nur zwei Versionen, und es gibt keine genaue Übersicht darüber, was sich geändert hat, sodass Sie auf einen Blick eine Vorstellung davon bekommen, was sich geändert hat.

Teilweise ist es die Kombination der menschlichen Natur und der Bedürfnisse des Teams. Wenn ich etwas reparieren muss und es in ein paar Stunden reparieren kann, werde ich wahrscheinlich keine Stunde damit verbringen, alte Versionen des Codes zu untersuchen, die seit einem Monat nicht mehr "live" waren (was jeder Entwickler überprüft bedeutet oft zurück viele Überarbeitungen), es sei denn, ich weiß zufällig, dass etwas drin ist (z. B. wenn ich mich an eine Diskussion über das Ändern von etwas erinnere, das mit dem zusammenhängt, was ich gerade mache).

Wenn der Code gelöscht und wieder eingecheckt wird, besteht er in jeder Hinsicht (mit Ausnahme des eingeschränkten Zwecks eines vollständigen Rollbacks) nicht mehr. Ja, es dient zu Sicherungszwecken, aber ohne eine Person in der Rolle des Codebibliothekars geht es verloren.

Mein Versionsverwaltungsbaum in meinem aktuellen Projekt ist ungefähr 10 Wochen alt, in einem Team von nur ungefähr 4 Ingenieuren, und es gibt ungefähr 200 festgeschriebene Änderungslisten. Ich weiß, dass mein Team beim Einchecken nicht so gute Arbeit leistet, wie es sollte, sobald etwas Festes und Bereites vorhanden ist. Das macht es ziemlich schwierig, sich darauf zu verlassen, den Codeverlauf für jeden Teil des Codes zu lesen, um jede wichtige Änderung zu erfassen.

Im Moment arbeite ich an einem Projekt im anfänglichen Entwicklungsmodus, der sich stark von einem Projekt im Wartungsmodus unterscheidet. Viele der gleichen Tools werden in beiden Umgebungen verwendet, aber die Anforderungen unterscheiden sich erheblich. Beispielsweise gibt es häufig eine Aufgabe, bei der zwei oder mehr Ingenieure eng zusammenarbeiten müssen, um etwas zu erstellen (z. B. einen Client und einen Server).

Wenn ich den Server schreibe, schreibe ich möglicherweise den Code für die Entwurfsschnittstelle, die der Client verwenden wird, und checke ihn vollständig funktionsunfähig ein, damit der Ingenieur, der den Client schreibt, aktualisieren kann. Dies liegt daran, dass wir die Richtlinie haben, die besagt, dass der einzige Weg, Code von einem Techniker an einen anderen zu senden, das Quellcodeverwaltungssystem ist.

Wenn die Aufgabe lange genug dauert, lohnt es sich, eine Zweigstelle zu erstellen, an der wir beide arbeiten können (obwohl dies gegen die Richtlinien in meiner Organisation verstößt - Ingenieure und einzelne Teamleiter verfügen nicht über die erforderlichen Berechtigungen der Versionsverwaltungsserver). Letztendlich ist es ein Kompromiss, weshalb wir versuchen, nicht zu viele "immer" oder "nie" Richtlinien einzuführen.

Ich würde wahrscheinlich auf eine solche Politik ohne kommentierten Code antworten, indem ich sage, dass sie ein bisschen naiv ist. Vielleicht gut gemeint, aber letztendlich unwahrscheinlich, dass es seinen Zweck erreicht.

Wenn Sie diesen Beitrag sehen, werden Sie den Code, den ich letzte Woche eingecheckt habe, noch einmal durchgehen und den auskommentierten Teil entfernen, der sowohl nie endgültig war (obwohl er funktioniert hat) als auch wahrscheinlich nie wieder gewünscht wird.


Warum stimmen so wenige Menschen diesen Argumenten zu?
Pabrams

2

Ich denke, auskommentierter Code wird als "Verschwendung" angesehen.

Ich gehe davon aus, dass Sie in einer Teamumgebung arbeiten. Wenn Sie alleine arbeiten und Code mit einem 'todo' auskommentieren und darauf zurückkommen, ist das anders. In einer Teamumgebung können Sie jedoch davon ausgehen, dass der auskommentierte Code nach dem Einchecken erhalten bleibt und höchstwahrscheinlich mehr Schmerzen als Zufriedenheit verursacht.

Wenn Sie Peer-Code-Überprüfungen durchführen, wird Ihre Frage möglicherweise beantwortet. Wenn ein anderer Entwickler Ihren Code überprüft und sagt "Warum gibt es diesen auskommentierten Code, der versucht," bla "zu tun?", Hat Ihr Code die Codeüberprüfung nicht bestanden und Sie sollten ihn sowieso nicht einchecken.

Auskommentierter Code wirft nur Fragen bei anderen Entwicklern auf und verschwendet somit Zeit und Energie.

Sie müssen die Frage stellen " warum der Code auskommentiert ist. Einige Vorschläge:

Wenn Sie Code auskommentieren, weil Sie "nicht sicher sind, welche Geschäftsregeln gelten", haben Sie wahrscheinlich ein Problem mit "Scope Creep" - am besten verschmutzen Sie Ihre Codebasis nicht mit Anforderungen, die "schön wären, aber wir haben keine Zeit" zu implementieren "- halten Sie es sauber mit klarem Code und Tests rund um das, was tatsächlich da ist.

Wenn Sie Code auskommentieren, weil Sie "nicht sicher sind, ob dies der beste Weg ist", lassen Sie Ihren Code einer Peer-Review unterziehen! Die Zeiten ändern sich, Sie werden sich den Code ansehen, den Sie heute in 2 Jahren schreiben, und denken, dass er schrecklich ist! Aber Sie können nicht herumgehen und Dinge auskommentieren, von denen Sie wissen, dass sie besser gemacht werden können, aber Sie können gerade keinen Weg finden. Lassen Sie denjenigen, der die Codebasis langfristig verwaltet, entscheiden, ob es einen besseren Weg gibt - lassen Sie den Code einfach schreiben, testen und arbeiten und fahren Sie fort.

Wenn Sie Code auskommentieren, weil "etwas nicht funktioniert", dann FIX IT ! Ein häufiges Szenario sind "fehlerhafte Tests" oder "Aufgaben". . Wenn Sie diese haben, sparen Sie viel Zeit, indem Sie sie entweder reparieren oder einfach loswerden. Wenn sie für einen bestimmten Zeitraum "gebrochen" werden können, können sie höchstwahrscheinlich für immer gebrochen werden.

Alle diese potenziellen Szenarien (und diejenigen, die ich hier nicht erwähnt habe) sind Zeit- und Arbeitsverschwendung. Auskommentierter Code scheint ein kleines Problem zu sein, kann aber ein Indikator für ein größeres Problem in Ihrem Team sein.


1

Repositorys sind Sicherungskopien von Code. Wenn ich an Code arbeite, dieser aber noch nicht vollständig ist, können Sie ihn auskommentieren und am Ende des Tages einchecken. Auf diese Weise habe ich keine Arbeit verloren, wenn meine Festplatte über Nacht ausfällt. Ich kann den Code am Morgen auschecken, ihn auskommentieren und weitermachen.

Der einzige Grund, warum ich es auskommentieren würde, ist, dass ich den Build über Nacht nicht brechen möchte.


Ein Repository ist für mich ein Versionskontrollsystem und kein Backup-Tool.
John

@ John: Viele Entwickler werden es als beides sehen.
Eddie

@ Eddie, werden sie, aber es ist nicht. Für Backups gibt es viele gute Optionen, die Versionskontrolle ist nicht wirklich eine davon, oder?
David sagt, Monica am

@ricebowl: Ich sage nicht, dass ich diesen Entwicklern zustimme! Viele Orte zahlen sich nicht aus, um die Boxen einzelner Entwickler zu sichern. Das Einchecken unvollständiger Arbeiten in eine private Niederlassung vor einem langen Urlaub ist eine anständige Sicherung der bisher geleisteten Arbeit. Entwickler sind pragmatisch.
Eddie

1

Es besteht eindeutig eine Spannung zwischen 1) frühem Einchecken und 2) ständigem Betrieb des Repositorys. Wenn Sie mehr als ein paar Entwickler haben, wird letzterer zunehmend Vorrang haben, da nicht ein Entwickler alle anderen für seinen persönlichen Workflow bescheißen kann. Das heißt , Sie sollten den Wert der ersten Richtlinie nicht unterschätzen. Entwickler verwenden alle Arten von mentalen Zaunpfosten, und individualisierte Workflows sind eine Möglichkeit, mit der großartige Entwickler diese zusätzlichen Xs herausdrücken können. Als Manager ist es Ihre Aufgabe, nicht zu versuchen, all diese Nuancen zu verstehen - an denen Sie scheitern werden, wenn Sie kein Genie sind und alle Ihre Entwickler Idioten sind -, sondern Ihren Entwicklern zu ermöglichen, durch ihre eigenen Entscheidungen das Beste zu sein, was sie können.

Sie erwähnen im Kommentar, dass Sie keine privaten Filialen verwenden. Meine Frage an Sie ist, warum nicht? Okay, ich weiß nichts über TFS, also gibt es vielleicht gute Gründe. Nachdem ich git ein Jahr lang benutzt habe, muss ich sagen, dass ein gutes DVCS diese Spannung völlig löst. Es gibt Fälle, in denen ich das Auskommentieren von Code als nützlich empfinde, wenn ich einen Ersatz baue, aber ich werde den Schlaf verlieren, wenn ich ihn anderen zufüge. In der Lage zu sein, lokal zu verzweigen, bedeutet, dass ich für meinen individuellen Prozess aussagekräftige Commits einhalten kann, ohne mich um nachgeschaltete Entwickler kümmern (oder sie sogar benachrichtigen) zu müssen.


Der Grund, warum wir keine privaten Zweige verwenden, ist, dass wir erst seit kurzem die Quellcodeverwaltung verwenden. Ich bin sehr neu in der Firma und es liegt in meiner Verantwortung, all dies zu klären. Ich bin mit dem Konzept nicht einverstanden, aber im Moment verwenden wir stattdessen Regale in TFS.
John

1

Ich stimme nur dem Refrain zu. Entmutigen Sie dies um jeden Preis. Dies erschwert das Lesen des Codes und lässt die Leute sich fragen, was gut / schlecht an dem Code ist, der derzeit noch nicht einmal Teil der Anwendung ist. Sie können Änderungen immer finden, indem Sie Revisionen vergleichen. Wenn es eine größere Operation gab und der Code massenhaft auskommentiert wurde, hätte der Entwickler dies in den Revisionsnotizen zum Einchecken / Zusammenführen vermerken müssen.

unvollständiger / experimenteller Code sollte sich in einem Zweig befinden, der bis zur Fertigstellung entwickelt werden soll. Der Kopf / Rumpf sollte die Hauptlinie sein, die immer kompiliert wird und was Versand ist. Sobald der experimentelle Zweig abgeschlossen / akzeptiert ist, sollte er in den Kopf / die Hauptzeile eingefügt werden. Es gibt sogar einen IEEE-Standard (IEEE 1042), der dies beschreibt, wenn Sie Supportdokumentation benötigen.


Meistens einverstanden. Aber was tun Sie, wenn Sie experimentellen Code versenden müssen, weil Sie versuchen, die Hauptursache für das Problem einer Site zu identifizieren? Wenn die Entwicklung zu sprechen, stimme ich Ihnen zu , aber als Unterstützung zu sprechen, manchmal Sie müssen experimentellen Code versenden.
Eddie

@Eddie - Ich stimme dem experimentellen Code zu, der von Zeit zu Zeit versendet werden muss. Aber es sollte nicht auskommentiert werden, wenn es meiner Meinung nach nicht mehr benötigt wird.
John

@ Eddie - ich verstehe. Der Zweig ist jedoch eine vollständige Kopie der Head / Release-Version zum Zeitpunkt der Erstellung des Zweigs. Wenn du einen Mod machst, sollte er baubar / versandfähig sein. Wenn Ihnen die Änderungen in der Verzweigung gefallen, führen Sie sie wieder in das Kopfende ein oder halten sie bei Bedarf für das Debuggen / Profiling bereit.
MikeJ

@ John: Stimme absolut zu. Sobald der experimentelle Code nicht mehr experimentell ist, sollte er an Ort und Stelle belassen oder vollständig entfernt werden, je nachdem, was angemessen ist. @ MikeJ: Gute Antwort.
Eddie

1

Ich würde es vorziehen, wenn möglicherweise fehlerhafter, zugänglicher Code, der noch nicht verwendet wird, über denselben Code vollständig nicht verfügbar ist. Da jede Versionskontrollsoftware eine Art "Arbeitskopie" unabhängig vom Trunk zulässt, ist es wirklich eine viel bessere Idee, diese Funktionen stattdessen zu verwenden.

Neuer, nicht funktionierender Code ist im Trunk in Ordnung, da er neu ist. Es bricht wahrscheinlich nichts, was bereits funktioniert. Wenn der Arbeitscode beschädigt wird, sollte er nur in einen Zweig verschoben werden, damit andere Entwickler diesen Zweig (falls erforderlich) überprüfen und feststellen können, was fehlerhaft ist.


1

" Narbengewebe " nenne ich auskommentierten Code. In den Tagen vor der weit verbreiteten Verwendung von Versionskontrollsystemen ließen Code Monkeys auskommentierten Code in der Datei, falls sie die Funktionalität zurücksetzen mussten.

Das einzige Mal, dass es akzeptabel ist, "Narbengewebe" einzuchecken, ist

  1. Wenn Sie eine private Niederlassung haben und
  2. Sie haben keine Zeit, den Code fehlerfrei zu kompilieren und
  3. Sie machen einen langen Urlaub und
  4. Sie vertrauen Ihrem VCS nicht, beispielsweise wenn Sie Visual Source Safe OR verwenden .
    [BEARBEITEN]
  5. Sie haben einen subtilen Fehler, der möglicherweise wieder eingeführt wird, wenn der falsche Code nicht als Erinnerung verwendet wird. (guter Punkt aus anderen Antworten).

Es gibt fast keine Entschuldigung für # 4, da es viele frei verfügbare und robuste VCS-Systeme gibt, wobei Git das beste Beispiel ist .

Andernfalls lassen Sie das VCS einfach Ihr Archiv- und Codeverteiler sein. Wenn ein anderer Entwickler Ihren Code anzeigen möchte, senden Sie ihm die Unterschiede per E-Mail und lassen Sie ihn die gewünschten Inhalte direkt anwenden. In jedem Fall ist es der Zusammenführung egal, warum oder wie die Codierung von zwei Dateien auseinander ging.

Da es sich um Code handelt, kann Narbengewebe sogar ablenkender sein als ein gut geschriebener Kommentar. Aufgrund seiner Natur als Code müssen Sie den Wartungsprogrammierer mentale CPU-Zyklen aufwenden, um herauszufinden, ob das Narbengewebe etwas mit seinen Änderungen zu tun hat. Es spielt keine Rolle, ob die Narbe eine Woche oder 10 Jahre alt ist. Das Belassen von Narbengewebe im Code belastet diejenigen, die die Code-Nachwörter entschlüsseln müssen.

[BEARBEITEN] Ich möchte hinzufügen, dass zwei wichtige Szenarien unterschieden werden müssen:

  • private Entwicklung, entweder Codierung eines persönlichen Projekts oder Einchecken in eine private Niederlassung
  • Wartungsentwicklung, bei der der eingecheckte Code in Produktion gehen soll.

Sag einfach "NEIN" zu Narbengewebe!


-1 Kommentierter Code ist sehr nützlich, um die Absicht einer Funktion zu verstehen. In einer perfekten Welt hinterlässt jeder großartige Kommentare dazu. Aber in der realen Welt fand ich kommentierten Code sehr hilfreich, und Andrew Shelansky wies auf die Gründe hin, warum ich ihn lieber nicht in der Quellcodeverwaltung nachschlagen müsste.
Brandon Moore

0

Ich weiß es nicht - ich kommentiere immer die ursprünglichen Zeilen aus, bevor ich Änderungen vornehme - es hilft mir, sie zurückzusetzen, wenn ich es mir anders überlege. Und ja, ich checke sie ein.

Ich entferne jedoch jeden alten kommentierten Code vom vorherigen Check-in.

Ich weiß, dass ich in den Diff-Protokollen nachsehen kann, was sich geändert hat, aber es ist ein Schmerz - es ist schön, die letzten Änderungen genau dort im Code zu sehen.


1
Vielleicht brauchen Sie bessere Diff-Tools?
jw.

Ein Grund, dies nicht zu tun, wäre, damit Sie sehen können, wer die ursprüngliche Zeile trivial geschrieben hat (z. B. Git-Schuld)
GTD

Huch. Für mich wäre dies analog zu der Aussage "Ich spüle immer, bevor ich auf die Toilette gehe. Aber nicht danach."
Benjaminism

0

Ein guter Kompromiss besteht darin, ein kleines Tool zu schreiben, mit dem Ihre ausgecheckten / geänderten Dateien auf einem Netzwerksicherungslaufwerk gespeichert werden. Auf diese Weise können Sie nach Herzenslust Änderungen vornehmen und Ihre Arbeit sichern, müssen jedoch niemals experimentellen oder unvollendeten Code einchecken.


0

Ich denke, dass das Einchecken von auskommentiertem Code gültig sein sollte, nur weil die neue Änderung Tests bestanden hat, kann es hilfreicher sein, zu sehen, was vorher da war und ob die neue Änderung wirklich eine Verbesserung darstellt.

Wenn ich mehrere Versionen zurückgehen muss, um eine frühere Änderung zu sehen, die jetzt zu einem Leistungseinbruch führt, wäre das sehr ärgerlich.

Manchmal ist der auskommentierte Code eine gute Geschichte, aber geben Sie Daten an, wann der Code auskommentiert wurde. Später kann jemand, der in der Nähe arbeitet, den auskommentierten Code einfach löschen, da sich herausgestellt hat, dass er nicht benötigt wird.

Es wäre auch gut zu wissen, wer diesen Code auskommentiert hat, damit sie gefragt werden können, wenn eine Begründung erforderlich ist.

Ich bevorzuge es, neue Funktionen zu schreiben, sicherzustellen, dass die Komponententests bestanden werden, sie einzuchecken und dann anderen zu erlauben, sie zu verwenden und zu sehen, wie sie funktionieren.


Wenn Sie ein ganzes Team von Mitarbeitern haben, die Code auf diese Weise entwickeln und dann warten, wird er schnell unlesbar. Mit dem richtigen Versionskontrollsystem können Sie leicht Unterschiede zwischen beliebigen Versionen finden.
Eddie

0

Wenn der Entwickler hat einige Codes kommentiert, weil es noch nicht vollständig ist, dann ist die richtige „Quellcodeverwaltung“ Art und Weise damit umgeht für die Entwickler wäre es in einem separaten Zweig seiner eigenen zu halten, bis dieser Code ist bereit zu prüfen , im.

Mit einem DVCS (wie Git, Basar oder Quecksilber) ist dies kinderleicht, da keine Änderungen im zentralen Repository erforderlich sind. Andernfalls könnten Sie vielleicht darüber sprechen, Entwicklern ihre eigenen Zweige auf dem Server zu geben, wenn sie an bestimmten Funktionen arbeiten, die lange genug dauern (dh Tage).

Es ist nichts Falsches daran, auskommentierten Code in einigen Situationen einzuchecken. Es ist nur eine Situation, in der es möglicherweise eine bessere Möglichkeit gibt, dies zu tun, sodass der Entwickler Änderungen an seiner Quelle verfolgen kann , obwohl dies noch nicht geschehen ist im Haupt-Repository eingecheckt.


0

Es ist klar, dass der Entwickler, der auskommentierten Code eincheckt, in einem separaten Zweig arbeiten und Änderungen aus dem Trunk-Zweig nach Bedarf zusammenführen sollte.

Es ist Sache des VCS-Systems, den Entwickler bei diesem Workflow zu unterstützen (Git ist ein ausgezeichnetes VCS-System, das sehr gut damit funktioniert).

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.