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


38

(Ich spreche über HTML / CSS-Code (keine Programmiersprachen), aber ich denke, wir stehen auch vor dem gleichen Problem wie bei Programmierern.)

Ich bin der leitende Front-End-Designer in einem Team und muss die Ergebnisse meiner Junioren oft in engen 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 / Norm. Ich bin hin- und hergerissen zwischen dem Aufräumen des Codes oder dem einfachen Umgang mit dem 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 chaotischen Code geschrieben, als ich anfing.)


1
Wenn Sie die Möglichkeit haben, schauen Sie sich die JetBrains-Produkte an (Re-Sharper für C #, IntelliJ für Java und sogar einige "dynamische" Sprachen), die projektweite idiomatische Änderungen lösungsweit und mit sehr geringem Zeitaufwand durchführen können. (Es kann auch verwendet werden, um dem Junior interaktiv beizubringen, was idomatisch ist. Stellen Sie jedoch sicher, dass Sie und er dieselben Einstellungen für das Projekt festlegen inhaltliche und kosmetische Änderungen im gleichen Commit),
David Bullock


2
Styleguide / Minimanual implementieren? Ich meine, dass sie keinen besseren Code schreiben werden, aber jeder ist in der Lage, Richtlinien zu befolgen, die es erfordern, triviale Dinge auf eine bestimmte Art und Weise zu schreiben.
Peteris

10
Ich sehe, dass Sie hier bereits ein Problem mit mangelnder Teamarbeit haben. Sie sollten den Nachwuchs erziehen und fördern ; nicht nur seinen oder ihren Code umschreiben und sich darüber beschweren.
James

3
@ Ramhound, seit Turing die Turing-Maschine erfunden hat, denke ich. Aber zurück zum Punkt, wenn Sie der Ältere sind, der die Jüngeren dazu bringen sollte, Sie anzuhören. Bringen Sie ihnen bei, wie man richtig (oder nach Überzeugung) handelt. Aber es ist wichtig, nach ihrer Meinung zu fragen, und vielleicht haben sie einige Ideen, wie sie das Zeug besser machen können. Wenn Sie RAW-CSS für ein nicht triviales Projekt verwenden, versuchen Sie, Ihr Projekt dazu zu bringen, LESS oder SASS zu übernehmen.
Hoffmann

Antworten:


79

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 gewohnheitsmäßig neu schreiben, können Sie Ihren Junioren den Eindruck vermitteln, dass Sie ihre Arbeit nicht schätzen, was ihre Moral mindert und ihnen beim nächsten Mal nicht hilft, besser zu programmieren.

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

Wenn der Teamkollege, der den Code überprüft, Sie sind, wird er viel mehr aus Ihrem Fachwissen lernen, als wenn Sie einfach seinen Code neu schreiben (er hat die Möglichkeit zu hören, warum der Code geändert werden sollte), und wird möglicherweise weniger Anstoß nehmen.

Indem Sie ihnen die Möglichkeit geben, auch Code-Reviews durchzuführen, verbessern Sie ihre Fähigkeiten - sehen, wie andere Leute Code schreiben und warum - und steigern ihr Selbstwertgefühl.

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


Ich stimme Ihnen zu 100% zu, aber ich frage mich, wie ich das bei engen Fristen anwenden soll. Schlagen Sie vor, Codeüberprüfungen durchzuführen, obwohl diese möglicherweise mehr Zeit in Anspruch nehmen (sowohl für den Überprüfungsprozess als auch für die nach der Überprüfung vorgenommenen Korrekturen)?
Phil

3
Ich denke nicht, dass ein Teammitglied die Arbeit eines anderen Teammitglieds ohne seine Mitarbeit / Zustimmung ändern sollte. Die Person, die den Code geschrieben hat, sollte dafür verantwortlich sein. Wenn der Code keinen kritischen Fehler enthält und der ursprüngliche Schreiber nicht verfügbar ist, ist die Einhaltung eines engen Zeitplans kein Grund, den Code einer anderen Person zu ändern. Wenn der Code zu unübersichtlich ist, teilen Sie ihn dem Entwickler mit und fordern Sie ihn auf, ihn für die nächste Version zu bereinigen.
Uri Agassi

23
@Phil Bei der Berechnung einer Frist sollte die Zeit für Code-Überprüfungssitzungen berücksichtigt werden. Es ist kein zusätzlicher Schritt über den Entwicklungsprozess hinaus - es ist ein wesentlicher Bestandteil des Entwicklungsprozesses.
18.

2
Außerdem kann die Schulung von Junioren über die Codeüberprüfung jetzt einen gewissen Zeitaufwand verursachen (der laut DJ18 ohnehin in Ihren Terminen und Schätzungen berücksichtigt werden sollte), der jedoch zu gegebener Zeit um ein Vielfaches zurückgezahlt wird, da Sie dadurch Zeit haben originellere Arbeit. Wenn Ihre Fristen so eng sind, dass Sie nie die Möglichkeit dazu haben, riecht es eher nach einer Todesspirale ...
Julia Hayward

2
@ JustinPaulson versteh mich nicht falsch - die Tatsache, dass jemand Code geschrieben hat, macht diesen Code nicht zu "seinem". Eine Woche später erhält ein anderes Teammitglied eine Aufgabe, bei der es erforderlich ist, diesen Code zu ändern, und sie sollte den Code auf jeden Fall an ihre Bedürfnisse anpassen. Ich sehe jedoch keinen Anwendungsfall, in dem jemand den Code eines anderen zum Zwecke der Bereinigung "bereinigen" sollte, insbesondere nicht als Last-Minute-Sache in einer engen Frist.
Uri Agassi

29

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 groß, 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 auf jeden Fall Ihre Junioren, sauberen, verständlichen Code zu schreiben. Wenn Sie jedoch alles, was sie schreiben, neu schreiben, verschwenden Sie das Geld Ihres Arbeitgebers um ein Vielfaches. Sie müssen für Ihre Junioren bezahlen, dann für Sie, um das zu 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.


11
"Wenn dies getesteter Code ist, haben Sie gerade den gesamten Testaufwand ungültig gemacht und müssen die Tests wiederholen." Nein, Sie haben keine Testanstrengungen ungültig gemacht. Sie müssen nur die Tests wiederholen , die Sie für jedes Commit trotzdem durchführen sollten. Wenn das so lange dauert, dass es für unmöglich gehalten wird, sind die Tests Mist und sollten behoben werden.
l0b0

7
Es sollte beachtet werden, dass das kontinuierliche Schreiben von schlampigem Code, um "es zum Laufen zu bringen", zu einem großen Schlammballen führt . Es ist in Ordnung, wenn es eine Ausnahme ist und nicht die Regel. Wenn es zur Regel wird, sollten Sie mit Ihrem Chef darüber sprechen, dass nicht nur Fristen zu berücksichtigen sind.
Neil

20
Das Problem ist, dass sich hässlicher Code schnell in fehlerhaften Code verwandelt.
Telastyn

1
@ramhound - klar, aber das OP (und fast alle anderen) reden nicht über Code, der einfach alte Standards verwendet - sie reden über umständlichen, inkonsistenten, schlampigen Code.
Telastyn

1
@JamesAnderson Dies ist eine äußerst kurzsichtige Perspektive. Code wird einmal geschrieben, aber für die gesamte Lebensdauer des Produkts beibehalten. Die meisten Codierungen werden überarbeitet. Wie lange schreiben Sie tatsächlich Code auf einen leeren Bildschirm, bevor Sie ihn optimieren und prüfen, ob er wie erwartet ausgeführt wird? Deshalb überarbeiten Sie bereits in der ersten Stunde nach Beginn einer neuen Klasse. Die Kosten für die Umgestaltung von hässlichem Code in nachfolgenden Fehlerkorrekturen und Verbesserungen übersteigen die Kosten für ein wenig Zeit, die im Vorfeld für Codeüberprüfungen aufgewendet wurde, um das Team auf einen klaren Standard zu bringen.
Scott Shipp

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

  • Eine pragmatischere Antwort ist es, die Zeit zu verkürzen. Planen Sie eine Stunde ein, um einen bestimmten Aspekt des Codes zu durchlaufen und zu bereinigen . Dann checke es ein und mache echte Arbeit. Aber seien Sie ehrlich zu sich selbst, wenn es darum geht, es zu beschränken.

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

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

Aber in der Antwort steckt ein 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) anfassen kann, ohne etwas Zeit für die Bereinigung aufzuwenden. Aber stellen Sie sicher , dass mit Stil und Format Getue und Stil Kriege werden nicht mehr wichtiger als den Code Produktion zu bekommen.


