Komplette Programmierphilosophie | Original, von KI übersetzt

Home 2025.01

Inhaltsverzeichnis

  1. Programmierung
    • Programmierung als kreative Tätigkeit
    • Entwicklung persönlicher Projekte
    • Technologietrends und neugiergetriebenes Lernen
    • Philosophie des Debuggens und Problemlösens
    • Benutzerorientierte Entwicklung
    • Code-Qualität und Einfachheit
    • Integration von KI und Automatisierung
  2. Ein unbegrenzter Ingenieur werden
    • Arbeiten unter Unternehmensbeschränkungen
    • Maximierung interner Ressourcen
    • Werkzeugbau im KI-Zeitalter
    • Veränderung der Denkweise
    • Überwindung wahrgenommener Grenzen
  3. Vorteile der Protokollsammlung
    • Protokollverwaltung in Unternehmensumgebungen
    • Historischer Kontext und Problemlösung
    • Strategien zur Organisierung von Protokolldateien
    • Langfristige Projektwartung
    • Wissensbewahrung und -teilung
    • Automatisierte Methoden zur Protokollsammlung

Programmierung

Ein unbegrenzter Ingenieur werden

Vorteile der Protokollsammlung

Als ich früher als Auftragnehmer für eine Bank arbeitete, nutzten wir eine Multi-Cloud-Anwendungsplattform, um die Microservices zu bedienen. Damals begann ich, Protokolle zu sammeln, als ich im Unternehmen arbeitete.

Einige Jahre sind vergangen, und ich denke immer noch, dass es eine der besten Möglichkeiten ist, mir bei der Arbeit oder Softwareentwicklung zu helfen. Im Laufe der Zeit gibt es in meinem Protokollverzeichnis Hunderte von Protokolldateien.

Ich habe keine spezifischen Unterverzeichnisse oder formale Protokolldateinamen dafür. Manchmal verwende ich einfach den JIRA-Aufgabennamen als Präfix für den Protokolldateinamen oder das Feature. Dann füge ich eine Nummer als Suffix hinzu. Zum Beispiel mutual-fund-1.log, mutual-fund-2.log usw. Das bedeutet, im Mutual-Fund-Microservice habe ich das Protokoll, als ich diesen Microservice ausführte.

Manchmal, wenn ich an Projekten arbeite, die mehrere Regionen bedienen, füge ich das Land als Suffix hinzu, wie mutual-fund-cn-1.log, mutual-fund-sg-1.log. Die Dateinamen der Protokolle sind irgendwie lässig. Denn damals musste ich mich auf Fehlerstapel oder umgebende Funktionsaufrufe konzentrieren.

Die Protokolle der Programme sind wichtig. Jeder weiß das. Aber ich möchte die Bedeutung der Protokollsammlung überbetonen, anstatt sie nur in der Konsole zu betrachten und gehen zu lassen. Du wirst mehr Bequemlichkeit erkennen, wenn das Projekt läuft. Du hast mehr Zeit, um frühere Protokolle zu finden. Vielleicht musst du wissen, ob ein ähnlicher Datenbank-Gespeicherter-Prozedur-Aufruf schon einmal passiert ist. Vielleicht musst du wissen, ob derselbe Fehler schon einmal aufgetreten ist. Vielleicht musst du dich erinnern, wie du das Problem das letzte Mal behoben hast.

In einem großen Projekt oder Dutzenden von Microservices gibt es Unmengen von Details. Und die Fehler, Ausnahmen oder Probleme passieren immer wieder. Das Protokoll ist wie das Laufdokument eines Programms. Und sie werden automatisch vom Programm generiert, ohne menschliche Eingabe. Und für Entwickler sind diese Protokolle lesbar. Wenn du also eine neue Aufgabe beginnst oder einen neuen Bug behebst, hast du Hunderte von Protokollen zur Hand, um diesen neuen Bug zu beheben. Du bist nicht allein.

Warum sammeln wir sie? Weil Dinge oder Wissen leicht vergessen werden.

Es gab menschlichen Fortschritt, als Papier erfunden wurde. Und als Computer erfunden wurden, gab es eine weitere Stufe der menschlichen Zivilisation. Notizen auf Papier zu halten ist wie Protokolle in Computern zu sammeln.

