„Exzellenz entsteht nie durch starke Absichten, aufrichtiges Engagement und kluges Handeln.“ Nicht der Zufall wird Ihr Schicksal bestimmen.“ – Aristoteles Wir alle wollen die Besten auf unserem Gebiet sein. Die Besten, aber nur wenige investieren die Zeit und Mühe, um das zu erreichen, was sie wollen. Es ist schwer, ein guter Mensch zu sein, wie es in jedem Beruf der Fall ist.
Es ist sehr schwierig, die Exzellenz eines JavaScript-Entwicklers zu bewerten.
Was zeichnet einen guten JavaScript-Entwickler aus?
Wir können auf der Grundlage vieler Kriterien Urteile fällen.
Codequalität, pünktliche Lieferung und zeitnahe Lösung von Tickets (Hinweis: Tickets ähneln Problemen in Github, siehe hier) sind mehrere Standards, auf die verwiesen werden kann. Dazu gehört natürlich auch, anderen Teammitgliedern bei der Lösung von Tickets zu helfen. Ich denke, dass die oben genannten Punkte keine genauen Messungen liefern. Ein ganzes Projekt um zwei Monate verzögern, um schönen Code zu schreiben, einfach weil man etwas umgestalten möchte, das in keiner Weise hilft. Wir alle wissen, dass das Schließen eines Tickets nichts bedeutet.
Es sind viele sich ändernde Faktoren zu berücksichtigen. Wenn ich 10 verschiedene Programmierer fragen würde, was ihrer Meinung nach einen guten Entwickler ausmacht, würde ich sicher 10 verschiedene Antworten bekommen.
Ich glaube, Sie denken jetzt auch über seine Definition nach.
Ich hatte eine Weile mit dieser Definition zu kämpfen, also beschloss ich, es herauszufinden.
Konzentrieren Sie sich auf die Arbeit
Ich möchte einige Dinge finden, die alle Entwickler tun, und dann kann ich die Entwicklerleistung danach klassifizieren, wie sie es tun.
Es ist zu einfach, eine hervorragende Bewertung einer Branche nur auf einer Sache zu basieren, aber ich werde es trotzdem versuchen.
Jetzt können Sie es mit Vorsicht genießen.
Ich werde versuchen zu beweisen, dass ich eine gute Wahl getroffen habe. Das ist etwas, was alle Entwickler tun, und es unterscheidet die guten von den mittelmäßigen.
Alle Entwickler schreiben von Zeit zu Zeit beschissenen Code.
Seien wir ehrlich, Sie und ich schreiben von Zeit zu Zeit Code, der so trashig und beschämend ist, dass wir nie wollen, dass ihn jemand sieht.
Wir alle haben Gründe, gelegentlich beschissenen Code zu schreiben. Ich werde mich nicht mit der Diskussion darüber befassen, was die triftigen Gründe sind, denn jeder von uns hat seine eigenen triftigen Gründe. Bevor wir einige Codierungsgräueltaten zeigen, schauen wir uns an, warum wir beschissenen Code schreiben. Dann können wir vermeiden, stecken zu bleiben und mit Code-Gerüchen zu kämpfen.
Häufige Gründe für das Schreiben von Junk-Code
1. Zeitrausch
„Zeitmangel“ ist derzeit der häufigste Grund für das Schreiben von Junk-Code. Schuld daran können Verpflichtungen gegenüber Kunden, knappe Zeitpläne und ausstehende Neuerscheinungen sein.
2. Große Schmerzen haben
Die vorhandene Codebasis ist so Müll, dass Sie nicht einmal hart arbeiten möchten, um guten Code zu schreiben. Sie wissen, dass es keine Möglichkeit gibt, diese Müllcodebasis zu retten, die irgendwann zusammenbrechen wird, egal was Sie tun.
3. „Ich beende einfach die Aufgabe und gehe“
Als Entwickler arbeiten wir manchmal in verschiedenen Projektgruppen. Wenn Sie nach dem Schreiben der letzten Codezeilen zu einem neuen Projekt wechseln müssen, ist dies keine große Sache, die sich auf andere auswirkt.
Wisse, dass deine Zeit an diesem Projekt zu Ende geht und niemand mehr deinen Code überprüfen wird. Sie übernehmen also einfach einen Commit, pushen und verlassen sich dann auf Unit-Tests, um sicherzustellen, dass es keine Probleme gibt.
Sehen Sie sich die Wahrheit an
Wir alle schreiben von Zeit zu Zeit Mistcode. Bedeutet das, dass wir alle schlechte Entwickler sind?
Natürlich nicht. Nur weil jeder von Zeit zu Zeit schlechten Code schreibt, bedeutet das allein noch nichts.
Allerdings habe ich im Laufe der Jahre nach und nach eine überraschende Wahrheit über Entwickler entdeckt.
Wie wir uns nach dem Schreiben von Junk-Code verhalten, ist ein grundlegender Test unserer Entwicklerqualifikationen.
Es ist ein bisschen unglaublich, aber es ist wahr. Das Bewusstsein, dass Sie Müllcode schreiben, und die Maßnahmen, die Sie ergreifen, um zu verhindern, dass so etwas in Zukunft noch einmal passiert, spiegeln wider, wie Sie Code schreiben und wie Sie beim Schreiben von Code im Allgemeinen vorgehen.
Wie viel hat Junk-Code mit der Bewertung der Exzellenz von Entwicklern zu tun? Es hat viel damit zu tun.
Nehmen wir Ron als Beispiel. Ron hat heute schlechten Code geschrieben und war darüber unzufrieden. Aufgrund einer fiesen fünfstufigen Vererbungskette des Backbone-Modells konnte Ron keine einzige Codezeile ändern, ohne alles kaputt zu machen.
Ron hat einen superschrottigen Code geschrieben, um dieses Problem zu umgehen. Alle waren zufrieden, weil Ron den Code pünktlich geliefert hat. Außer Ron selbst.
Er erzählte dem Teamchef, was passiert ist. Gemeinsam überlegten sie, wie sie das Problem lösen könnten. Sie machten deutlich, dass es die beste Lösung sei, die Vererbungskette zu durchbrechen und sie in horizontale Kompositionsmodule aufzuteilen.
Ron bat dann seinen Chef, ihm Zeit zu geben, den Wiederaufbauplan umzusetzen, den er und sein Chef gerade besprochen hatten.
Roger hat heute auch schrecklichen Code geschrieben. Er erzählte seinen Entwicklerkollegen, dass er einen unglaublichen Hack verwendet hatte, um eine seltsame fünfstufige Vererbungskette des Backbone-Modells zu umgehen. Er war bereit, die gesamte Struktur zu umrunden und pünktlich zu liefern.
Roger selbst war sehr zufrieden und hatte das Gefühl, dass es keinen Bedarf für weitere Verbesserungen gab.
Vier Arten von JavaScript-Entwicklern
Sie können Programmierer in vier Kategorien einteilen, von schlecht bis ausgezeichnet, basierend auf ihrer Einstellung zum Schreiben von Müllcode.
Sagen Sie mir, dass Sie nicht alle vier Entwicklertypen gleichzeitig kennengelernt haben.
Barney – schlechter JavaScript-Entwickler
Barney ist es egal, dass er beschissenen Code schreibt. Ihm geht es nur darum, die Arbeit pünktlich zu erledigen; nichts anderes zählt. Wenn der Code normal ausgeführt wird, gibt es kein Problem.
Der von Barney geschriebene Müllcode behindert manchmal den Fortschritt des gesamten Projekts. Bei der Arbeit am Code kommt es immer zu vielen Problemen, die den Fortschritt des gesamten Projekts beeinträchtigen. Barney hingegen glaubt nicht, dass er etwas Neues lernen muss.
Er weiß bereits alles, was er über JavaScript wissen muss, um seine Arbeit zu erledigen.
Bill – ein gewöhnlicher JavaScript-Entwickler
Bill ist sich nicht bewusst, dass er Müllcode schreibt. Er befolgte die Teamvereinbarung und die Flusenregeln und war der Meinung, dass an dem, was er tat, nichts falsch war. Er nahm sich jedoch nicht die Zeit, die gesamte Projektstruktur und das Zusammenspiel der verschiedenen Komponenten miteinander zu verstehen.
Das Endergebnis ist leider Chaos.
Bill hat niemanden konsultiert, bevor er wichtige Designentscheidungen getroffen hat. Er macht, was er will. Er las drei Blogbeiträge von vor einem Jahr, die ihn bei seiner Entscheidung beeinflussten.
Ich sage oft, dass es sich anfühlt, als würde man Bills Kodex befolgen, als würde man einen Krieg führen, ein einziger falscher Schritt und alles fliegt einem um die Ohren.
Roger – ein guter JavaScript-Entwickler
Wir haben die Art von Roger bereits erwähnt. Seien Sie sich völlig darüber im Klaren, dass Sie Müllcode schreiben. Er weiß, wie der Code aussehen würde, wenn er ihn gut schreiben wollte. Er klopfte sich selbst auf die Schulter und schrieb diesen Mist weiter.
Rogers Hauptproblem besteht darin, dass er nicht versucht hat, einige Änderungen vorzunehmen. Er hat getan, was von ihm verlangt wurde, und er hat es gut gemacht. Aber er würde die Dinge lieber so lassen, wie sie sind, als sich die Zeit und Mühe zu nehmen, sie zu ändern.
Ron – ein ausgezeichneter JavaScript-Entwickler
Ron ist ein ausgezeichneter Programmierer, aber gelegentlich muss er trotzdem Müllcode schreiben.
Was Ron von anderen unterscheidet, ist, dass er, wenn er diesen Müllcode schreibt, ernsthaft darüber nachdenkt, wie er verhindern kann, dass sich diese Situation wiederholt, weder für sich selbst noch für andere. Ron wird herausfinden, welche Art von Refactoring erforderlich ist und welche technischen Lösungen geändert oder verbessert werden können.
Basierend auf diesen Erkenntnissen wird Ron dann Maßnahmen ergreifen, um diese Veränderungen voranzutreiben.
Die kalte Realität
Ich muss umkehren. Ich bin hier Roger. Aber ich bin auch Ron. Ich glaube auch, dass ich mehr als einmal zufällig Bill war, ohne es zu wissen. Ich glaube nicht, dass ich wie Barney gelebt habe, aber wer weiß? Wir alle gehen auf dem Weg zu dauerhafter Exzellenz hin und her. Manchmal sind wir gewöhnlich, manchmal sind wir gut oder ausgezeichnet. Ich versuche immer, nicht schlecht zu sein.
Die Rolle, die wir am längsten behalten, bestimmt, was für ein Entwickler wir sind.
Um ehrlich zu sein, ist vom gewöhnlichen Entwickler bis zum guten Entwickler die Anhäufung von mehr Wissen und Erfahrung erforderlich als bei anderen Dingen. Aber um den Sprung vom Guten zum Großartigen zu schaffen, müssen Sie nur eines ändern: Ihre Einstellung.
„Denken Sie daran, bevor Sie gut sein können, müssen Sie schlecht sein, aber bevor Sie schlecht sein können – Art Williams >
Das Obige ist der Unterschied zwischen JavaScript-Entwicklern mit unterschiedlichem Leistungsniveau. Weitere verwandte Inhalte finden Sie auf der chinesischen PHP-Website (www.php.cn)
