Sollte ich die Fähigkeiten meines Codes verringern, wenn mein Team über geringe Fähigkeiten verfügt? [geschlossen]

156

Zum Beispiel gibt es ein allgemeines Snippet in JS, um einen Standardwert zu erhalten:

function f(x) {
    x = x || 'default_value';
}

Diese Art von Snippet ist für alle Mitglieder meines Teams nicht leicht zu verstehen, da ihr JS-Level niedrig ist.

Sollte ich diesen Trick dann nicht anwenden? Es macht den Code für Peers weniger lesbar, aber für jeden JS-Entwickler besser lesbar als die folgenden:

function f(x) {
    if (!x) {
        x = 'default_value';
    }
}

Klar, wenn ich diesen Trick benutze und ein Kollege ihn sieht, kann er etwas lernen. Aber es kommt oft vor, dass sie dies als "versuchen, klug zu sein" ansehen.

Soll ich also die Ebene meines Codes senken, wenn meine Teamkollegen eine niedrigere Ebene als ich haben?

Florian Margaine
quelle
42
Ich glaube, das läuft auf die Frage hinaus: "Solltest du idiomatischen Code schreiben und Leute auf diese Ebene zwingen? Oder nicht-idiomatischen Code schreiben, der alles explizit ausdrückt?"
53
Verringern Sie nicht die Fähigkeitsstufe Ihres Codes! Ich habe so viel gelernt, indem ich den Code fortgeschrittener Programmierer gelesen habe. Schaffen Sie eine Kultur, in der Ihre Kollegen gefragt werden (und lernen), wenn sie etwas nicht verstehen. Stellen Sie einfach sicher, dass Sie konsistent sind.
Kosta Kontos
6
Haben Sie Code-Reviews? Das wäre ein ausgezeichneter Ort für sie, um Fragen zu diesem Code zu stellen.
Thegrinner
3
Ein Teil der Codierfertigkeit ist die Klarheit unter Berücksichtigung Ihres "Publikums". Diese spezielle Sprache scheint es wert zu sein, unterrichtet zu werden, aber es wird sicherlich Fälle geben, in denen es sinnvoller ist, einen transparenteren Codierungsstil zu verwenden.
LarsH
3
Ist es nur gemein, wer denkt, dass das zweite Beispiel von besserer Qualität ist als das erste Beispiel, da das, was getan wird, kristallklar ist? Das zweite Beispiel scheint lesbarer zu sein als die Short-Handed-Version, die das erste Beispiel ist. Gibt es keine Tools, die automatisch von Menschen erstellten Code verwenden und für Javascript optimieren? Aufgrund meiner Javascript-Erfahrung muss der tatsächlich ausgeführte Code nicht unbedingt so effektiv wie möglich sein.
Ramhound

Antworten:

135

Ok, hier ist meine Sicht auf dieses große und komplizierte Thema.


Vorteile für die Beibehaltung Ihres Codierungsstils:

  • Dinge wie x = x || 10sind idiomatisch in der JavaScript-Entwicklung und bieten eine Form der Konsistenz zwischen Ihrem Code und dem Code der von Ihnen verwendeten externen Ressourcen.
  • Eine höhere Codeversion ist oft aussagekräftiger, Sie wissen, was Sie erhalten, und es ist für hochqualifizierte Fachleute einfacher, sie zu lesen.
  • Sie werden Ihren Job mehr genießen. Ich persönlich schätze es, schönen Code zu erstellen. Ich denke, es bringt mir viel Befriedigung in meiner Arbeit.
  • Im Allgemeinen wird ein besser lesbarer Stil erstellt. Sich an die Redewendungen der Sprache zu halten, kann sehr wertvoll sein - oft sind es Redewendungen aus einem bestimmten Grund.

Nachteile für die Beibehaltung Ihres Codierungsstils:

  • Es wird schwieriger für die untergeordneten Programmierer, Schritt zu halten. Dies sind oft die Leute, die Ihren Code pflegen und diejenigen, die das, was Sie schreiben, tatsächlich lesen müssen.
  • Maintainer von Code, häufig JavaScript-Code, stammen aus anderen Sprachen. Ihre Programmierer beherrschen möglicherweise Java oder C #, verstehen jedoch nicht, wie und wann sich JavaScript genau unterscheidet. Diese Punkte sind oft idiomatisch - ein sofort aufgerufener Funktionsausdruck (IIFE) ist ein Beispiel für ein solches Konstrukt.

Meine persönliche Meinung

