Ungeschriebene Regeln zum Umschreiben des Codes eines anderen Teammitglieds [geschlossen]

40

Wir üben kollektiven Code-Besitz. Meines Erachtens bedeutet dies, dass jeder Entwickler eine beliebige Codezeile ändern kann, um Funktionen hinzuzufügen, Änderungen vorzunehmen, Fehler zu beheben oder Designs zu verbessern.

Aber wie wäre es mit einem kompletten Umschreiben des Codes eines Entwicklers, der noch im Team ist? Soll ich ihn zuerst fragen? Was ist die beste Praxis?

sglahn
quelle
5
Wenn der Code gelöscht werden muss, kann ich keinen Schaden feststellen - vorausgesetzt, Sie verwenden die Quellcodeverwaltung. Die anderen Antworten auf diese Frage beschreiben die Ethik des Löschens des Codes eines anderen ziemlich gut.
Anonym
9
Ich glaube nicht, dass dies in einer der [ausgezeichneten] Antworten ausdrücklich erwähnt wird: Auch wenn vorhandener Code eine Umschreibung verdient , ist es sehr wahrscheinlich , dass es Zeitverschwendung ist, [Geld] umzuschreiben, wenn er jetzt funktioniert . Ich habe gelernt, dass quick 'n dirty in vielen Szenarien der richtige Weg ist. Sie werden dafür bezahlt, Code zu schreiben, also sollten Sie so effizient wie möglich sein. Sie benötigen kein gut gestaltetes Framework für etwas, das nur einige Male ausgeführt wird. Sie möchten nicht eine Woche brauchen, um etwas zu tun, das mit schlechten Entwurfspraktiken an einem Tag hätte erledigt werden können. Viele Manager bevorzugen diesen Ansatz.
taz
9
@taz - Dies ist die Grundlage des Big Ball of Mud- Musters ( laputan.org/mud ).
Matthew Flynn
@MatthewFlynn - Großartiger Artikel. Die Phrase "Big Ball of Mud" erschien so oft, dass es sich wie ein Deja-Vu-Erlebnis von Allan Iversons "Practice" anfühlte ( youtube.com/watch?v=eGDBR2L5kzI ). ;-)
Happy Green Kid Nickerchen
3
Benötigt mehr Kontext. Warum ändern Sie den Code, welchen Umfang hat die Änderung? Stunden, Tage, Wochen, Monate der Arbeit. Wer bezahlt das Wechselgeld und wird es wirklich gebraucht? Wer billigt die Notwendigkeit für die Änderung. Was ist Ihr Prozess und wie ist es so schlimm ausgefallen, dass Sie in dieses Chaos geraten sind?
Mattnz

Antworten:

62

Ich denke, gute Kommunikation ist immer die beste Praxis. Sprechen Sie mit dem Entwickler und sehen Sie, ob es einen Grund dafür gibt, warum die Codierung so ist, wie sie ist. Es kann sein, dass sie vorhatten, zurück zu kommen und es für Ewigkeiten umzugestalten. Es kann sein, dass sie es aus einem sehr guten Grund so gemacht haben, oder dass Sie beide etwas aus dem Gespräch lernen können.

Das Eingehen und Umschreiben ohne vorherige Mitteilung ist ein Rezept für bösen Willen.

