Als Entwickler werden Sie viele verrückte, unglaubliche Theorien über die Bedeutung von „Codezeilen“ hören. Glaube keinem einzigen. Codezeilen sind lächerliche Metriken. In sehr seltenen Fällen sagt sie etwas, normalerweise nichts. Die Verwendung von Codezeilen zum Treffen von Entscheidungen entspricht der Bewertung der Buchqualität anhand der Seitenzahl.

Einige mögen sagen, je weniger Codezeilen in einer Anwendung, desto einfacher ist das Lesen. Dies ist nur teilweise richtig. Hier sind meine Metriken für lesbaren Code:

• Der Code muss konsistent sein
  
• Der Code sollte informativ sein.
  
• Der Code sollte gut dokumentiert sein.
  
• Der Code sollte stabile moderne Funktionen verwenden.
  
• Code muss nicht zu kompliziert sein
  
• Der Code sollte nicht ineffizient sein (schreiben Sie nicht absichtlich langsamen Code)

Wenn die Reduzierung der Anzahl der Codezeilen einer dieser Metriken widerspricht, wird dies zu einem Problem. In der Praxis stört es fast immer und ist daher fast immer ein Problem. Wenn Sie jedoch die oben genannten Kriterien erfüllen möchten, hat Ihr Code die ideale Anzahl von Zeilen - und Sie müssen sie nicht zählen .

Sprachen sind nicht unbedingt "gut" oder "schlecht"


Außer PHP natürlich (ein Witz). Quelle

Ich sehe Leute, die die ganze Zeit solche Dinge sagen:

• C ist wegen der Leistung besser als X.
  
• Python ist aus Gründen der Kürze besser als X.
  
• Haskell ist wegen Aliens besser als X.

Die Idee, dass Sprachvergleiche auf einen Satz reduziert werden können, ist fast beleidigend. Dies sind Sprachen, keine Pokémon.

Versteh mich nicht falsch, es gibt definitiv Unterschiede zwischen den Sprachen. Es gibt einfach praktisch keine „nutzlosen“ Sprachen (obwohl es viele veraltete / tote gibt). Jede Sprache hat ihre eigenen Kompromisse. In dieser Hinsicht sehen sie aus wie eine Toolbox. Ein Schraubenzieher kann das, was ein Hammer nicht kann, aber wird jemand sagen, dass ein Schraubenzieher besser ist als ein Hammer?

(Offensichtlich ist der Hammer besser)

Bevor ich über Sprachbewertung spreche, möchte ich etwas klarstellen. Die Wahl einer Sprache ist sehr selten wichtig . Natürlich können einige Dinge in einigen Sprachen nicht erledigt werden. Wenn Sie für ein Frontend schreiben, haben Sie keine Wahl. Es gibt bestimmte Kontexte, in denen Leistung wichtig ist und die X-Sprache einfach nicht geeignet ist, aber solche Situationen sind ziemlich selten. Im Allgemeinen ist die Sprachauswahl eines der am wenigsten wichtigen Themen für ein Projekt.

Hier sind die Hauptaspekte in der Reihenfolge, die meiner Meinung nach die Wahl der Sprache beeinflussen sollten (ohne spezifische Metriken):

• Dichte der verfügbaren Online-Ressourcen (StackOverflow-Dichte)
  
• Entwicklungsgeschwindigkeit
  
• Fehlerveranlagung
  
• Die Qualität und Abdeckung eines Paket-Ökosystems (ja, npm, wenn es um Qualität geht)
  
• Leistung (mehr Punkte)
  
• Beschäftigungsmöglichkeit (Sorry, COBOL)

Einige wichtige Faktoren, die außerhalb Ihres Einflusses liegen. Wenn Sie auf dem Gebiet der Datenwissenschaft arbeiten, müssen Sie wirklich Python, R oder Scala (möglicherweise Java) verwenden. Wenn dies ein Hobbyprojekt ist, verwenden Sie, was Sie mögen. Ich habe nur eine unbestreitbare Regel. Ich lehne die Verwendung von Sprachen ab, wenn die meisten möglichen Probleme mit dieser Sprache noch nicht in StackOverflow behoben sind. Es ist nicht so, dass ich sie nicht lösen kann, es ist einfach nicht die Zeit wert.