Sie sollten die Fähigkeit Ihres Codes nicht verringern. Sie sollten danach streben, ausdrucksstarken, klaren und prägnanten Code zu schreiben. Wenn Sie irgendwelche Zweifel über das Niveau Ihres Teams haben - bilden Sie sie aus . Die Menschen sind mehr als bereit zu lernen, als Sie vielleicht denken, und sie sind bereit, neue Konstrukte anzupassen, wenn sie davon überzeugt sind, dass sie besser sind.

Wenn sie denken, dass Sie nur schlau sind, versuchen Sie, Ihren Standpunkt zu argumentieren. Seien Sie bereit zuzugeben, dass Sie manchmal falsch liegen, und versuchen Sie auf jeden Fall, die Stile in Ihrer gesamten Arbeitsumgebung einheitlich zu halten. Dies hilft, Feindseligkeiten zu vermeiden.

Das Wichtigste ist, konsequent zu bleiben.

Der Code eines Teams sollte so geschrieben werden, als ob eine Person ihn codiert hätte. Sie müssen sich unbedingt auf Kodierungsrichtlinien einigen. Sie sollten sich an diese Richtlinien halten. Wenn in den Kodierungsrichtlinien festgelegt ist, dass das Lesen optionaler Parameter weniger clever erfolgen soll, ist dies der richtige Weg.

Benjamin Gruenbaum
quelle
1
Ich weiß, Lernen ist eine konstante Sache, aber ist es wirklich die Aufgabe dieses Entwicklers, seine Kollegen zu schulen? Es sollte wirklich Aufgabe des Managements sein, das für sie am besten geeignete Training zu finden.
CorsiKa
8
@corsiKa Es ist unwahrscheinlich, dass diese Entwickler alle Eigenheiten einer Sprache durch "kostenpflichtiges Training" (dh die Art des Trainingsmanagements, an das die Mitarbeiter gesendet werden) lernen. Ich halte es für einen kranken Arbeitsplatz, wenn Mitarbeiter nicht voneinander lernen. Es ist nicht so, dass das OP ihnen eine Schulung im Klassenzimmer geben müsste. Die Leute können einfach Fragen stellen, wenn sie nicht weiterkommen, und wie in einem Kommentar oben erwähnt, können Codeüberprüfungen hilfreich sein, um diese Art von Wissen weiterzugeben.
MetalMikester
2
Seine Kollegen sollten aus den Beispielen des OP (und anderer) selbständig lernen. Andernfalls werden sie niemals über ihr aktuelles Wissen hinausgehen. Das OP sollte nicht stundenlang dauern, um sie persönlich zu trainieren, aber Code-Reviews und eine gelegentliche Brown-Bag-Sitzung können jedem helfen (also jedem, der etwas lernen möchte ).
Alroc
1
@corsiKa war sich einig, dass eine Überprüfung des Codes eines älteren Entwicklers kein adäquates Training für sich ist, obwohl dies eine gute Möglichkeit sein kann, Dinge zu identifizieren, die der jüngere Entwickler später nachschlagen sollte.
Dan Lyons
2
@yms Fair genug, das ist ein gültiger Standpunkt. Ich habe nie argumentiert, dass Lesbarkeit König ist. Ich habe starke Einwände gegen die Verwendung mehrerer Sprachen, als ob sie dieselbe Sprache wären. Ein Einwand, der in Hunderten von Stunden des Debuggens "verdient" wurde. Ich stimme voll und ganz zu, dass die Lesbarkeit von entscheidender Bedeutung ist, aber ich glaube, dass Sie Codes in mehreren Sprachen nicht auf ähnliche Weise behandeln können. Darüber hinaus glaube ich, dass der größte Teil des schlechten Rufs von JavaScript darauf zurückzuführen ist. Die Leute erwarten, dass es sich wie eine andere Sprache verhält, aber das tut es nicht. Ich stimme zu, dass die Lesbarkeit von entscheidender Bedeutung ist. Besserer Code ist immer besser lesbar :)
Benjamin Gruenbaum
47

Kommentar Gut

Sollten Sie die Fähigkeit Ihres Codes verringern? Nicht unbedingt, aber Sie sollten auf jeden Fall die Fähigkeiten Ihrer Kommentare verbessern . Stellen Sie sicher, dass Sie gute Kommentare in Ihren Code einfügen, insbesondere in den Abschnitten, die Ihrer Meinung nach komplizierter sind. Verwenden Sie nicht so viele Kommentare, dass es schwierig wird, dem Code zu folgen, aber stellen Sie sicher, dass der Zweck jedes Abschnitts klar ist.

Die Realität ist, dass es für weniger qualifizierte Teammitglieder nützlich sein kann, mit Kommentaren etwas ausführlicher zu sein, aber diejenigen mit den geringsten Fähigkeiten können sie ignorieren, besonders wenn es zu viele gibt, also übertreiben Sie es nicht.