9

Beim Korrigieren des Codes und bei der Einhaltung der Frist wende ich normalerweise zwei Regeln an:

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

Ich behebe ein Problem und lasse den Rest intakt .

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

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

Der Grenzfall ist:

Der Code ist chaotisch und sehr schlecht. Es ist immer noch möglich, einen Fehler in angemessener Zeit zu beheben, aber die Codestruktur erschwert die Wartung. Jede neue Funktion führt sehr wahrscheinlich zu neuen Fehlern oder zu einer signifikanten Leistungsminderung.

In diesem Fall muss der Code korrigiert werden, jedoch nur, wenn neue Funktionen implementiert werden sollen, und zwar in der Leerlaufzeit, niemals in der Fehlerbehebungszeit vor Ablauf der Frist!


Das Problem mit dem "Borderline Case" ist, dass andere Module auftauchen, die diesen Code verwenden. Es wird dann sehr riskant, Änderungen vorzunehmen, da andere Module nun möglicherweise auf "falsches / unerwünschtes" Verhalten angewiesen sind. Sie bleiben also mit Code stecken, der wirklich schwer zu pflegen ist und der Sie jedes Mal zusammenzucken lässt, wenn Sie ihn sehen, und der Sie dazu bringt, sich anderweitig zu engagieren. Schlechter Code muss zumindest von jemandem abgeschirmt werden, der weiß, was er tut. Auf diese Weise kann es zu einem späteren Zeitpunkt repariert werden, ohne dass das Risiko besteht, es einfach zu verlassen, bis jemand Zeit hat, sich darum zu kümmern.
Dunk