Matthew Flynn
quelle
1
Ja, ich habe aus Erfahrung gelernt, dass einige Entwickler sehr aufgeregt sein können, wenn Sie sogar Fehler in ihrem Code beheben, ohne zu fragen. Natürlich war dies ein Projekt ohne Nachverfolgung von Problemen oder Aufgabenplanung, und ich bin erstaunt, dass es jemals ausgeliefert wurde.
flauschige
+1 für "mit dem Entwickler sprechen" - wir haben einen Fehler (zumindest einen, wahrscheinlich noch mehr), den der Kunde jetzt erwartet ... Und der so weit begraben ist, dass ich der einzige war, der vage wusste, warum er übrig geblieben ist allein.
Izkata
3
Ich bin grundsätzlich nicht mit "guter Kommunikation" einverstanden, aber ich denke, diese Antwort ist ein wenig banal. Nach Abzug aller lästigen Fragen zu den Umständen, unter denen diese Frage gestellt wurde, sollte es eigentlich keine Rolle spielen, ob ein Entwickler die Frage "Soll ich Ihren Code umschreiben?" Mit "Ja" oder "Nein" beantwortet. , weil das nicht unbedingt die beste Antwort für das Team oder das Produkt sein wird. Natürlich sollte man versuchen, alles über die ursprünglichen Annahmen und Entscheidungen herauszufinden, aber woher wissen wir, dass das OP das nicht bereits getan hat?
Aaronaught
2
@Aaronaught - Die Frage, ob der ursprüngliche Entwickler gefragt werden soll, impliziert, dass das OP noch nicht mit dem ursprünglichen Entwickler gesprochen hat und daher nicht versucht hat, alles zu entdecken, was er kann. Ich hoffe, die Antwort ist das Gegenteil von banal - es ist grundlegend.
Matthew Flynn
1
Wenn Sie tatsächlich kollektiven Code-Besitz praktizieren, haben Sie das Recht, Code zu ändern, umzuschreiben oder zu löschen, wann immer Sie dies für angebracht halten. Dies gilt insbesondere dann, wenn Sie eine Paarprogrammierung durchführen. Nun, nachdem wir gesagt haben, dass es vor einer größeren Änderung (wie einem Umschreiben) des Codes, den eine bestimmte Person geschrieben hat, ratsam ist, mit ihnen darüber zu sprechen. In den meisten Fällen, die ich gesehen habe (auch mit meinem eigenen Code), lautete die Antwort: "Oh ja, sorry! Dieser Code ist eine Katastrophe. Ich habe es einfach nicht richtig gemacht. Hier sind einige Ideen, wie man ihn verbessern kann Bitte lauf damit! "
Jeff Grigg
35

Die Prämisse dieser Frage wirft für mich eine Reihe von Bedenken auf, die meines Erachtens mit keiner der vorhandenen Antworten angemessen angegangen werden sollen. Lassen Sie mich hier einige Nachfragen stellen:

  1. Sind Sie sich absolut sicher, dass Sie über das Umschreiben und nicht über das Refactoring sprechen? Per Definition sind Änderungen am Codestil oder an der Codestruktur, die zu einer verbesserten (oder einfach anderen) Implementierung führen, ohne dass das externe Verhalten geändert wird, ein Refaktor und kein Umschreiben. Das Aufteilen einer monolithischen 500-Zeilen-Routine in einen Satz von 50 Subroutinen kann das Schreiben einer ganzen Menge neuen Codes erfordern, ist jedoch kein Umschreiben. Der Begriff " Umschreiben" bedeutet, ein ganzes Produkt oder eine ganze Funktion wegzuwerfen und von vorne zu beginnen. es ist nicht etwas, das man leicht nimmt.

  2. Wenn das Verhalten des ursprünglichen Codes so falsch ist oder die Implementierung so fehlerhaft ist, dass ein vollständiges Umschreiben erforderlich ist, warum wurde es dann nicht vom Prozess Ihres Teams erfasst und im richtigen Kontext (dh eher technisch als sozial) angesprochen? Schlechter oder fragwürdiger Code sollte einem gesunden Team schnell durch Tests, Code-Reviews, Design-Reviews usw. aufgedeckt werden. Haben Sie diese?

  3. Ist sich der Manager / Techniker des Problems bewusst, und wenn nicht, warum nicht? Unabhängig davon, welche Art von Prozess Sie haben, liegt die Codequalität normalerweise in der Verantwortung des Entwicklungsleiters. Er oder sie ist die erste Person, die Sie fragen sollten - offensichtlich nicht im Kontext von "so und so geschriebener Mistcode", sondern einfach "Ich denke, ich sehe hier ein großes Problem. Können wir über ein Umschreiben sprechen?" Wenn es diese Art von Diskussion nicht rechtfertigt, dann rechtfertigt es vielleicht auch kein Umschreiben?

  4. Wenn die Größe und der Umfang des anstößigen Codes groß genug sind, um eine ernsthafte Diskussion über ein Umschreiben zu rechtfertigen, warum gehört er dann ausschließlich einem Entwickler? Die meisten, wenn nicht sogar alle Male, in denen ich Code gesehen und "umgeschrieben" habe, wurde er von einem Dutzend verschiedener Leute mit Füßen getreten, und die Schlechtigkeit ist eine direkte Folge der Anhäufung von Stilinkonsistenzen, falschen oder geänderten Annahmen und guten alten Hacks. Code wächst Dornen im Laufe der Zeit gerade wegen seiner gemeinsamen Eigentümerschaft.

    Mein Punkt hier ist, dass es seltsam ist, dass eine Person in einer Umgebung, in der angeblich kollektives Eigentum praktiziert wird, eine so große Menge an Code besitzt. Haben andere Angst, den Code dieses Entwicklers zu berühren? Haben sie Angst, das Thema anzusprechen? Möglicherweise liegt ein Problem mit Ihrer Gruppendynamik oder speziell mit diesem Entwickler vor. Wenn ja, ignorieren Sie es nicht. Oder alternativ vielleicht ist es Ihr erstes Mal an diesem Projekt arbeitet, und wenn ja, warum sind Sie denken über eine Rewrite so früh im Spiel? Irgendetwas an der Situation scheint für mich nicht zu stimmen.

  5. Die Frage heißt es im ersten Absatz any developer can change any line of code to add functionality, to refactor, fix bugs or improve designs. Wird ein Umschreiben diese Dinge nicht tun? Oder macht es etwas extra - und wenn ja, was? Welche Gründe sprechen grundsätzlich für ein Umschreiben, und wie sicher sind Sie, dass sie dem Produkt oder dem Team zugute kommen? Sie brauchen mir nicht zu antworten, aber Sie sollten einige objektive Punkte ansprechen, wenn Sie sich dazu entschließen, diese mit dem Team zu besprechen.