Eine Frage des Stils?

Das Beispiel, das Sie angegeben haben, ist etwas grundlegend, aber auch eher stilistisch. Ein Kommentar zu jeder Variablenvorgabe wäre ziemlich mühsam zu pflegen und zu lesen. Stattdessen sollten wahrscheinlich stilistische oder wiederholte Verknüpfungen oder Codemuster als Standard festgelegt werden. Wenn Sie der Meinung sind, dass so etwas wie das Standardisieren von Parametern von allen verstanden und jedes Mal verwendet werden sollte, schreiben Sie diese Ideen auf und bringen Sie sie zu Ihrem Teamleiter. Es ist alles möglich, was Sie brauchen, um Ihre Teamkollegen zu unterrichten, ist ein einfaches Meeting, in dem Sie die von Ihnen vorgeschlagenen Standards besprechen.

Halten Sie die Antwort, wie bereits erwähnt, konsistent .

Bringe einem Mann das Fischen bei ...

Das Unterrichten Ihrer Teamkollegen ist wahrscheinlich der beste Weg, um allen Beteiligten zu helfen. Stellen Sie klar, dass sich jeder, der eine Frage zu einem Code mit Ihrem Namen im Commit-Protokoll oder in den Zeitstempeln hat, frei fühlen sollte, Sie danach zu fragen. Wenn Ihr Team Code-Überprüfungen hat, ist dies eine großartige Gelegenheit , Ihren Teamkollegen verwirrenden (ähm), gut kommentierten Code zu erklären . Wenn Ihr Team keine Codeüberprüfungen hat, warum nicht? Komm schon!

Sie müssen jedoch vorsichtig sein. Sie sind möglicherweise nicht immer in der Nähe, um Menschen zu unterrichten, und vergessen möglicherweise sogar, was Sie ursprünglich in einem bestimmten Codeabschnitt versucht haben.

"Clevere" Tricks

Es ist auf jeden Fall wichtig, die Fähigkeiten Ihrer Teamkollegen im Auge zu behalten, aber das Schreiben von wartbarem Code bedeutet häufig, keine geheimen Verknüpfungen für Probleme zu verwenden, die häufigere Lösungen haben könnten. Dies ist wichtig, auch wenn Ihre Teamkollegen intelligent sind. Sie möchten nicht, dass es zu lange dauert, bis der Code verstanden wird, oder dass subtile, aber wichtige Nebenwirkungen auftreten, die übersehen werden könnten. Im Allgemeinen ist es am besten, "clevere" Tricks zu vermeiden, wenn es geeignete Alternativen gibt. Sie wissen nie, wer möglicherweise den Code auf der ganzen Linie warten muss - oft erinnern sich ältere Versionen von uns nicht an die Details oder Gründe für diese Tricks.

Wenn Sie feststellen, dass Sie einen cleveren Trick anwenden müssen, befolgen Sie zumindest die nächsten Ratschläge ...

KUSS

Wenn Sie Zweifel haben, halten Sie es einfach . Ob Code einfach ist oder nicht, entspricht nicht unbedingt den Fähigkeiten eines Programmierers, wie Sie vielleicht denken. In der Tat sind einige der brillantesten Lösungen für ein Problem die einfachsten, und einige der komplizierteren Lösungen landen bei TheDailyWTF . Wenn Sie Ihren Code einfach und präzise halten, können Sie einige der intelligenteren, aber möglicherweise kontraintuitiven Entscheidungen leichter nachvollziehen.

