it-swarm.com.de

Wie wichtig ist es, den Code eines anderen zu bereinigen, wenn die Frist knapp ist?

(Ich spreche von HTML/CSS-Code (keine Programmiersprachen), aber ich denke, wir haben auch das gleiche Problem wie bei Programmierern.)

Ich bin der leitende Front-End-Designer in einem Team und muss die Ergebnisse meiner Junioren oft innerhalb enger Fristen überarbeiten.

Ich habe zwei Probleme:

  1. Ihr Codierungsstil ist ein bisschen chaotisch.
  2. Die Ästhetik ist nicht gut.

Ich finde, ihr Codierungsstil ist eine gemischte Tasche ohne angemessene Konvention/Standard. Ich bin hin und her gerissen zwischen dem Aufräumen des Codes oder dem Umgang mit ihrem Code (sogar dem Kopieren, wie sie Dinge tun).

Ich finde es frustrierend, ihrem Codierungsstil zu folgen, da ich das Gefühl habe, schlechte Gewohnheiten zu lernen. Aber das ist der schnellste Weg, um die Frist einzuhalten.

Was ist für diejenigen mit viel mehr Erfahrung effektiver? Soll ich die Bereinigung für später aufheben? Oder aufräumen, während ich die Änderungen vornehme?

(Ich möchte zwar nicht arrogant klingen, aber das ist die Realität. Es wird mehr Jahre dauern, bis sie besseren Code schreiben. Ich weiß, ich habe unordentlichen Code geschrieben, als ich angefangen habe.)

38
anon

Ich glaube, Sie sehen das Problem falsch - Sie verpassen eine großartige Gelegenheit, den Junioren beizubringen, wie man besseren Code schreibt.

Wenn Sie ihren Code gewöhnlich neu schreiben, können Sie Ihren Junioren den Eindruck vermitteln, dass Sie ihre Arbeit nicht schätzen, was ihre Moral senkt und ihnen beim nächsten Mal nicht hilft, besser zu codieren.

Ich glaube, ein besserer Ansatz besteht darin, dem Entwicklungsprozess Ihres Teams eine Aufgabe zur Codeüberprüfung hinzuzufügen. Es muss sich nicht um jeden festgeschriebenen Code handeln, und es muss nicht (ich würde argumentieren, dass dies nicht der Fall sein sollte) nur von Ihnen ausgeführt werden - wann immer ein Mitglied Ihres Teams eine ausreichend große Aufgabe erledigt, die es sollte Koppeln Sie sich mit einem (oder mehreren) seiner Teamkollegen, erklären Sie ihnen den Code und erhalten Sie konstruktive Meinungen und Kritik zu seinem Design, seinem Codierungsstil, möglichen Fehlern und Sicherheitsproblemen usw.

Wenn Sie der Teamkollege sind, der den Code überprüft, werden sie viel mehr aus Ihrem Fachwissen lernen, als wenn Sie einfach ihren Code neu schreiben (sie haben die Möglichkeit, den Grund zu hören, der Code sollte geändert werden). und könnte weniger Anstoß nehmen.

Wenn Sie ihnen die Möglichkeit geben, auch Codeüberprüfungen durchzuführen, werden sie ihre Fähigkeiten weiter verbessern - zu sehen, wie andere Menschen Code schreiben und warum - und ihr Selbstwertgefühl steigern.

Sie werden auch viel lernen, wenn Sie ihnen die Möglichkeit geben, Ihren Code zu überprüfen. Vielleicht lernst du auch etwas - also mach es nicht nur zur Show!

79
Uri Agassi

Ich habe das schon einmal gesagt und werde es noch einmal sagen "Arbeitscode ist wertvoller als hübscher Code".

Wenn Sie den Code ändern, ist die Wahrscheinlichkeit hoch, dass Sie sein Verhalten ändern. Wenn es sich um getesteten Code handelt, haben Sie gerade den gesamten Testaufwand ungültig gemacht und müssen die Tests wiederholen.