Das Lesen des Codes eines anderen ist schwierig

Das Lesen des Codes eines anderen ist schwierig. Robert K. Martin spricht darüber in Pure Code: „Tatsächlich beträgt das Verhältnis von Zeit zum Lesen und Schreiben von Code viel mehr als 10 zu 1. Wir lesen ständig den alten Code, wenn wir versuchen, einen neuen zu schreiben. ... [Deshalb] vereinfacht das, was das Lesen vereinfacht, auch das Schreiben. "

Lange Zeit dachte ich, ich sei nur schwach darin, den Code eines anderen zu lesen. Mit der Zeit wurde mir klar, dass fast jeder Programmierer jeden Tag mit diesem Problem konfrontiert ist. Das Lesen des Codes eines anderen ist wie das Lesen eines Textes in einer Fremdsprache. Auch wenn Sie mit der Auswahl der Programmiersprache des Autors des Codes vertraut sind, müssen Sie sich an verschiedene Stile und Architekturoptionen anpassen. Es wird auch davon ausgegangen, dass der Autor konsistenten und zuverlässigen Code geschrieben hat, der möglicherweise wahr ist oder nicht. Das ist wirklich schwer. Es gibt ein paar Dinge, die mir sehr geholfen haben.

Eine Überprüfung des Codes einer anderen Person verbessert Ihre Fähigkeiten erheblich. In den letzten zwei Jahren habe ich einige Überprüfungen für die Poolanfragen auf Github durchgeführt. Mit jedem neuen fühle ich mich ein bisschen sicherer, wenn ich den Code eines anderen lese. GitHub-Pool-Anfragen sind aus folgenden Gründen besonders nützlich:

• Hier können Sie jederzeit eine Überprüfung durchführen. Finden Sie einfach ein Open Source-Projekt, zu dem Sie beitragen möchten.
  
• Lesen in einem begrenzten Kontext (einzelne Funktion oder Fehler).
  
• Es erfordert Liebe zum Detail, damit Sie jede Zeile schätzen.

Die zweite Technik, mit der der Code eines anderen gelesen werden kann, ist etwas einzigartiger. Dies ist eine Technik, die ich erfunden habe und die wirklich die Zeit reduziert hat, die ich brauche, um mich in der Codebasis eines anderen wohl zu fühlen. Nachdem ich mir den Codestil angesehen habe, den ich lesen möchte, öffne ich zuerst vi und beginne, Code im selben Stil zu schreiben. Wenn Sie Code in einem neuen Stil schreiben, verbessert dies auch Ihre Lesefähigkeiten. Der Stil wird weniger fremd, wenn Sie ihn selbst erlebt haben. Selbst wenn ich mir nur ein zufälliges Projekt auf Github ansehe, wende ich diese Technik schnell an. Probieren Sie es selbst aus.

Sie werden niemals "perfekten" Code schreiben

Ich hatte vier Jahre lang alleine programmiert, bevor ich anfing, in einem Team zu arbeiten. Die meiste Zeit habe ich einfach angenommen, dass jeder Programmierer in der Branche perfekten Code geschrieben hat. Ich entschied, dass es nur eine Frage der Zeit und Mühe war, bevor ich auch den „perfekten“ Code schrieb.

Das ist etwas, worüber ich mir vorher große Sorgen gemacht habe. Sobald ich mich dem Team anschloss, wurde schnell klar, dass niemand „perfekten“ Code schrieb. Aber der im System enthaltene Code war fast immer "perfekt". Auf welche Weise? Antwort: Codeüberprüfung.

Ich arbeite mit einem Team von wirklich brillanten Ingenieuren. Dies sind einige der kompetentesten und selbstbewusstesten Programmierer, die Sie für Geld kaufen können. Jedes Mitglied unseres Teams (einschließlich ich) wird eine echte Panikattacke auslösen, wenn jemand jemals anbietet, den Code ohne Überprüfung festzuschreiben. Selbst wenn Sie denken, dass Sie der nächste Bill Gates sind, werden Sie definitiv Fehler machen. Ich spreche nicht einmal über logische Fehler, ich spreche über Tippfehler, vermisste Zeichen. Dass dein Gehirn es einfach nicht bemerkt. Wofür ein anderes Paar Augen ist.