Corion
quelle
10
Das Problem ist, dass Sprachfunktionen als "clevere Tricks" angesehen werden, auch wenn ich glaube, dass dies eindeutig nicht der Fall ist. Schon mal eine Schließung gesehen? Schon mal ein IIFE gesehen? Schon mal eine Funktionsreferenz als Rückruf übergeben? Das sind Sprachfunktionen, die jeder erfahrene JS-Entwickler kennt. Dennoch sind sie "clevere Tricks" für weniger erfahrene JS-Entwickler.
Florian Margaine
1
@FlorianMargaine hört sich für mich so an, als müssten Sie an der Änderung der Terminologie arbeiten, dh: Dies sind keine "cleveren Tricks", sondern fortgeschrittenere Funktionen der Sprache ... 1 impliziert, dass Ihr Code nicht ohne weiteres verstanden wird / eine schlechte Sache ist. 2 impliziert die Möglichkeit, "meine" Codierungsfähigkeiten zu erlernen und zu verbessern (wie man andere dazu bringt, ihre Terminologie zu ändern? Kommentare, Fragen anzuregen, Codeartikel auszutauschen, in denen erklärt wird, wie diese Funktionen nützlich sind usw.)
Andrew Bickerton
3
Wenn es Ihre Kopfschmerzen lindert, kann ein Teil der Frustration sein, dass Javascript als Sprache ... keinen Sinn ergibt. Es macht Sinn für uns, die Leute hier zu posten, weil wir das schon lange gemacht haben. Aber egal, wie wir die Sprache dazu gebracht haben, "gut" zu funktionieren, für das neutrale Auge ergibt das einfach keinen Sinn. Auf einer anderen Anmerkung; Sie können leider den Wert der Einstellung erfahrener Entwickler oder vorzugsweise von Entwicklern in jeder Sprache mit einer hohen Bereitschaft zum Erlernen neuer Paradigmen unter Beweis stellen .
Katana314
1
@FlorianMargaine Ich arbeite hauptsächlich auch in JavaScript. Ich kenne die Schmerzen, die du fühlst. Ich habe versucht, Teamkollegen zu erziehen. Die Crockford JavaScript-Videos ( 1 , 2 ) helfen. Ich glaube nicht, dass diese Dinge, die Sie aufgelistet haben, unter "clevere" Tricks fallen - Ihre Teamkollegen sollten sie lernen -, aber einige der Dinge, die Sie mit diesen Sprachfunktionen tun, könnten die schlechte Art von "clevere" sein. Wie Sie Ihr Unternehmen davon überzeugen können, erfahrene
Entwickler
2
Kommentare sind nicht immer gut. Ich habe vor einiger Zeit "Clean Code" gelesen und einige Punkte, die er zu Kommentaren anführt, sind ausgezeichnet. Wenn Sie der Meinung sind, dass Sie Kommentare schreiben müssen, um Ihren Code zu erklären, besteht eine gute Chance, dass der Code falsch geschrieben ist. Wenn der Code aussagekräftiger war, ist ein Kommentar überflüssig. Wenn Sie einen Kommentar schreiben möchten, überlegen Sie kurz, ob Refactoring eine bessere Option sein könnte. Wenn Code aussagekräftig ist, ist es nicht erforderlich, seinen Zweck zu erläutern. Außerdem können Kommentare irreführend oder einfach falsch sein, wenn der Code geändert wird, die Kommentare jedoch nicht entsprechend aktualisiert werden.
Pappa
34

Es scheint eine große Abneigung gegen das Erstellen einer Funktion in JS zu geben. Diese Abneigung führt dazu, dass die Leute versuchen, klug zu sein und lächerliche Tricks anzuwenden, um die Dinge in einer Zeile zu halten, wie es ein Funktionsaufruf gewesen wäre. Natürlich dient der Funktionsname in einem Aufruf auch als zusätzliche Dokumentation. Wir können einem kniffligen Ausdruck keinen Kommentar hinzufügen, da dies den Sinn des Ausdrucks zunichte machen würde. Wir nennen ihn einfach "js idiom" und plötzlich ist es verständlich.

Javascript ist extrem zugänglich, die meisten Leute essen keine Spezifikationen zum Frühstück wie wir. Sie werden also nie verstehen, was die versteckten Annahmen und Randfälle einer Redewendung sind.

x = x || 'default_value';

Der Durchschnittsmensch wird dies entweder nicht verstehen oder hat auswendig gelernt, dass dies das Idiom für den Standardwert ist. Beides ist schädlich, in der Tat ist letzteres sogar noch schädlicher. Er wird die Annahmen und Randfälle hier nicht verstehen. Es wird ihm egal sein, die Spezifikation zu lesen und sie jemals zu verstehen.

Wenn ich in diesem Code aussehen sehe ich „ , wenn es nulloder undefinedsetzen sie dann auf diesen Standardwert. Obwohl es auch implizit behandeln wird +0, -0, NaN, false, und ""als nicht geeignete Werte. Ich muß sich erinnern , dass 3 Monate ab jetzt , wenn die Bedürfnisse Ich werde es wahrscheinlich vergessen. "

Die implizite Annahme führt höchstwahrscheinlich zu einem Fehler in der Zukunft. Wenn Ihre Codebasis voller solcher Tricks ist, besteht keine Möglichkeit, dass Sie sie alle im Kopf behalten, wenn Sie darüber nachdenken, wie sich eine Änderung auswirkt. Und das ist für den "JS Pro", der durchschnittliche Joe hätte den Fehler selbst dann geschrieben, wenn die Anforderungen von Anfang an einen falschen Wert akzeptieren würden.

Ihr neues Snippet verfügt über eine vertraute Syntax, weist jedoch das oben genannte Problem auf.

Sie können mit gehen:

function f(x) {
    x = valueOrDefault(x, "default_value");
}