Ermutigen Sie Ihre Junioren auf jeden Fall, sauberen, verständlichen Code zu schreiben. Wenn Sie jedoch alles, was sie schreiben, neu schreiben, verschwenden Sie das Geld Ihres Arbeitgebers mehrmals. Sie müssen für Ihre Junioren bezahlen, dann dafür, dass Sie das tun, wofür sie Ihre Junioren bereits bezahlt haben, und dann noch einmal für Sie, um den Job zu erledigen, für den sie Sie tatsächlich eingestellt haben.

29
James Anderson
  • Die kurze Antwort lautet: nein. In schwierigen Zeiten muss man manchmal nur den Kopf senken und die ästhetische Kugel nehmen. ;)

  • Eine pragmatischere Antwort ist die Zeitbox. Planen Sie eine Stunde ein, um einen spezifischen Aspekt des Codes zu durchlaufen und zu bereinigen. Dann checke es ein und mache echte Arbeit. Aber seien Sie ehrlich zu sich selbst, wenn Sie es einschränken.

  • Manchmal jedoch beschleunigt ein bisschen Aufräumen die Arbeit. Selbst einige schnelle Änderungen am Typ zum Suchen und Ersetzen machen alles viel zugänglicher.

  • Seien Sie vorsichtig bei Stilkriegen. Insbesondere in einer Situation mit engen Fristen sollten Sie besser warten, bis Sie Zeit haben, um wirklich herauszufinden, wie Sie diese ansprechen möchten, wenn Sie einige Stileinstellungen rückgängig machen möchten, die der andere Programmierer nur noch einmal macht Stilfragen kooperativ. (Was bedeutet, dass einige geben und nehmen.)

Aber die Antwort enthält einen Urteilswert. Ich würde sagen "mäßig" wichtig. Sauberer Code kann die Arbeit wirklich beschleunigen, und die Codequalität ist schließlich Teil des Ergebnisses. Ich glaube nicht, dass ich Code (auch meinen eigenen) berühren kann, ohne etwas Zeit für die Bereinigung aufzuwenden. Aber stellen Sie sicher, dass die Auseinandersetzung mit Stil und Format und Stilkriegen nicht mehr wichtig wird, als den Code in die Produktion zu bringen.

16
Rob

Wenn ich Code repariere und eine Frist habe, verwende ich normalerweise zwei Regeln:

Der Code ist schrecklich, aber es ist möglich, ein Problem in angemessener Zeit zu finden und zu beheben

Ich behebe ein Problem und lass den Rest intakt.

Der Code ist so chaotisch, dass es dort wirklich schwierig ist, ein Problem zu finden. Etwas zu reparieren verursacht sofort etwas anderes. Es wäre wahrscheinlich schneller, diesen Code von Grund auf neu zu schreiben, als ihn zu reparieren.

Dann habe ich keine andere Wahl als umschreiben/umgestalten bis der Code sauber genug ist, um den Fehler zu lokalisieren und zu beheben.

Der Fall Borderline ist:

Der Code ist chaotisch und wirklich schlecht. Es ist immer noch möglich, einen Fehler in angemessener Zeit zu beheben, aber die Codestruktur macht es wirklich schwierig, ihn zu warten. Es ist sehr wahrscheinlich, dass neue Funktionen neue Fehler verursachen oder zu erheblichen Leistungseinbußen führen.

In diesem Fall muss der Code repariert werden, aber nur, wenn neue Funktionen implementiert werden sollen, während der Leerlaufzeit, niemals in der Fehlerbehebungszeit angesichts der Frist!

9
Danubian Sailor

Es würde mich interessieren, an welchem ​​Punkt in Ihrem Prozess Sie dieses Problem finden?

Genau genommen sollte in dieser magischen idealen Welt, in der keiner von uns lebt, jeder beworbene oder eingesetzte Code perfekt sein. Es ist nicht so manchmal muss man pragmatisch sein.

Wenn Sie jedoch einen Codeüberprüfungsprozess haben, sollte dieser vor dem Testen hervorgehoben werden. Wenn Sie ständig mit Fristen konfrontiert sind, bedeuten die Probleme bei den Schätzungen für die Lieferung, dass eine Schlüsselkomponente eines Entwicklungsprozesses - dh die Codeüberprüfung - erwürgt wird?