Ich bin der festen Überzeugung, dass diese Frage einen enormen Zusammenhang mit sich bringt und nicht ohne ein sehr klares Verständnis dieses Zusammenhangs beantwortet werden sollte . Die "richtige" Antwort hängt vollständig von Ihrem Team, Ihrem Produkt, Ihrer Organisation, Ihrer Persönlichkeit, Ihrem Prozess, dem Umfang des ursprünglichen Codes, dem Umfang der Änderungen usw. ab. Dies ist, IMO, ein Thema, das Sie unbedingt mit Ihrem Team besprechen müssen und nicht auf einer Online-Q & A-Site.

Aaronaught
quelle
3
+1 Die einzig richtige Antwort in dieser Diskussion.
Mattnz
Nach meiner Erfahrung in XP-Teams mit kollektivem Code-Besitz (und Paarbildung) müssen große Änderungen am Design oder am "Umschreiben" von Teilen des Systems in der Regel mit den meisten Teammitgliedern (allen Beteiligten) besprochen werden. Mit der kritischen Kernfunktionalität ist das vorhandene Design das Beste, was das Team zu diesem Zeitpunkt tun konnte. Wenn es nicht einfach zu ändern ist, ist es hilfreich, sich mit allen Vorstellungen zu befassen, was sie tun sollten, und verschiedene Möglichkeiten zu finden, um es zu verbessern. Wenn Sie keinen Konsens erzielen können, probieren Sie einige "Spitzen" oder Experimente aus, um Informationen zu sammeln.
Jeff Grigg
11

Warum bearbeiten Sie den Code?

Gibt es Fehler oder liegt ein grundlegenderer Designfehler vor?

Im ersten Fall würde ich mir Gedanken über ein Umschreiben machen, um kleinere Fehler im Code zu beheben.

Im letzteren Fall würde ich, obwohl ich ein Heads-up erwarten würde, dass "mein" Code möglicherweise umgeschrieben wird, vollkommen glücklich sein, dass es passiert.

Das ist der Punkt des kollektiven Besitzes von Code - der Code, den Sie schreiben, muss geändert oder sogar ersetzt werden, wenn etwas Besseres eintritt.