Versuchen Sie, mit anderen Menschen zusammenzuarbeiten, die auf Details achten und bereit sind, Ihre Arbeit zu kritisieren. Kritik zu hören ist zunächst schwierig, aber es ist der einzige konsequente Weg, um die Situation zu verbessern. Geben Sie Ihr Bestes, um während der Codeüberprüfung keine defensive Position einzunehmen, und nehmen Sie niemals persönlich Kommentare entgegen. Du bist nicht dein Code.

Wenn der Autor in einer Codeüberprüfung eine Auswahl getroffen hat, mit der ich nicht vertraut bin, werde ich sofort googeln, wenn seine Auswahl von der allgemeinen Meinung abweicht. Es ist nicht so, dass die Meinung der Bevölkerung immer richtig ist, nur die Meinung der Bevölkerung ist die Standardwahl. Wenn sich jemand entschieden hat, die beliebte Wahl nicht zu akzeptieren, ist das in Ordnung. Ich möchte nur wissen, dass dies gerechtfertigt ist. Bei der Überprüfung des Codes ist es sehr wichtig, dass Sie die Gründe für die getroffenen Entscheidungen verstehen. Wenn man das gleiche Problem aus der Sicht eines Anfängers betrachtet , kann man oft Dinge bemerken, auf die eine Person niemals geachtet hätte.

Die Arbeit eines Programmierers bedeutet nicht 8 Stunden Programmieren pro Tag

Dies ist eine sehr häufige Frage, aber die Leute geben niemals eine klare Antwort. Wie viel gibt der durchschnittliche Entwickler oder „exzellente“ Entwickler jeden Tag für das Schreiben von Code aus?

Sehr wenige Codes mehr als vier Stunden am Tag

Diejenigen, die damit nicht einverstanden sind, sind entweder Ausnahmen von der Regel oder arbeiten für Unternehmen, die sie zu stark ausnutzen. Das Programmieren ist eine geistig anstrengende, intensive Aufgabe. Es ist völlig unvernünftig zu erwarten, dass jemand den Code 8 Stunden am Tag, fünf Tage die Woche schreibt. Es gibt Zeiten, in denen Sie Termine einhalten oder pro Sitzung etwas mehr tun müssen, aber es gibt nur wenige davon und sie sind selten. Wenn ich "selten" sage, meine ich fast nie. Vermeiden Sie Workflows, die Sie missbrauchen, und machen Sie Überstunden aufgrund schlechter Planung / Personalmangels.

Für das Protokoll ist selbst das Unternehmen selbst nicht rentabel, wenn Sie 8 Stunden am Tag aktiv programmieren. Ihr Chef mag denken, dass dies so ist, aber es ist kurzsichtig und er ignoriert die langfristigen Konsequenzen, da dies die Produktivität und die psychische Gesundheit beeinträchtigt.

Aus Gründen der Klarheit schlage ich nicht vor, dass Sie nur vier Stunden am Tag arbeiten. Die restlichen vier Stunden verbringen Sie normalerweise am besten mit:

• Forschung, sowohl arbeitsbezogen als auch nicht arbeitsbezogen
  
• Diskussion Ihrer Arbeit mit Kollegen
  
• Helfen Sie Kollegen, die Probleme mit ihrer eigenen Arbeit haben
  
• Zukünftige Arbeitsplanung
  
• Codeprüfung
  
• Treffen

Ich empfehle außerdem dringend, tagsüber regelmäßig Pausen einzulegen und Sport zu treiben (zumindest nicht lange). Die Vorteile von Bewegung zur Bekämpfung von geistiger Müdigkeit sind gut dokumentiert. Ich persönlich fand, dass Bewegung besonders hilfreich ist, wenn es Probleme mit der Konzentration gibt.

Dies sind einige Dinge, die ich an der Universität anstelle einer reinen Theorie lernen möchte. Während des Schreibens habe ich über eine Menge anderer Nuancen nachgedacht, aber dies ist ein Thema für einen separaten Artikel!