Jetzt können Sie die Edge Cases mit einer sehr komplexen Logik behandeln, und der Client-Code sieht immer noch gut aus und ist lesbar.


Wie unterscheidet man nun fortgeschrittene Sprachfunktionen wie das Übergeben einer Funktion als Argument oder einen cleveren Trick wie || "default"?

Clevere Tricks funktionieren immer unter einigen versteckten Annahmen, die ignoriert werden konnten, als der Code ursprünglich erstellt wurde. Ich werde niemals ein IIFE an etwas anderes anpassen müssen, weil sich eine Anforderung geändert hat, es wird immer da sein. Vielleicht im Jahr 2020, wenn ich aktuelle Module verwenden kann, aber ja.

| 0oder die ~~numfür Bodenbeläge verwendete Frachtkultversion setzt positive und 32-Bit-Ganzzahlgrenzen mit Vorzeichen voraus.

|| "default" Es wird davon ausgegangen, dass alle falschen Werte mit dem Fehlen eines Arguments identisch sind.

Und so weiter.

Esailija
quelle
4
Sie konzentrieren sich auf ein Beispiel. Was ist mit Sachen wie IIFEs, Verschlüssen, Funktionsreferenzen? Das ist der Hauptpunkt meiner Frage.
Florian Margaine
1
@FlorianMargaine Glaubst du, ich habe das im zweiten Teil nicht gut genug angesprochen?
Esailija
3
Nun, es sagt nichts darüber aus, wie ich mit der Situation umgehen soll, in der ich einfach "erweiterte Sprachfunktionen" verwende, die Teamkollegen als "cleverer Trick" missverstehen.
Florian Margaine
Ich mag diese Antwort +1, ich denke, sie vermisst einen großen Teil der Frage, aber sie geht ausführlich auf andere Teile und Szenarien ein und erklärt die Probleme anderer Teamentwickler, die solche Konzepte selbstständig aufgreifen, ohne die Anleitung durch das Lesen Ihrer Code.
Benjamin Gruenbaum
@FlorianMargaine du meinst, wie man tatsächlich mit einer Situation in der Praxis an deinem Arbeitsplatz umgeht, in der du IIFE verwendest und jemand denkt, dass das ein cleverer Trick ist? Wie ich bereits erklärt habe, funktioniert eine Speicherung wie "Variablen sind nicht global" für den Durchschnitt einwandfrei, da es keine versteckten Annahmen gibt.
Esailija
23

Sie sollten nicht senken Sie Ihre Programmierkenntnisse, aber Sie müssen eventuell neu einstellen , wie Sie Code schreiben. Das Ziel ist fast vor allem, Ihren Code den Leuten klar zu machen, die ihn lesen und pflegen müssen.

Leider kann es ein bisschen ein Urteil sein, ob ein bestimmter Stil "clever" oder nur fortgeschritten ist. Der Code in der Frage ist ein gutes Beispiel dafür - Ihre Lösung ist nicht unbedingt besser als die andere. Einige werden argumentieren, dass es so ist, andere werden anderer Meinung sein. Wählen Sie den Stil aus, mit dem sich das Team als Ganzes am wohlsten fühlt, da beide Lösungen praktisch die gleiche Laufzeitleistung aufweisen (lesen Sie: Der Benutzer wird den Unterschied nie bemerken).

In einigen Fällen müssen Sie ihnen bessere Codierungsmethoden beibringen, in anderen Fällen müssen Sie jedoch Kompromisse eingehen, um die Übersichtlichkeit zu gewährleisten.

Bryan Oakley
quelle
+1. Kein konkretes Beispiel des OP ist empirisch besser als das andere, sie sind lediglich verschieden.
Ross Patterson
sehr nette antwort @ bryan-oakley. Prost
Andy K
7

Dies kann bereits in einer anderen Antwort gesagt worden sein, aber ich möchte diese Frage meine eigenen Bestellungen beantworten.

Allgemeine Richtlinie

Wenn Sie in einem Team arbeiten, sind Sie nicht die Zielgruppe eines Codeteils. Ihr Publikum ist die Entwickler Ihres Teams. Schreiben Sie keinen Code, den sie nicht ohne Grund verstehen können.

  1. Sofern es keine spezifischen Nachteile gibt, sollte der gesamte Code nach einem bestimmten Muster oder einer bestimmten Richtlinie geschrieben werden, die eine einfache Wartung durch die Entwickler ermöglichen, die ihn warten werden. (Eine Einschränkung: Schlechten Mustern zu folgen, nur weil sie sich gerade in der Codebasis befinden, ist eine schreckliche Übung.)
  2. Wenn Sie einen guten Grund finden, eine sprachspezifische Sprache zu verwenden, die für die Zielgruppe nicht leicht lesbar ist, fügen Sie einen Kommentar hinzu. Wenn Sie feststellen, dass Sie jeder anderen Zeile einen Kommentar hinzufügen müssen, möchten Sie möglicherweise Ihren Code neu schreiben, damit er für Ihre Zielgruppe besser lesbar ist. Ich finde es nicht wertvoll, idiomatisch zu sein, um idiomatisch zu sein.