ChrisF
quelle
3
Dies ist die einzige Antwort, der ich bisher zustimmen kann. Wenn etwas umgeschrieben werden muss, schreibe ich es um. Ich sehe nicht einmal nach, wer der ursprüngliche Autor war. warum sollte ich? Angenommen, es gibt Tests (es gibt Tests, oder?) Und angenommen, dass der Zweck einigermaßen klar ist oder durch Kommentare erklärt wird (wenn nicht, dann muss es definitiv gehen), dann werde ich ziemlich schnell wissen, ob ich etwas kaputt gemacht habe. Natürlich spreche ich über das Umschreiben einiger Klassen, nicht eines gesamten Frameworks, aber wenn das Umschreiben so umfangreich ist, handelt es sich eher um ein Planungs- / Projektplanungsproblem als um ein Problem der gemeinsamen Eigentümerschaft.
Aaronaught
6

Wenn Sie alle zustimmen, dass Sie alle für den Code verantwortlich sind, ist es im Allgemeinen in Ordnung, jeden Code neu zu schreiben, wenn dies eine Verbesserung darstellt. Besprechen Sie dies zunächst mit dem anderen Entwickler. Es kann triftige Gründe dafür geben, dass es auf eine bestimmte Art und Weise geschrieben ist. Auf persönlicher Ebene werden viele Entwickler emotional in das investiert, was sie produzieren, und wie andere gesagt haben, möchten Sie keinen bösen Willen.

Insbesondere hängt es etwas von der Teamdynamik ab. Ein leitender Entwickler, der im Begriff ist, den Code eines Junior-Entwicklers neu zu schreiben, sollte wahrscheinlich eine Codeüberprüfung (auf meiner Website) mit ihm durchführen, bevor er ihn einfach neu schreibt. So kann der Nachwuchsentwickler aus der Situation lernen.

Matt S
quelle
5

Es spielt keine Rolle, ob der ursprüngliche Entwickler im Team ist oder nicht oder ob Sie der ursprüngliche Entwickler sind. Vollständiges Umschreiben von jedem gemeinsamen Code sollte von Ihrem Team ausgeführt werden, aus den folgenden Gründen:

  • Es dauert sehr lange. Wenn jemand anderes an einer ähnlichen Änderung arbeitet, möchten Sie seine Zeit nicht verschwenden.
  • Andere Menschen haben eine andere Perspektive. Selbst wenn Sie 20 Jahre lang programmiert haben, weiß möglicherweise jemand anderes etwas über Interaktionen mit Code, die Sie selten anfassen.
  • Andere Entwickler sind die "Kunden" des Quellcodes. Der Quellcode ist für andere Entwickler zum Lesen geschrieben. Möglicherweise haben sie Architekturanforderungen, Eingaben zum Stil oder Feature-Anforderungen, die sie in diesem Code gewünscht haben, aber keine Zeit hatten. Sie möchten einen Refactor nicht nur fertigstellen, um herauszufinden, dass ein anderer Entwickler ihn auf eine andere Weise refactored muss.
Karl Bielefeldt
quelle
4

Wie Matthew Flynn sagte, ist es notwendig, zuerst mit dem Entwickler zu sprechen. Der ursprüngliche Entwickler kann wichtige Dinge über die Funktionalität erzählen und erklären, warum diese oder jene Lösung gegeben wurde.

Erstellen Sie jedoch vor dem Umgestalten oder Neuschreiben des Codes entweder eine Sicherungskopie oder eine Verzweigung, die diesen Code enthält. Wenn der alte Code einwandfrei funktioniert, besteht die Möglichkeit, dass er wiederhergestellt wird.

Wenn Sie ein Quellcodeverwaltungssystem haben (von dem ich annehme, dass Sie es haben), überarbeiten Sie nach Möglichkeit den gesamten Code und checken Sie das erst dann ein, wenn Sie sicher sind, dass es funktioniert.