6

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

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

Wenn Sie jedoch einen Codeüberprüfungsprozess durchführen, sollte dieser vor dem Testen hervorgehoben werden. Wenn Sie ständig mit Terminen konfrontiert sind, bedeutet das Problem, dass die Schätzungen für die Lieferung bedeuten, dass eine Schlüsselkomponente eines Entwicklungsprozesses - dh die Codeüberprüfung - erdrosselt wird?

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


4

Kommt auf die Gesamtkultur an. Akzeptieren Sie, dass Sie später eine Bereinigung durchführen müssen, wenn sporadisch enge Fristen gelten. Wenn sie konstant sind, bauen Sie strukturell technische Schulden auf und sollten das Problem mit dem Management aufgreifen. Wenn sie nicht auf Ihre Bedenken eingehen, sollten Sie besser nach anderen Beschäftigungsmöglichkeiten suchen, da die Unternehmenskultur höchstwahrscheinlich bald den darwinistischen Grundsätzen entspricht.


3

Entwickeln Sie ein internes Coding Standards and Practices-Dokument, das von allen Mitarbeitern befolgt werden muss, um das Problem in Zukunft einzudämmen.

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


Ich habe für einige große, sehr prozessorientierte Unternehmen gearbeitet, die bereit waren, Unmengen an Geld auszugeben, um sicherzustellen, dass die Codierungsstandards und -praktiken eingehalten wurden. SIE WAREN NIE, bis automatisierte Werkzeuge anfingen, sie durchzusetzen.
Dunk

@Dunk Zählt das US-Militär als "groß und prozessorientiert"? Sie verwenden ständig S & Ps: stroustrup.com/JSF-AV-rules.pdf
Casey

Sie gelten mit Sicherheit als Goldstandard für Kodierungsstandards und -praktiken. Jeder Vertrag erfordert sie. So sehr sich Unternehmen jedoch bemühen, ihre Standards und Praktiken einzuhalten, so zuverlässig und konsequent geschieht dies nicht. Es ist einfach zu viel los. Aus diesem Grund sind automatisierte Tools erforderlich, wenn Sie das Wort "Muss" in Ihren Vorschlag aufnehmen möchten, wie Sie es getan haben. Das DOD erkannte die Unmöglichkeit der Einhaltung von Standards mit manuellen Mitteln an und deshalb verabschiedete der Kongress 2011 ein Gesetz, das Verteidigungsunternehmen dazu aufforderte, automatisierte Tools für die Durchführung dieser Überprüfungen einzusetzen.
Dunk