Spezifisches Beispiel

Wir haben eine große Anzahl von Perl-Skripten in unserer Codebasis. Wir verwenden Perl normalerweise nur für sehr einfache Operationen und der Großteil des Codes wird von Java-Entwicklern geschrieben, daher ist es ähnlich wie Java gestaltet. Wir haben eine Reihe von Perl-Skripten und ein Framework, das von einem 'Perl-Guru' geschrieben wurde, der unsere Firma inzwischen verlassen hat. Dieser Code enthält viele der undurchsichtigen Perl-Redewendungen, und keiner unserer Entwickler, einschließlich ich, kann diesen Perl-Code ohne größeren Aufwand lesen. Wir verfluchen ihn oft dafür. :)

user606723
quelle
5

Wenn Sie guten Code schreiben, aber glauben, dass Ihre derzeitigen oder zukünftigen Kollegen Schwierigkeiten haben könnten, ihm zu folgen, sollten Sie einen kurzen Kommentar hinzufügen, um ihn zu erläutern.

Auf diese Weise können Sie ihnen etwas beibringen, ohne ihre individuelle Intelligenz zu beleidigen oder jemanden in einer Gruppendiskussion in Verlegenheit zu bringen.

DavidR
quelle
3

Ich würde Ihr Beispiel nicht als Trick bezeichnen, sondern nur als idiomatisch. Ob Sie es verwenden sollten, hängt IMHO nicht so sehr von der aktuellen Ebene Ihres Teams ab, aber ob (zumindest einige) Ihre Teamkollegen bereit sind, einige neue Redewendungen zu lernen. Natürlich sollten Sie dieses Thema mit ihnen diskutieren und diesen Stil nicht erzwingen. Und Sie sollten sie nicht bitten, jeden Tag 5 neue Dinge oder "Tricks" zu lernen. Aber ehrlich gesagt, wenn Sie nur Teamkollegen haben, die nicht bereit sind, etwas Neues zu lernen, sollten Sie überlegen, zu einem anderen Team zu wechseln, auch wenn es so einfach und klein ist wie diese Redewendung.

Doc Brown
quelle
3

Das Lesen dieser Frage und der nachfolgenden Antworten und Diskussionen scheint zwei Punkte zu geben. Die erste: Ist es in Ordnung, erweiterte Sprachfunktionen zu verwenden? Zweitens: Wie kann ich das tun, ohne so zu wirken, als würde ich angeben?

Im ersten Fall ist es sinnvoll, Verbesserungen und erweiterte Funktionen zu verwenden. Beispiel: In C # müssen Sie keine Linq- oder Lambda-Ausdrücke verwenden, aber die meisten Leute tun dies, weil der Code dadurch übersichtlicher und verständlicher wird, sobald Sie tatsächlich wissen, was er tut. Auf den ersten Blick sieht es nur seltsam aus.

Die Menschen gewöhnen sich an Muster und in vielen Fällen verwenden sie die festgelegte Art, Dinge zu tun, nur um die Arbeit zu erledigen. Ich bin daran genauso schuld wie der nächste Mann. Wir haben alle Fristen. In mancher Hinsicht sind Sie schuld daran, neue Ideen und Denkweisen einzuführen! Dies kommt zum zweiten Punkt, und hier werden Sie wahrscheinlich auf den größten Widerstand stoßen.

Für die Person, die die Website nutzt, ist es egal, welcher Stil verwendet wird. Geht es schnell? Wenn Sie also keinen Leistungsvorteil erzielen, gibt es in dem von Ihnen angegebenen Beispiel keinen richtigen oder falschen Weg. Verbessert Ihr Weg die Lesbarkeit von Code oder nicht? Das kann passieren, wenn sich Ihre Kollegen daran gewöhnt haben.

Wie führen Sie diese Änderungen ein? Versuchen Sie, mit Ihren Kollegen in dieser Richtung zu diskutieren: Wussten Sie, dass diese Funktion auf diese Weise geschrieben werden kann? Codeüberprüfungen und Paarprogrammierungen können gute Zeiten sein, um eine gegenseitige Befruchtung von Ideen zu ermöglichen. Es ist schwierig für mich, die Vorgehensweise festzulegen, da ich die Umgebung, in der Sie arbeiten, nicht kenne. Ich finde, dass einige Programmierer sehr defensiv und veränderungsresistent sein können. Auch hier habe ich mich schuldig gemacht. Der beste Weg, mit solchen Programmierern zu arbeiten, besteht darin, etwas Zeit damit zu verbringen, zu lernen, was sie zum Ticken bringt, ihren Hintergrund zu erlernen und dann ihre Stile und Erfahrungen mit denen zu vergleichen und ihnen gegenüberzustellen. Es braucht Zeit, aber es ist gut investierte Zeit. Wenn möglich, versuchen Sie sie zu ermutigen.

