Es ist lange her, dass ich einen Artikel über das Programmieren mit einem ständigen Lächeln im Gesicht gelesen habe.

Grug ist wie die meisten von uns kein Entwickler mit großen Köpfen, sondern ein einfacher Höhlenmensch, der Code von anständiger Qualität schreiben und Dinge erledigen möchte.

Grug ist nicht besonders schlau, aber das könnte seine Superkraft sein. Der Text enthält viel Weisheit.

Es hat ein paar Minuten gedauert, bis ich Grugs Ausdrucksweise verstanden habe, aber es lohnt sich!

Lesen Sie den vollständigen Artikel unter grugbrain.dev

Hier sind einige goldene Nuggets von Grug :

Komplexität

Komplexität ist ein Geisterdämon, der durch wohlmeinende, aber letztendlich sehr vereinbare Entwickler und Projektmanager, die keine Angst vor dem Geisterdämon der Komplexität haben oder überhaupt etwas davon wissen, in die Codebasis eindringt

Nein sagen

Die beste Waffe gegen die Komplexität des Geisterdämons ist das Zauberwort: „Nein“

Nein, Grug baut diese Funktion nicht auf
. Nein, Grug baut diese Abstraktion nicht auf

Beachten Sie, dass dies ein guter technischer Ratschlag, aber ein schlechter Karriereratschlag ist: „Ja“ ist ein Zauberwort für glänzenderen Stein und die Verantwortung für eine große Gruppe von Entwicklern

Traurig, aber wahr: „Ja“ lernen und dann lernen, anderen Groll die Schuld zu geben, wenn man scheitert, ein idealer Karriereratschlag

Faktorisierung Ihres Codes

Berücksichtigen Sie Ihre Bewerbung nicht zu früh!

Entwickler mit großen Köpfen mögen das oft überhaupt nicht und erfinden zu Beginn des Projekts viele Abstraktionen

Grug war versucht, nach der Keule zu greifen und zu schreien: „Großes Gehirn, kein Code pflegen!“ Großer Brainstorming-Vorstoß beim nächsten Architekturausschuss, Hinterlassenscode für Grug-Deal!“

Versuchen Sie stattdessen, den Schaden für Entwickler mit großen Köpfen zu Beginn des Projekts zu begrenzen, indem Sie ihnen Dinge wie ein UML-Diagramm geben (kein beschädigter Code, wahrscheinlich sowieso wegwerfen) oder indem Sie morgen eine funktionierende Demo verlangen

Ein besonders guter Trick in der Arbeitsdemo: Erzwingen Sie, dass Big Brain etwas macht, über das tatsächlich gearbeitet werden kann, und Code, der sich das ansieht, um etwas zu tun. Dies hilft Big Brain, die Realität vor Ort schneller zu erkennen

Chestertons Zaun

Grug versteht, dass alle Programmierer Platoniker auf irgendeiner Ebene Perfektion im Code wünschen. Aber die Gefahr ist da, die Welt ist oft hässlich und grottig und das muss auch der Code sein

Grug sage nicht, dass ich das System nie verbessern werde, das ist ziemlich dumm, aber wir empfehlen, sich zuerst die Zeit zu nehmen, das System zu verstehen, insbesondere bei größeren Systemen. Respektieren Sie den Code, der heute funktioniert, auch wenn er nicht perfekt ist

Werkzeug

Grug-Liebeswerkzeug

Ein guter Debugger, der in glänzenden Steinen Gewicht wert ist, in der Tat sogar noch mehr: Wenn Grug mit einem Fehler konfrontiert wird, tauscht er oft den ganzen glänzenden Stein und vielleicht ein paar Kinder gegen einen guten Debugger ein, und jedenfalls wiegt der Debugger nichts, soweit Grug das beurteilen kann

Grug empfiehlt neuen Programmierern immer, den verfügbaren Debugger gründlich zu erlernen, Funktionen wie bedingte Haltepunkte, Ausdrucksauswertung, Stapelnavigation usw. zu nutzen und neuen Grug oft mehr über Computer als an Universitäten beizubringen!

Typsysteme

Grug sehr ähnliche Typsysteme erleichtern die Programmierung. Für Grug sind die Typsysteme am wertvollsten, wenn Grug den Punkt auf der Tastatur drückt und eine Liste der Dinge auftauchen lässt, die Grug tun kann. Diese 90 % des Werts des Typsystems oder mehr sind zu groß

Es kommt immer das wertvollste Typsystem: Drücken Sie den Punkt und sehen Sie, was Grug kann. Vergessen Sie es nie!

Trennung von Bedenken

Separation of Concern (SoC) ist eine weitere starke Idee, die viele Entwickler beschäftigt

Hier ist Grug viel sauerer als DRY und schreibt tatsächlich einen großhirnigen Aufsatz über alternative Designprinzipien, Locality of Behavior (LoB) und SoC