BTW, ich sage nicht, dass es keine Notwendigkeit gibt, Standards und Praktiken zu codieren. Es besteht absolut Bedarf. Ich habe gerade eine Auseinandersetzung mit dem Teil "Alle Mitarbeiter müssen folgen", es sei denn, Sie erwähnen auch etwas über die Durchsetzung durch automatisierte Tools.
Dunk

@Dunk Das JSF-AV-Team muss dies erkannt haben. In dem Dokument wird speziell die Verwendung automatisierter Tools als Möglichkeit zur Durchsetzung der S & P erwähnt (im Jahr 2005)
Casey

2

Ich bin mit Programmierung ziemlich unerfahren. Als Student engagiere ich mich jedoch häufig für Peer Review und Partnerschaften bei Projekten. Wenn genügend Zeit vorhanden ist, um ein Projekt abzuschließen, werde ich den Code eines Teammitglieds aus Gründen der Klarheit und Lesbarkeit bereinigen. 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 anderen Programmierern bessere Gewohnheiten und Codierungen beizubringen. Wenn die Zeit dafür nicht ausreicht, kopiere ich sie einfach, füge sie ein und bearbeite meine Projekte mit dem Gesamtbild der schlechten Benutzeroberflächen. Danach werde ich Ihnen sicher viele Tipps zur Codierungstechnik geben. Konstruktive Kritik (unabhängig davon, wie unerwünscht sie ist) kommt bei der Begutachtung durch Fachkollegen auf lange Sicht nur ihm und mir zugute.

Wenn Sie Zeit haben, sollten Sie Ihren Neuankömmlingen zeigen, 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, lassen Sie die Arbeit fürs Erste hinter sich und melden Sie sich bei ihnen, wenn Sie die Gelegenheit dazu haben. Lassen Sie sie wissen, dass es bessere Möglichkeiten gibt, Dinge zu tun, besonders 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 bei weitem überlegen. In diesem Sinne:

  • Das Programmieren von Paaren funktioniert wie eine erweiterte 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. Wenn Sie beobachten, wie sich Code weiterentwickelt und Änderungen schnell besprochen werden, ist dies 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 das Entwickeln allein, da ständig Ideen herumgeschleudert werden, was zu einem insgesamt besseren Ergebnis und einem besseren Verständnis sowohl des Codes als auch des Denkens der anderen Person führt.
  • Fusselwerkzeuge können überprüfen, ob der Codierungsstil eingehalten wird. Dies lehrt jeden, wie man Code formatiert, und Fehler sollten schnell auftreten, sobald sich die Entwickler an den Standard erinnern.
    • Nehmen Sie diese Elemente in den Erstellungsprozess vor, 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.
  • Validierungstools können überprüfen, ob die generierte Ausgabe korrekt ist. Diese sollten auch Teil des Erstellungsprozesses sein.

2

Am besten ist es, einen Kodierungsstil-Leitfaden zu haben und regelmäßige Überprüfungen durchzuführen, damit Sie nicht mit diesem Problem konfrontiert werden, wenn Sie sich einer Frist nähern.

Ich empfehle Ihnen, die Führung zu übernehmen 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, aber meiner Erfahrung nach werden sie beeindruckt sein, wenn ein Programmierer die regelmäßigen Codeüberprüfungen plant und durchführt.

Es gibt viele Vorteile für Ihre Leute, die werden:

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

Und einige Vorteile für Sie selbst:

  • effizienter bei Last-Minute-Debugs (was immer passieren wird)
  • Sowohl von Ihrem Team als auch vom Management als Experte und Leiter anerkannt

1
Das Problem beim Codieren von Styleguides ist, dass sie dazu neigen, sich in Bücher zu verwandeln. Die meisten Menschen sind bereit zu lernen und sich an ein recht bescheidenes Regelwerk zu halten. Leider gehen diese Anleitungen irgendwann immer über die Fähigkeit der Menschen hinaus, alle Regeln zu lernen und sich daran zu erinnern. Sie benötigen ein Tool, das automatisch Stilprüfungen durchführt. Code Reviews sollten nicht zur Durchführung von Grammatikprüfungen, sondern zum Auffinden von Fehlern und Missverständnissen dienen.
Dunk