Daniel Hollinrake
quelle
Wenn Sie der Meinung sind, dass es für Sie einfacher ist, zu erläutern, was Sie in einer C # -Umgebung meinen, hätte OP zweifellos nichts dagegen - ich würde es auf jeden Fall nicht tun. Bei dieser Frage geht es nicht um JavaScript :) Stellen Sie sich vor, Sie geben optionale Parameter oder Lambdas in Ihrem Code auf, weil andere Teamentwickler das nicht verstehen - würden Sie das tun? Ich denke, Sie haben hier einige interessante Ideen, aber wenn Sie aufhören, sich Gedanken über die spezifische Sprache zu machen, können Sie sie überzeugender schreiben :)
Benjamin Gruenbaum
1
Ich arbeite hauptsächlich mit C #, das war also das Beispiel, das mir am ehesten in den Sinn kam. Sie machen einen ausgezeichneten Punkt in Bezug darauf, ob ich nützliche Sprachfunktionen aufgeben würde, nur weil andere sich dessen nicht bewusst sind. Die Antwort müsste nein sein, aber das Schwierige ist natürlich, andere zu veranlassen, die Vorteile dieses neuen Weges zu erkennen, der Florians Hauptproblem zu sein scheint.
Daniel Hollinrake
3

Arbeiten Sie dann nicht für die Royal McBee Computer Corp., denn wer sagt, dass Sie nicht der unerfahrene Programmierer sind?

Sicher, es ist großartig, Code zu schreiben, der kurz und knapp ist und in einer Javascript-Umgebung nützlich sein kann (na ja, bis jemand einen js-Compiler zum Herunterladen für Browser erstellt, aber das ist eine andere Geschichte).

Was jedoch wichtig ist, ist die Fähigkeit Ihres Codes, die wenigen Minuten zu überstehen, die Sie zum Schreiben benötigt haben. Sicher, es ist schnell und einfach, und Sie können es herausnehmen und weitermachen, aber wenn Sie Jahre später noch einmal darauf zurückkommen müssen, denken Sie vielleicht: "Welche Muppet hat das geschrieben?" Und stellen fest, dass Sie es waren! (Ich habe das getan, sicher haben es auch die meisten Leute. Ich beschuldige die zu aggressiven Fristen, ehrlich).