Ihre Junioren werden niemals lernen, sich zurückzulehnen und bessere Methoden zu entwickeln, wenn Sie sich nicht die Zeit nehmen, es zu einem Teil ihres Entwicklungsprozesses zu machen, um zu lernen. Es hört sich für mich so an, als würden Sie das nicht tun.

6
temptar

Kommt auf die Gesamtkultur an. Wenn enge Fristen sporadisch sind, akzeptieren Sie, dass Sie später aufräumen müssen. Wenn sie konstant sind, bauen Sie strukturell technische Schulden auf und sollten das Problem mit dem Management aufgreifen. Wenn sie Ihre Bedenken nicht ansprechen, sollten Sie besser nach anderen Stellen suchen, da die Unternehmenskultur höchstwahrscheinlich bald den darwinistischen Grundsätzen entspricht.

4
user1703394

Um das Problem in Zukunft einzudämmen, entwickeln Sie ein internes Dokument mit Codierungsstandards und -praktiken, das alle Mitarbeiter befolgen müssen.

Bereinigen Sie für den aktuellen Stapel den Code gemäß dem S & P-Dokument, während Sie den Code umgestalten, jedoch nur, wenn Sie ihn umgestalten.

3
Casey

Die beste Vorgehensweise wäre, einen Codierungsstil-Leitfaden zu haben und regelmäßige Überprüfungen durchzuführen, damit Sie bei Annäherung an eine Frist nicht mit diesem Problem konfrontiert werden.

Ich empfehle Ihnen, Führung zu zeigen und die regelmäßige Überprüfung des Codes voranzutreiben. Das Management wird nicht von oben gedrängt, um sicherzustellen, dass regelmäßige Codeüberprüfungen stattfinden. Ich habe jedoch die Erfahrung gemacht, dass sie beeindruckt sein werden, wenn ein Programmierer regelmäßige Codeüberprüfungen plant und durchführt.

Es gibt viele Vorteile für Ihre Mitarbeiter, die:

  • lerne besseren Stil
  • befolgen Sie bessere Praktiken
  • lernen zu erforschen, was sie tun

Und einige Vorteile für Sie selbst werden Sie sein:

  • effizienter bei Last-Minute-Debugs (was immer passieren wird)
  • sowohl von Ihrem Team als auch von Ihrem Management als Experte und Führungskraft anerkannt
2
Aaron Hall

Ich kann den Grund in den Antworten "Nicht reparieren, was funktioniert" und "Verschwenden Sie keine Zeit mit dem, was für den Kunden nicht wichtig ist" sehen. PMs sind besorgt über Risiken und das ist in Ordnung.

Ich verstehe auch, dass die meisten Leute diese Art von Lösung nicht gut nehmen. Ich verstehe das auch.

Ich glaube, dass die meisten Fristen künstlich sind. Reale Systeme leben immer mehr als die Fristen und das schlechte Design, das Sie heute machen, wird Sie für immer und ewig zurückschlagen. Die Leute laufen, um in ein paar Monaten etwas zu liefern, und verbringen Jahre danach damit, einige schlechte Entscheidungen in einem Code zu korrigieren, der in der Produktion ausgeführt wird.

Technische Schulden sind das Wort. Es wird eines Tages zurückkommen und jemand wird dafür bezahlen.

IMO, ich denke, Sie sind genau richtig, um das kaputte Design zu reparieren, und professionell zu sein (speziell für die Junioren) bedeutet auch, dass Sie wissen müssen, wie man Kritik nimmt und daraus lernt, auch wenn es nicht höflich ist. Tatsächlich ist der größte Teil des Lebens sowieso nicht höflich.

2
Leo

Ich bin ziemlich unerfahren mit Programmierung. Als Student verpflichte ich mich jedoch häufig zu Peer Review und Partnerschaften bei Projekten. Wenn genügend Zeit vorhanden ist, um ein Projekt abzuschließen, bereinige ich den Code eines Teammitglieds, um Klarheit und Lesbarkeit zu gewährleisten. Meistens fällt es mir schwer, die ersten 100 Zeilen oder so zu sichten. In diesen Fällen bin ich mehr als bereit, eine Hand zu reichen, um einem Programmierkollegen bessere Gewohnheiten und Codierungen beizubringen. Wenn einfach nicht genug Zeit vorhanden ist, kopiere/füge ich sie einfach ein und arbeite meine Projekte in das Gesamtbild ein, das sich mit ihren schlechten Schnittstellen befasst. Danach werde ich sicher viele Ratschläge zur Codierungstechnik geben. Wenn es um Peer Review geht, kommt konstruktive Kritik (unabhängig davon, wie unerwünscht sie ist) auf lange Sicht nur ihm und mir zugute. Wenn ich in Zukunft mit denselben Personen zusammenarbeite, kann ich sicher sein, dass sie einige informative Richtlinien im Kopf haben, und hoffe nur, dass die nächste Runde viel reibungsloser verläuft.