Löschen Sie den alten Code nicht, bevor Sie sicher sind, dass der neue Code einwandfrei funktioniert. Aber den alten Code für immer dort zu lassen, ist auch keine gute Sache. Ich schlage vor, Sie löschen den Code einige Zeit später, wie in einem Monat, nachdem er den Test bestanden hat.

superM
quelle
2
"Ich schlage vor, Sie löschen den Code einige Zeit später" - wo soll er in der Zwischenzeit bleiben? In einem kommentierten Block? Dafür dient die Quellcodeverwaltung, um eine Sicherungskopie des gesamten geänderten / gelöschten Codes zum einfachen Abrufen zu erstellen und gleichzeitig den aktuellen Quellcode sauber zu halten.
18.
@ dj18, Ich lasse den Code normalerweise eine Weile kommentieren, um ihn deutlicher zu machen, und damit jeder, der sich mit dem Code befasst, sehen kann, dass er sofort geändert wurde. Außerdem ist es einfacher, auf diese Weise
nachzuschlagen
1
Dies ist eine weitere Funktion eines ordnungsgemäßen Versionskontrollsystems: Sie können anzeigen, wann Änderungen eingecheckt wurden, Versionen vergleichen, um genau zu sehen, was sich von einem Einchecken zum nächsten geändert hat, und Kommentare mit Einchecken verknüpfen, um zu erklären, warum eine Änderung vorgenommen wurde. Wenn es für andere so wichtig ist, sofort zu wissen, dass ein Teil des Codes geändert wurde, senden Sie möglicherweise eine E-Mail-Benachrichtigung, anstatt darauf zu warten, dass die anderen Entwickler Ihre Kommentare zufällig beantworten.
dj18
2
Das Wissen, dass diese Antwort vom ursprünglichen Entwickler angefordert werden sollte, sollte im Code oder zumindest in den zugehörigen Kommentaren oder Dokumentationen enthalten sein. Wenn dies wichtige Informationen sind, sollten sie nicht im Gehirn eines anderen Menschen gespeichert werden, und die Entwicklungspolitik sollte dies nicht fördern. Warum nicht auch den alten Code löschen? Sie können es zurückbekommen, wenn Sie es wirklich brauchen. das ist , was zur Versionskontrolle ist für .
Aaronaught
1
@Aaronaught: Ich denke , was SuperM bedeutete zu sagen war die „hier Drachen“ Art oder „lessons learned“. Während Fallstricke für einen erfahrenen Programmierer ziemlich offensichtlich sein sollten, sind subtile Entscheidungen weniger offensichtlich und möglicherweise nicht gut dokumentiert. (Ich bin damit einverstanden, dass dies schlechte Anzeichen sind, die angegangen werden müssen.)
Rwong
2

Was ist der Umfang davon?

  • Wenn Sie ein paar Zeilen überarbeiten, um effizienter zu sein, tun Sie es einfach. Vielleicht fragen Sie, ob die Gefahr besteht, dass Sie subtiles Verhalten löschen. Melden Sie die Änderung während des Scrums oder per E-Mail, wenn sie nicht wirklich trivial ist (Behebung eines Tippfehlers).

  • Wenn Sie eine Klasse mit angemessener Größe überarbeiten, sollten Sie wahrscheinlich fragen, ob Sie das Design / Verhalten verstehen. Informieren Sie die Mitarbeiter im Voraus, damit jeder, der in demselben Bereich tätig ist, auf Sie aufmerksam wird und sich mit Ihnen abstimmt.

  • Wenn Sie ein größeres System überarbeiten, sollten Sie auf jeden Fall mit Ihrem Team zusammenarbeiten, um es auf die Änderungen aufmerksam zu machen und das Design zu planen.

Telastyn
quelle
1

Wenn Ihre Originalautoren da sind, kommunizieren Sie mit ihnen. Nicht NUR für Etikette, sondern für zusätzliche Informationen, falls es Fälle oder Umstände gibt, die Sie nicht kennen. Manchmal erzählen sie dir etwas Wertvolles.