Als Python-Programmierer und Leiter der Codeüberprüfung habe ich PEP 8 und Googles Python-Style-Handbuch mindestens ein Dutzend Mal ausgedruckt, um es weiterzugeben. Was auch immer Programmierer nicht von ihnen lernen werden, sie werden hinter denen zurückfallen, die dies tun. Trotzdem stimme ich zu, dass ein Style Checker auch eine gute Praxis ist, wenn Sie ihn implementieren können.
Aaron Hall

Ich verwende Python nicht, daher kenne ich die verfügbaren Tools nicht. Wenn Sie sich jedoch auf Codeüberprüfungen verlassen, um Ihre Stilregeln durchzusetzen, verschwenden Sie Hunderte (wenn nicht Tausende) Stunden pro Jahr für etwas, das Sie tun konnte für Sie im Wesentlichen ohne Zeitaufwand erledigt werden. Ich würde auf keinen Fall eine eigens entwickelte Version implementieren. Ich würde das Geld ausgeben, um eine kommerzielle Version zu kaufen, die viel besser ist als alles, was in der Freizeit selbst gebaut werden kann. Auch die teuren Werkzeuge machen sich um ein Vielfaches bezahlt.
Dunk

Python, das Open-Source-Füllhorn, das es ist, verfügt über alle Arten von kostenlosen Tools (Pylint, Pep8, Pyflakes), von denen einige von uns kombiniert und verbessert wurden.
Aaron Hall

1
: Ich bezog mich auf Ihr Snippet "Wenn Sie es implementieren können". Wenn Sie einen Style Checker kaufen könnten, dann ist dies der richtige Weg. Wenn Sie Ihr Team in einer angemessenen Zeit so etwas Nützliches implementieren lassen könnten, muss es ein Unternehmen / Open Source geben, das dies bereits getan hat. Es wäre also weitaus kostengünstiger, es einfach zu kaufen. Ich bin mir sicher, dass es besser und aktueller wäre als eine "nicht-produktive" Version aus eigenem Anbau. Wenn Sie Tausende von Entwicklern haben, habe ich die Einsparungen, die ein automatisiertes Tool zur Stil- / Sicherheitsüberprüfung bringen würde, bei weitem unterschätzt.
Dunk

2

Ich kann den Grund in den Antworten "Nicht reparieren, was funktioniert" und "Verschwenden Sie Ihre Zeit nicht damit, 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 finden. 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 tun, werden Sie für immer und ewig zurückschlagen. Die Leute versuchen 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.

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

Also, 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 aufnimmt und daraus lernt, auch wenn es nicht höflich ist. Tatsächlich ist der Großteil des Lebens sowieso nicht höflich.


0

Jede klare Antwort wird extrem sein. Offensichtlich gibt es Fälle, in denen die Frist so kurz 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 welchem ​​Bereich Sie sich befinden, und vielleicht Methoden, um realistische Fristen festzulegen, die Zeit zum Schreiben von besserem Code lassen.

Bewahren Sie die Bereinigung nicht für später auf. Es gibt kein "späteres" Ereignis, in dem die Aufräumarbeiten für den Code eine höhere Priorität haben als im Moment, es sei denn, Sie haben normalerweise Zeiträume, in denen Sie nichts anderes zu tun haben als die Umgestaltung. Die Routine lautet "rot, grün, refaktorieren", nicht "rot, grün, zwei Wochen lang etwas völlig anderes tun, refaktorieren". Realistisch gesehen werden Sie den Code erst ändern, wenn Sie ihn das nächste Mal aus einem anderen Grund erneut aufrufen, und dann werden Sie wahrscheinlich auch eine Frist einhalten. Ihre wirklichen Optionen sind, es jetzt zu reparieren oder es zu lassen.

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, räumen Sie es nicht auf . 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 realen Falls, um zu beurteilen, wie viel es kostet, ihn zu reparieren, und wie viel es kostet (bei einer erhöhten zukünftigen Wartung), 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 Probleme können Sie jetzt nicht wirklich beheben. Die offensichtlichsten sind trivial zu beheben (Whitespace-Fehler und ähnliches) und so ist es schwer vorstellbar, dass Sie Zeit haben, diese Frage zu stellen, aber sie 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 in den Köpfen aller nicht so frisch sind; (b) andere Dinge wurden geschrieben, die sich auf sie stützen oder sie imitieren. Diese Probleme können jetzt viel besser behoben werden. Priorisieren Sie sie daher. Wenn Sie in Ihren Fristen keine Zeit haben, diese zu korrigieren, müssen Sie so viel Druck wie möglich auf längere Fristen ausüben, da Sie in Ihrer Codebasis Schulden aufbauen, die Sie wahrscheinlich beim nächsten Besuch bezahlen müssen der Code.