Wenn Sie Zeit haben, sollten Sie Ihren Neuankömmlingen beibringen, wie sie ihre Arbeit so ausführen, dass alle davon profitieren. Nehmen Sie sich eine Minute Zeit und bringen Sie ihnen bei, was für Sie funktioniert hat und was nicht. Wenn Sie nicht die Zeit haben, machen Sie sich erst einmal mit ihrer Arbeit vertraut und melden Sie sich bei ihnen, wenn Sie die Chance dazu haben. Lassen Sie sie wissen, dass es bessere Möglichkeiten gibt, Dinge zu tun, insbesondere wenn Sie in Zukunft mit ihnen arbeiten werden.

2

Die Verbesserung der Gesamtqualität ist der Verwendung einer einzelnen Person als "Filter" für eine größere Gruppe weit überlegen. In diesem Sinne:

  • Paarprogrammierung funktioniert wie eine aufgemotzte Version der Codeüberprüfung, um zu verstehen, wie man sich entwickelt - es ist wie der Unterschied zwischen Lesen und Tun, Erzählen und Zeigen. Das Beobachten der Codeentwicklung und das schnelle Besprechen von Änderungen ist immens hilfreich, um nicht nur das Wie, sondern auch das Warum von Refactoring und gutem Code zu verstehen. Nach meiner Erfahrung ist es schneller als die alleinige Entwicklung, da Ideen kontinuierlich herumgeworfen werden, was zu einem insgesamt qualitativ besseren Ergebnis und einem besseren Verständnis sowohl des Codes als auch des Codes führt das Denken einer anderen Person.
  • Flusenwerkzeuge kann überprüfen, ob der Codierungsstil eingehalten wird. Dies lehrt jedem , wie man Code formatiert, und Fehler sollten schnell verschwinden, sobald sich Entwickler an den Standard erinnern.
    • Machen Sie diese Teile des Erstellungsprozesses, um sicherzustellen, dass sie vor dem Festschreiben behoben sind.
    • Verwenden Sie Sprachvorlagen, um sicherzustellen, dass Ihr CSS-, HTML-, JavaScript- und serverseitiger Code separat überprüft werden kann.
  • Validierungswerkzeuge kann überprüfen, ob die generierte Ausgabe korrekt ist. Diese sollten auch Teil des Erstellungsprozesses sein.
2
l0b0

Jede klare Antwort wird extrem sein. Natürlich gibt es Fälle, in denen die Frist so eng ist, dass Sie hässlichen Code verwenden müssen, und es gibt Fälle, in denen der Code so hässlich ist, dass es sich lohnt, die Frist zu verpassen, um ihn zu verbessern. Was Sie brauchen, sind Methoden, um zu beurteilen, in welcher Position Sie sich befinden, und möglicherweise Methoden, um realistische Fristen festzulegen, die Zeit lassen, besseren Code zu schreiben.

Speichern Sie die Bereinigung nicht für später. Wenn Sie nicht gewöhnlich Zeiträume haben, in denen nichts anderes als Refactor zu tun ist, gibt es kein "späteres", in dem es irgendwie eine höhere Priorität hat, den Code aufzuräumen als jetzt. Die Routine ist "rot, grün, Refaktor", nicht "rot, grün, zwei Wochen lang etwas völlig anderes machen, Refaktor". Realistisch gesehen werden Sie den Code erst ändern, wenn Sie ihn das nächste Mal aus einem anderen Grund erneut besuchen, und dann haben Sie wahrscheinlich auch eine Frist. Ihre wirklichen Möglichkeiten sind, es jetzt zu reparieren oder es zu verlassen.