Wir haben eine miserable Code-Kontrolle. Ich habe derzeit eine Menge Dinge, die überprüft und gewartet werden müssen, und ich habe nicht einmal jemanden, mit dem ich Code überprüfen kann. Die vorherigen Autoren (abgesehen von moi) haben sich nicht die Mühe gemacht, Code zu kommentieren. Und sie sind aus der Firma verschwunden. Es gibt niemanden, der nach dem Code fragt.

Wenn ich neu schreibe, kommentiere ich aus, mit Kommentaren, die ich auskommentiert habe, sowie Datum und Name / Initialen und warum es auskommentiert wurde. Ich kommentiere neuen Code, mit Namen oder Initialen, Datum, Grund wurde hinzugefügt, etc.

Zusätzliche Kommentare werden am Paketkopf (normalerweise äh) abgegeben und geben an, welche Funktionen / procs / SQL / etc. wurden mit Datum geändert. Auf diese Weise können geänderte Abschnitte einfach nachgeschlagen werden, und diese Abschnitte verfügen über eine vollständige Dokumentation.

Kommentare sind billig. Daten sind ein Indikator dafür, was sich geändert hat, und nach x-number of (Tage / Revisionen / Neueinstellungen / Pensionierungen) kann der Code von alten Kommentaren befreit werden und der verbleibende Code ist die neue Grundlinie.

Marc
quelle
1

Nach meiner Beobachtung lautet die allgemeine Praxis: Löschen Sie niemals den Code. Einfach auskommentieren und behalten.

Meine Praxis ist es, es beim Ersetzen zu kommentieren. (Hauptsächlich als Referenz.) Löschen Sie sie dann beim endgültigen Festschreiben der Arbeitsänderung. (Dies erfordert eine Versionskontrolle und ein Verständnis dafür, wie Änderungen rückgängig gemacht werden können.)

Wenn ich alten kommentierten Code finde, versuche ich, ihn in einem separaten Commit mit entsprechenden Kommentaren zu löschen. Dies erleichtert das Zurücksetzen oder Überprüfen der Änderung, falls dies erforderlich sein sollte.

Bei allen Änderungen sollten Sie in der Lage sein, anhand des Revisionsverlaufs die Entwickler zu ermitteln, die den Code erstellt haben. (Hier hilft der kommentierte Versionsverlauf.) Wenden Sie sich nach Möglichkeit an diese, um festzustellen, warum der Code so ist, wie er ist. Bei vielen Projekten tritt keine Bereinigungszeit auf und die Dinge bleiben zurück. Überprüfen Sie den Bug-Tracker, um festzustellen, ob Aufzeichnungen über die erforderliche Bereinigung vorliegen. Manchmal müssen Änderungen ein oder zwei Releases später bereinigt werden.

Wenn Sie Code ändern, sollte es einen Grund geben, warum Sie mit diesem Code arbeiten. Wenden Sie sich an den ursprünglichen Entwickler, um herauszufinden, warum der Code so ist, wie er ist. Wenn es einen berechtigten Grund gibt, das Problem nicht zu beheben, fügen Sie einen Kommentar hinzu, in dem erläutert wird, warum das Problem nicht behoben wurde oder warum es nicht geändert werden sollte. Dies spart dem nächsten Entwickler etwas Zeit.

Tags wie FixMe, ToDo, Bug und Hack können verwendet werden, um Code anzugeben, der später geändert werden könnte. (Es ist akzeptabel, Einschränkungen als Fehler zu kennzeichnen und nicht zu beheben, wenn sie unter den erforderlichen Bedingungen nicht ausgelöst werden.) Es kann ein Fehler sein, wenn ein Home Accounting-Programm mit 20 Millionen Dollar überläuft, aber ich würde nicht viel Zeit damit verschwenden, Fehler zu beheben es.

Änderungen an der Codeüberprüfung sollten vom ursprünglichen Entwickler vorgenommen werden, wenn eine Änderung des Codes angezeigt ist.

BillThor
quelle
2
Ich habe dies fast abgelehnt, bis ich "Dann lösche es beim letzten Commit" sah.
Joshua Drake
1