Nicht nur für Menschen, sondern auch für KI-Chatbots, LLM-Tools werden diese Protokolle immer wichtiger. Die GreptimeDB, eine Datenbank für die einheitliche Sammlung und Analyse von Beobachtungsdaten (Metriken, Protokolle und Spuren), die 2022 gegründet wurde, ist kein Zufall.

Warum habe ich das nicht früher gemacht? Nachdem ich als Auftragnehmer für große Banken gearbeitet hatte, musste ich mehr zusammenarbeiten und an größeren Projekten arbeiten. Davor arbeitete ich die meiste Zeit in Startups oder während meiner Startup-Phase allein. Als ich früher bei LeanCloud arbeitete, arbeitete ich etwa die Hälfte der Zeit an der IM-App LeanChat.

Und als ich in die formellere Unternehmenswelt eintrat, war die Entwicklung der Projekte anders als bei meinen persönlichen Projekten oder Startup-Projekten. Sie haben SIT-, UAT-Testumgebungen. Und die Produktionsumgebung ist oft nur für bestimmte kleine Teamkollegen geöffnet. Die Protokolle von ihnen zu bekommen und Probleme zu beheben, wird lang und etwas mühsam. Und das Ausführen eines Projekts dauert Zeit, und die Jenkins-Pipeline braucht oft eine halbe Stunde.

Daher kann ich das Programm nicht wie im Flug testen. Ich kann kein Deployment durchführen, indem ich einfach einen Befehl auf meinem persönlichen Computer eingebe und Code auf den Server hochlade, um ihn auszuführen.

Daher lässt es mich irgendwie Protokolle sammeln, um mehr Kontext für die Aufgabenbearbeitung zu haben. Wir sollten Probleme besser beim ersten Versuch beheben. Wir sollten unsere Korrekturen besser in wenigen Versuchen überprüfen. Wir können nicht leicht Protokolle des Programms bekommen, das in einer Cloud oder auf dem Server des Unternehmens läuft, also kopieren wir sie besser und speichern sie auf dem lokalen Laptop, um Analysen durchzuführen.

Und jetzt sammle ich auch für meine persönlichen Projekte Protokolle. Es ist eine Gewohnheit geworden. Nachdem ich einige Jahre in großen Unternehmen gearbeitet habe, habe ich irgendwie mehr Geduld oder Strategie, um meine Projekte größer und länger zu machen. Daher weiß ich, dass ich diese Protokolle mit der Zeit brauche.

Manche mögen sagen, dass du nur eleganten Code und ein funktionierendes Projekt brauchst. Du musst keine Protokolle oder Fehlerstapel sammeln. Das ist in Ordnung. Wenn wir einen Bug oder ein neues Feature haben, können wir das Programm ausführen, um die aktuellen Protokolle zu bekommen. Wir brauchen die Protokolle aus dem Entwicklungsprozess nicht. Sie sind wie detaillierte Aufzeichnungen wissenschaftlicher Experimente. Auf den ersten Blick scheint es okay. Aber langfristig, wenn du eines Tages wieder daran arbeiten willst oder es teilen oder andere übernehmen lassen willst, mag es nicht gut sein.

Ich denke, es könnte hier gute Möglichkeiten geben. Warum ermutigen wir in Unternehmen nicht jeden Entwickler, seine gesammelten Protokolle zu teilen? In Open-Source-Projekten sollten wir das auch haben. Wir finden die Protokolle anderer nicht ansprechend, weil wir sie nicht kennen. Wir verlieren den Kontext beim Speichern dieser Protokolle. Und darin scheinen Unmengen von unwichtigen oder trivialen Nachrichten zu sein.

Aber der Aufwand, Protokolle zu sammeln, ist nur trivial. Es ist nur Kopieren und Einfügen jedes Mal, wenn wir einige Protokolle sehen, besonders die Fehlerprotokolle. Und wie wäre es, wenn wir es automatisiert machen? Es ist eine gute Idee, die Protokolle jedes Mal, wenn wir ein Projekt ausführen, in einem Verzeichnis aufzuzeichnen, wie diese Spring-Boot-Projekte.

Die Welt wird immer digitaler, daher ist das Sammeln von Protokollen digitaler Programme wie das Sammeln von Büchern in einer physischen Welt.

Back Donate