Dies ist die einzige wichtige Sache, die Sie bedenken sollten. Wenn ich also ja sagen würde, gehen Sie zu diesem bestimmten Operator, wenn es funktioniert und klar ist, und zu Ihren "unerfahrenen" Entwicklern (obwohl das für sie abfällig ist, weiß ich viel von unerfahrenen Entwicklern, die alle Operatoren und Tricks kennen, da sie verschiedene Webseiten-Tutorials und -Referenzen auswendig gelernt haben, schreiben sie den schlechtesten Code, obwohl sie jeden kleinen Trick kennen.

Wie auch immer, wenn Sie die Geschichte von Mel lesen könnten , würden Sie erkennen, dass die Tricks nicht das Beste sind, um Code einzufügen, obwohl Mel ein echter Programmierer erster Ordnung war. Dies zahlt sich für jedes Argument aus, bei dem jemand sagt, dass er guten Code schreiben kann und jeder andere mehr lernen muss, um Schritt zu halten.

gbjbaanb
quelle
1
Ich kenne keinen einzigen Programmierer, der nicht zu seinem Code zurückgekehrt ist (seit einem Monat!) Und "wer zum Teufel hat das geschrieben" hat. Wir entwickeln uns immer stilvoll weiter (zumindest versuchen wir es). In diesem speziellen Fall schreibt OP Standardcode, nicht WTFish-Code. OP diskutiert nicht das Schreiben von "cleverem" Code oder "kürzer, um cool zu sein" Code, es ist idiomatisch JS.
Benjamin Gruenbaum
2

Nun, für den Anfang sieht das für mich nach grundlegendem JS aus.

Aber im Allgemeinen sollten Sie keine cleveren Hacks verwenden, um zu paraphrasieren: "Das Debuggen ist doppelt so schwer wie das Programmieren. Wenn Sie Code so clever wie möglich schreiben, können Sie ihn per Definition nicht debuggen."

Das bedeutet nicht, dass Sie Code vermeiden sollten, nur weil andere ihn nicht verstehen. Sie sollten den Code so klar und konsistent wie möglich schreiben. Aber Ihre Kriterien für Klarheit sollten lauten: "Verstehe ich das in der ersten Lesung eines Jahres?", Nicht: "Kann es jemand verstehen?".

Schreiben Sie klar und deutlich, dass Sie keine Schwierigkeiten haben zu verstehen, und lassen Sie andere daran arbeiten, ihre Fähigkeiten zu verbessern - behindern Sie sich nicht, um anderen einige hypothetische Schwierigkeiten zu ersparen.

jmoreno
quelle
1

Ich würde mit meinen Teamkollegen besprechen, welche Codierungsstandards wir haben möchten, da es hauptsächlich darum geht, wie etwas, das auf Dutzende von Wegen getan werden kann, für unsere Codebasis getan werden kann. Wenn es einen Konsens gibt, wäre das mein erster Versuch, eine Antwort zu finden.

Wenn dies nicht der Fall ist, würde ich wahrscheinlich überlegen, welche Art von vorgeschlagenem Standard sinnvoll ist, und damit beginnen, ihn in die Praxis umzusetzen, sobald ich ihn mit dem Management und einigen Mitarbeitern geklärt habe. Die Idee dabei ist, sicherzustellen, dass das Management mit dieser Idee einverstanden ist und dass ich nicht einfach mein eigenes Ding mache und dann alle anderen dazu zwinge, es zu übernehmen.

Ich würde dies eher als die Frage betrachten, welche Art von Standards und Praktiken Ihr Team hat und nicht nur die Fähigkeitsstufe, da es viele Möglichkeiten gibt, Code zu bewerten. Wie gut andere es behaupten können, ist eines dieser Kriterien.

JB King
quelle
1

Das Problem ist, dass Sie eine gute Lesbarkeit der Quelle wünschen, die Lesbarkeit jedoch in den Augen des Betrachters liegt.

Ich würde vorschlagen, dass wir bessere Werkzeuge brauchen, um dieses Problem zu lösen. Nichts komplexes, wohlgemerkt, wir haben die Technologie, um es seit mehr als 50 Jahren zu tun. Nehmen Sie einen Parser in den Editor auf und lassen Sie den Editor die Quelle in Form von Sexps speichern (ja, genau wie lisp). Anschließend wird die Quelle gelesen und vom Editor in die syntaktische und typografische Form (Leerzeichen, Tabulatoren, Kommas) zerlegt, die der Benutzer bevorzugt.

Auf diese Weise können Sie schreiben und lesen, x = x || 10und andere Programmierer lesen es als

if (0 == x) { x = 10;}

Emacs hat alle Teile, um das einfach zu machen.

Pascal Bourguignon
quelle
1
In diesem Fall wissen wir, wer der Betrachter ist. Sie sind unsere Mitarbeiter. Ich denke, dieser Ausdruck wird normalerweise verwendet, wenn Sie Ihr Publikum nicht kennen.
Dcaswell
-1

Warum nicht die Qualität des Teams verbessern, anstatt den Code herunterzuspielen? Training, Coaching, Schulung und verbesserte Einstellungspraktiken können viel zur kontinuierlichen Verbesserung beitragen.
Statismus, Code-Fäulnis, die Ablehnung von Verbesserungen und Innovationen, weil jemand nicht an der Selbstverbesserung arbeiten will, verursachen nur Probleme auf der ganzen Linie und eher früher als später.

In dem speziellen Fall, den Sie zeigen, versuchen Sie natürlich nur klug zu sein und absichtlich verschleierten Code zu schreiben, was niemals eine gute Idee ist. Code sollte in erster Linie lesbar, leicht verständlich und nicht geschrieben sein, um zu zeigen, wie klug Sie darin sind, etwas mit den geringstmöglichen Anweisungen zu erstellen zum).

jwenting
quelle
5
In diesem Fall bin ich nicht schlau. Ich schreibe idiomatischen Code für jeden erfahrenen Entwickler. Verstehst du, warum ich jetzt kämpfe? :)
Florian Margaine
3
Ihr erster Absatz ist genau richtig, aber -1, weil Ihr zweiter Absatz weit von der Marke entfernt ist. Es ist falsch zu sagen, dass dieses Beispiel ein bewusster Versuch ist, klug zu sein. Es ist eigentlich sehr klar und vor allem ein idiomatischer Stil, dem sich viele gute Javascript-Entwickler einig sind. Es ist nicht die einzige Ausdrucksweise in Javascript für Standardfunktionsparameter, aber es ist eine übliche.
Ben Lee