Es hängt wahrscheinlich davon ab, warum das Umschreiben notwendig ist. Wenn es Probleme mit dem Geschriebenen gibt und es schon immer Probleme damit gab, dann ist es angebracht, darüber zu sprechen, um zu minimieren, wie oft Code in der Zukunft repariert werden muss.

Mein Vorschlag in diesem Fall ist, beim Korrigieren des Codes zu koppeln. Auf diese Weise liefert es ein gutes Beispiel für die Zwischenzustände und (hoffentlich) einen Zusammenhang, warum der umgeschriebene Code besser ist. Versuchen Sie auch (wenn auch nur als persönliche Übung), den Code zu überarbeiten, um ihn zu verbessern, ohne ihn komplett neu zu schreiben. Es wird schwieriger, aber es ist gut für dich.

Andererseits gibt es einige andere Zeiten, in denen ein Umschreiben erforderlich ist:

  • Das Team hat viel gelernt, seit der Code geschrieben wurde, und die Entwickler, die ihn geschrieben haben, haben ihn jetzt anders geschrieben, auch ohne Ihre Eingabe.

  • Eine neue Feature-Anforderung ändert die Situation so, dass ein gezieltes Mini-Rewrite angezeigt ist.

In diesen Fällen würde ich mich wahrscheinlich nicht um ein Gespräch kümmern.

Wenn ich darüber nachdenke, scheint es mir, dass je länger der Code vorhanden ist, desto unwahrscheinlicher ist eine Unterhaltung.

Sean Reilly
quelle
1

Ich denke, @aaronaught hat einige gute Punkte gemacht, was wirklich zu der Antwort führt, die ich geben wollte, nämlich dass es wirklich davon abhängt, wer die Änderung vornimmt (und warum) und wer den Code geschrieben hat.

Mein persönlicher Erfahrungscode wird normalerweise geändert, weil er entweder nicht wie beabsichtigt funktioniert oder Sie einfach erweitern müssen, was er tatsächlich tut.

In einer Team-Entwicklungsumgebung sollte es nicht erforderlich sein (und möglicherweise nicht möglich sein), mit dem Original-Codierer zu sprechen. Der Code sollte alle Angaben enthalten.

Das führt dann zu der Frage, die den größten Teil meiner Zeit in Anspruch nimmt, was der ursprüngliche Programmierer beabsichtigte, und es ist diese Frage, die am häufigsten zum Löschen von Code führt, und warum wir alles kommentieren sollten und wo unerfahrene Junior-Programmierer am meisten sind falle oft faul.

Jeder Programmierer, der den Code einer anderen Person ändert (Refactoring), sollte aus Höflichkeit und Erfahrung den gleichen Codierungsstil wie den bereits vorhandenen Code kopieren und zunächst herausfinden, wie der ursprüngliche Code funktioniert und was er versucht hat zu erreichen und tatsächlich zu erreichen. Oft identifiziert dies an sich Fehler, aber sicherlich zwingt es die Leute, den Schmerz zu ertragen, den die nächste Person haben wird, wenn sie Ihren Code betrachtet.

In meinem Team kann jeder etwas löschen, umgestalten oder umschreiben, und ich betrachte "Besitz" als eine Praxis, die Faulheit erzeugt, als ob eine Person über Änderungen informiert werden würde, warum sie den Code lesbar machen müsste.

Kurz gesagt, nein, Sie sollten nicht den ursprünglichen Autor des Codes fragen müssen. Wenn Sie sich den Code ansehen, ist dies ein Zeichen dafür, dass sein Code entweder nicht lesbar genug ist oder dass Sie ihn verbessern müssen deine Fähigkeiten. Ich finde es jedoch in guter Form, den ursprünglichen Code an Ort und Stelle zu lassen, kommentiert, bis Sie absolut sicher sind, dass Sie beim Umschreiben nicht versehentlich die erforderliche Funktionalität entfernt haben. Niemand ist perfekt.

sibaz
quelle
-2

Oft wird Code aus einem bestimmten Grund auf eine bestimmte Weise geschrieben. Die Mitteilung der Änderung an den Autor funktioniert immer am besten.

Chuck Conway
quelle