grug viel lieber Code auf das Ding setzen, das das Ding macht. Wenn du dir jetzt das Ding anschaust, grug, weißt du, was das Ding macht, immer gute Erleichterung!

Protokollierung

Ich bin ein großer Fan der Protokollierung und befürworte viel davon, insbesondere im Cloud-Einsatz. Einige Nicht-Grugs sagen, Holzeinschlag sei teuer und nicht wichtig. Grug verwendet, nicht mehr so ​​zu denken

Grug-Tipps zum Protokollieren sind:

• Alle wichtigen logischen Verzweigungen im Code protokollieren (wenn/für)
• Wenn sich die „Anfrage“ über mehrere Maschinen in der Cloud-Infrastruktur erstreckt, geben Sie die Anfrage-ID in alle ein, damit die Protokolle gruppiert werden können
• Wenn möglich, wird die Protokollebene dynamisch gesteuert, sodass Grug bei Bedarf ein-/ausgeschaltet werden kann. Debug-Probleme (viele!)
• Erstellen Sie nach Möglichkeit eine Protokollebene pro Benutzer, um bestimmte Benutzerprobleme beheben zu können

Der größte Gehirnentwickler hat einmal gesagt:

Vorzeitige Optimierung ist die Wurzel allen Übels

Grug empfiehlt, immer ein konkretes, reales Leistungsprofil zu haben, das spezifische Leistungsprobleme zeigt, bevor mit der Optimierung begonnen wird.

Man weiß nie, um welches eigentliche Problem es sich handeln könnte, es gibt oft Überraschungen! sehr oft!

APIs

API-Entwickler denken zu abstrakt und zu großhirnig

Normalerweise kümmert sich Grug nicht allzu sehr um die Details der API: Ich möchte eine Datei schreiben oder eine Sortierliste oder was auch immer, ich möchte nur write() oder sort() oder was auch immer aufrufen

Aber Big-Brain-API-Entwickler sagen:

nicht so schnell, grug! Ist diese Datei zum Schreiben geöffnet? Haben Sie einen Komparator für diese Art definiert?

Grug findet wieder eine selbstbeherrschende Hand, die nach der Keule greift

Das interessiert mich im Moment nicht, ich will nur die Datei sortieren und schreiben, Herr großer Kopf!

Front-End-Entwicklung

Einige Nicht-Grugs sagen, wenn sie mit der Webentwicklung konfrontiert werden:

Ich weiß, ich werde meine Front-End- und Back-End-Codebasis aufteilen und eine heiße neue SPA-Bibliothek verwenden, die über HTTP mit einem GraphQL-JSON-API-Back-End kommuniziert (was lustig ist, weil ich keinen Hypertext übertrage).

Jetzt haben Sie zwei Verstecke komplexer Dämonengeister

grug ist nicht wie große, komplexe Front-End-Bibliotheken, die jeder nutzt

Grug macht HTML und Hyperscript zu vermeiden

Halten Sie die Komplexität niedrig, einfaches HTML, vermeiden Sie viel Javascript, den natürlichen Äther des Geistkomplexitätsdämons

Vielleicht arbeiten sie für Sie, aber keine Stellenausschreibung, sorry

Reagieren Sie besser auf einen Job und auch auf eine Art Bewerbung, aber Sie werden auch zum Akolythen des Komplexitätsdämons, ob Sie wollen oder nicht, tut mir leid, das ist das Front-End-Leben

Angst, dumm auszusehen

Notiz! Sehr gut, wenn Senior Grug bereit ist, öffentlich zu sagen: „Hmm, das ist zu komplex für Grug“!

Viele Entwickler haben Angst davor, dumm auszusehen (FOLD), Grug auch einmal FOLD, aber Grug lernen, darüber hinwegzukommen: Sehr wichtig, Senior Grug sagt: „Das ist zu kompliziert und verwirrend für mich.“

Dies macht es für jüngere Schüler in Ordnung, etwas zu Komplexes einzugestehen und es dann nicht so gut zu verstehen, was oft der Fall ist! FOLD Hauptquelle der Komplexität, dämonische Macht über Entwickler, insbesondere über junge Grugs!

Hochstapler-Syndrom

Beachten Sie, dass sich viele solcher Betrüger in der Entwicklung befinden

Nun macht Grug Software mit viel Arbeit und mäßigem Open-Source-Erfolg, und doch hat Grug selbst oft keine Ahnung, was er tun soll! sehr oft! Grug hat immer noch Angst, einen Fehler zu machen, jeden Code zu brechen und andere Grugs zu enttäuschen, Betrüger!

Vielleicht liegt es in der Natur der Programmierung, dass die meisten sich als Betrüger fühlen und mit dem Besten einverstanden sind: Kein Betrüger, wenn jeder Betrüger ist

Jeder junge Ungläubige, der bis hierher gelesen hat, kommt wahrscheinlich in der Programmkarriere gut zurecht, auch wenn Frustration und Sorgen immer da sind, sorry