Natürlich ist gut gestalteter Code besser als schlecht gestalteter Code, vorausgesetzt, Sie planen, ihn jemals wieder zu lesen. Wenn Sie vorhaben, es nie wieder zu lesen, dann nicht aufräumen. Versenden Sie das erste, was die Tests besteht. Aber das ist ein ziemlich seltenes Szenario, für die meisten Programmierer passiert es ungefähr nie. Wenn Sie diesen Fall ignorieren, haben nur Sie die Details Ihres tatsächlichen Falls, um zu beurteilen, wie viel es kostet, ihn zu reparieren, und wie viel es (bei erhöhter zukünftiger Wartung) kostet, ihn nicht zu reparieren.

Es gibt bestimmte Dinge, die an dem Punkt, an dem der Code gewartet werden muss, nicht schwieriger zu beheben sind als jetzt. Diese Vorteile bringen Ihnen nicht viel, wenn Sie sie jetzt beheben. Die offensichtlichsten sind trivial zu beheben (Leerzeichenfehler und dergleichen) und daher ist es schwer vorstellbar, dass Sie Zeit haben, diese Frage zu stellen, aber nicht zu beheben ;-) Für diejenigen, die nicht trivial sind und von dieser Art sind, dann OK Sie haben einen Code, der nicht ideal ist, aber Sie müssen pragmatisch sein. Es funktioniert und Sie haben eine Frist. Benutze es.

Es gibt bestimmte Dinge, die jetzt wesentlich einfacher zu beheben sind als später, wenn (a) sie nicht in aller Munde sind; (b) andere Dinge wurden geschrieben, die sich auf sie stützen oder sie nachahmen. Diese sind jetzt viel wertvoller zu beheben, also priorisieren Sie sie. Wenn Sie keine Zeit in Ihren Fristen haben, um diese zu beheben, müssen Sie für längere Fristen so hart wie möglich pushen, da Sie Schulden in Ihrer Codebasis aufbauen, die Sie wahrscheinlich beim nächsten Besuch bezahlen müssen der Code.

Die bevorzugte Methode zum Fixieren von Code ist ein Überprüfungsprozess. Kommentieren Sie die Probleme, die Sie damit haben, und senden Sie es an den Junior zurück, um es zu ändern. Sie können Beispiele dafür geben, was Sie meinen, und den Junior verlassen, um alle Fälle im Code zu finden, für die sie gelten, aber nicht nur den Code für sie fertigstellen. Wenn Sie dies tun, geben Sie ihnen keine Möglichkeit, sich zu verbessern.

Sie sollten häufig auftretende Probleme in einen Styleguide schreiben, der besagt: "Mach das nicht, mach das stattdessen" und erklärt, warum. Letztendlich darf der Grund sein, "um unseren Code ästhetisch konsistent zu machen", aber wenn Sie nicht bereit sind, Ihre Regeln mit einer Rechtfertigung aufzuschreiben, sollten Sie wahrscheinlich nicht sein sie auch durchzusetzen. Lassen Sie einfach jeden Programmierer frei wählen.

Achten Sie schließlich auf die Tendenz, Dinge auf unbestimmte Zeit zu optimieren. Die Renditen nehmen ab, und Sie müssen durch Erfahrung lernen, wo sie noch gut sind. Es ist absolut notwendig, dass Sie sich eine realistische Vorstellung davon machen, was gut genug ist, sonst können Sie nicht die Verhandlung führen, bei der Sie sicherstellen, dass Ihre Fristen Ihnen Zeit geben, "gut genug" Code zu erstellen. Verbringen Sie Ihre Zeit mit Dingen, die nicht gut genug sind.

0
Steve Jessop

Wie so viele bereits gesagt haben, wird alles, was Sie in die Luft werfen, immer wieder herunterkommen. Ich glaube an eine starke Einheitlichkeit über eine Codebasis hinweg. Natürlich sind einige Dinge wirklich nicht so wichtig. Zum Beispiel Namenskonventionen für lokale Variablen innerhalb einer Prozedur. Für alles Strukturelle sollte es jedoch sofort repariert werden, bevor es endgültig in den Hauptstamm übergeht. Es mag nur ein wenig mies sein, wenn man sich die einzelnen Prozeduren oder Klassen ansieht, aber wenn jeder "leicht hässlichen" Code festlegt, wird es insgesamt sehr schnell sehr hässlich.