Die bevorzugte Methode zum Korrigieren von Code ist ein Überprüfungsprozess. Kommentieren Sie die Probleme, die Sie damit haben, und senden Sie sie an den Junior zurück, um sie zu ändern . Sie können Beispiele geben, was Sie meinen, und dem Junior überlassen, alle Fälle in dem Code zu finden, auf den er sich bezieht, aber den Code nicht einfach für ihn zu Ende bringen. Wenn du das tust, gibst du 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 Begründung aufzuschreiben, sollten Sie sie wahrscheinlich auch nicht durchsetzen. Lassen Sie einfach jedem Programmierer die freie Wahl.

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 wichtig, dass Sie eine realistische Vorstellung davon haben, was gut genug ist. Andernfalls 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

Wie schon so viele gesagt haben, wird alles, was Sie in die Luft werfen, immer wieder runterkommen. Ich glaube an starke Einheitlichkeit über eine Codebasis. Natürlich sind manche Dinge nicht so wichtig. Zum Beispiel Namenskonventionen für lokale Variablen innerhalb einer Prozedur. Für alles, was strukturell ist, sollte es jedoch sofort repariert werden, bevor es endgültig in den Hauptstamm übergeht. Wenn man sich die einzelnen Prozeduren oder Klassen ansieht, ist es vielleicht nur ein bisschen mies, aber wenn jeder "leicht hässlichen" Code schreibt, wird es sehr schnell wirklich hässlich.

Hässlicher Code, der oft funktioniert, funktioniert in 90% der Fälle einwandfrei, fällt jedoch an den Rändern auseinander. Stellen Sie sicher, dass dies normalerweise nicht einfach genug ist, indem Sie nur ein paar einfache Regeln befolgen. Erstens sollte es für jeden Programmierer obligatorisch sein, genaue Beschränkungen für jede Prozedur oder jeden Funktionsblock, die sie erzeugen, 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 ausführen kann (und muss). Offensichtlich ist dies mit einer richtigen 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 hierfür hervorragend geeignet. Jeder Benutzer verfügt über dieselben Tools (und Versionen), dieselben Konfigurationen und dieselben Updates. Installieren Sie ein Refactoring-Tool wie CodeRush oder Resharper, das gemäß Ihren Standards vorkonfiguriert ist, und weisen Sie Programmierer an, Commits mit Warnungen abzulehnen. Jetzt können Sie die Codeüberprüfungszeit Ihres Teams nutzen, um das Feedback zu Ihrem Regelsatz tatsächlich zu verbessern, und Ihr Team korrigiert sich glücklich, ohne dass Sie danach ständig aufräumen müssen. Es ist für einen Programmierer auch viel einfacher, Code-Kritik von einem richtig konfigurierten Tool zu nehmen als von einem Kollegen oder Chef, bei dem die Standards willkürlich definiert zu sein scheinen oder nicht richtig verstanden werden. Wenn Ihnen die IDE mitteilt, dass Ihr Code schlecht ist, niemand wird sich damit streiten und es wird korrigiert. Sie werden feststellen, dass die Codequalität dramatisch steigen wird und das gesamte Team nach ein paar Wochen VIEL weniger Zeit für die Umgestaltung und Bereinigung aufwenden wird. 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 steigern und die Inkompetenz zu beseitigen, besteht darin, eine wöchentliche gewichtete Anzeigetafel für alle zu berechnen, in der beispielsweise Punkte für abgelehnte Commits und Terminüberschreitungen abgezogen werden. Zeigen Sie bei der wöchentlichen Teambesprechung die besten N, und zahlen Sie demjenigen, der im Monatsdurchschnitt den ersten Platz einnimmt, vielleicht sogar das Mittagessen.


0

Ich schlage vor, ein Überprüfungstool zu verwenden. Wenn Sie ein Git-basiertes Repository haben, können Sie das Gerrit- Überprüfungstool 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 umgeschrieben 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, die Codierungsstandards von Teammitgliedern zu erlernen .

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.