Hässlicher Code, der oft in 90% der Fälle gut funktioniert, aber an den Rändern auseinander fällt. Stellen Sie sicher, dass dies nicht einfach genug ist, indem Sie nur ein paar einfache Regeln befolgen. Erstens sollte es für jeden Programmierer obligatorisch sein, genaue Einschränkungen für jede von ihnen erzeugte Prozedur oder jeden Funktionsblock zu definieren und zu dokumentieren.

Zweitens sollte für jedes Verfahren ein Test gegen diese Einschränkungen durchgeführt werden. Dies sollte ein einfacher Komponententest sein, den der Programmierer vor dem Festschreiben lokal gegen seine Prozedur ausführen kann (und muss). Offensichtlich ist dies mit einer geeigneten Testsuite einfacher zu verwalten, aber auch ohne Test sollte geschrieben und möglicherweise in einer Teilklasse festgeschrieben werden, die vom Build ausgeschlossen werden kann.

Drittens ist eine Reihe standardisierter Entwicklungsumgebungen mit vorkonfigurierten Tools von unschätzbarem Wert. Ein TS-Server ist dafür hervorragend geeignet. Jeder hat genau die gleichen Tools (und Versionen), die gleichen Konfigurationen und die gleichen Updates. Installieren Sie ein Refactoring-Tool wie CodeRush oder Resharper, das gemäß Ihren Standards vorkonfiguriert ist, und weisen Sie die Programmierer an, dass Sie alle Commits ablehnen, für die noch Warnungen vorhanden sind. Jetzt können Sie die Codeüberprüfungszeit Ihres Teams nutzen, um Ihren Regelsatz anhand des Feedbacks tatsächlich zu verbessern, und Ihr Team korrigiert sich gerne selbst, ohne dass Sie danach ständig aufräumen müssen. Für einen Programmierer ist es auch viel einfacher, Codekritik von einem ordnungsgemäß konfigurierten Tool zu übernehmen als von einem Kollegen oder Chef, bei dem die Standards willkürlich definiert zu sein scheinen oder nicht richtig verstanden werden. Wenn das IDE Ihnen sagt, dass Ihr Code schlecht ist, wird niemand damit streiten und es wird korrigiert. Sie werden feststellen, dass die Codequalität dramatisch ansteigen wird und das gesamte Team Geld ausgeben wird Viel weniger Zeit für das Refactoring und Aufräumen nach ein paar Wochen. Programmierer werden sich auch an die Regeln gewöhnen und aufhören, Mistcode zu schreiben.

Schließlich besteht die einfache Lösung darin, den Programmierern einen Anreiz zur Verbesserung zu geben. Programmierer sind per Definition wettbewerbsfähig. Jeder möchte den schönsten oder schnellsten Code haben. Eine gute Möglichkeit, alle zu motivieren, die Produktivität zu verbessern und Inkompetenzen auszurotten, besteht darin, eine wöchentliche gewichtete Anzeigetafel für alle zu berechnen und beispielsweise Punkte für abgelehnte Commits und Terminüberschreitungen abzunehmen. Zeigen Sie die Top N bei der wöchentlichen Teambesprechung und zahlen Sie vielleicht sogar das Mittagessen an denjenigen, der im Durchschnitt des Monats an erster Stelle steht.

0

Ich schlage vor, ein Überprüfungstool zu verwenden. Wenn Sie ein Git-basiertes Repository haben, können Sie das Überprüfungstool Gerrit verwenden. Nach einigen abgelehnten Commits lernt das Team die Standards, denen Sie folgen möchten, und zukünftige Commits erfordern keine zusätzliche Arbeit von Ihnen.

Commits warten auf Ihre Annahme. Wenn Sie Zeilen sehen, die neu geschrieben werden sollten, können Sie Kommentare schreiben und Ihre Teamkollegen können den Code basierend auf Ihren Anforderungen selbst korrigieren. Es ist wirklich eine gute Möglichkeit, Teammitglieder zu lernen Codierungsstandards .

0