Dies ist der erste meiner regelmäßigen Rückblicke auf technische Probleme, die mir bei der Arbeit begegnet sind. Dieser Rückblick ist also hauptsächlich eine Zusammenfassung der Erfahrungen, die ich im Laufe der Zeit gemacht habe, um einen Vorsprung für künftige technische Rückblicke zu erhalten.
Ich arbeite jetzt seit fast sechs Monaten in dem Unternehmen und habe vor kurzem von der clientseitigen Entwicklung zur Backend-Entwicklung gewechselt. Das ist das, was ich mir wünsche, aber eigentlich nicht das, worum ich gebeten habe. Denn ich persönlich habe das Gefühl, dass Backend-Entwickler in der aktuellen Karriereplanung der chinesischen Tech-Industrie etwas mehr Möglichkeiten haben und viel mehr mit Problemen konfrontiert werden. Auch die Client-Seite ist vielversprechend. Mein erstes ausgereifteres Open-Source-Projekt, GpgFrontend, ist ein clientseitiges Projekt. Ich habe viel Zeit darin investiert und eine Reihe von Problemen gelöst. Vor allem Kompilierungsprobleme, Probleme mit der Plattformkompatibilität und Stabilitätsprobleme. Die Tiefe seiner Erforschung, die Schwierigkeit des Problems, sind nicht gering. Ich habe das Gefühl, dass der Grund für die Aufteilung der Client- und Backend-Entwicklung in eine hohe und eine niedrige Stufe darin liegt, dass das Herz nicht zur Ruhe kommt und immer daran denkt, aufzusteigen. Darüber hinaus für die Ausübung der Technologie ursprünglich keine Rolle Client-, Front-End-oder Back-End, die technischen Ideen hinter ihnen sind im Wesentlichen gemeinsam, aber die aktuelle Besetzung ist zu wichtig, aber statt der beruflichen Arbeitsteilung, um die Technologie klar zu teilen. Ich denke, das ist nicht gut, so dass, obwohl ich derzeit ein Back-End-Entwickler, aber ich darf nicht denken, dass ich nur ein Back-End-Entwickler, andere Technologien nicht sehen, nicht lernen, ihr eigenes Denken Box auf.
Nun, da sich die Position zum Backend-Entwickler geändert hat, weiß ich nicht, was ich stattdessen tun soll. Backend-Entwicklung, ich erinnere mich gerade daran, dass das früheste Backend-Projekt, das ich selbst geschrieben habe, ein Astronomieforum Stelescope war, das in Nodejs geschrieben wurde, als ich 15 Jahre alt war. Es verwendete das Express-Framework, das damals sehr beliebt war. Ich erinnere mich noch gut daran, wie ich zum ersten Mal mit technischen Konzepten wie MongoDB, dem Speichern von Zuständen für die An- und Abmeldung, asynchronen Callbacks usw. bekannt gemacht wurde. Am meisten erinnere ich mich an die asynchronen Rückrufe, bei denen ich lange brauchte, um sie zu verstehen. Es dauerte lange, bis ich es verstand, weil ich nicht einmal die grundlegenden Konzepte von Prozessen und Threads kannte, geschweige denn asynchrone Rückrufe und Closures. Damals wurde im Internet noch über die Vor- und Nachteile von Nodejs und PHP gestritten, Nodejs eignet sich für welche Szenarien, und dann sind asynchrone Rückrufe und Multiprozessparallelität besser oder schlechter. Damals erinnerte ich mich daran, dass asynchrone Rückrufe nicht blockiert werden können. Wenn Sie auf eine blockierende Operation stoßen, verwenden Sie eine nicht blockierende API, die sofort zur blockierenden Operation zurückkehren kann, um sie zu bearbeiten, während der Hauptthread weiterhin mit dem nachfolgenden Code arbeiten kann. Wenn die blockierende Operation beendet ist, wird der Hauptthread benachrichtigt, die Callback-Funktion auszuführen, um die Ergebnisse der blockierenden Operation zu verarbeiten.
Anschließend lernte ich auch die Python-Backend-Entwicklung kennen und schrieb ein einfaches System zur Verwaltung der Anwesenheit von Schülern (SP ). Hier wurde ich mit der Idee von MVC vertraut gemacht, was ich als Model, View und Controller verstehe. Das ist eine wichtige Idee, denn zu dieser Zeit war das Konzept des Frontends noch nicht sehr klar, die Trennung von Frontend und Backend war noch nicht die gängige Idee. Damals war der Server für die dynamische Seitengenerierung zuständig, und der Controller wurde durch die Anfrage veranlasst, zu antworten. Controller führten Berechnungen auf der Grundlage des Modells durch und renderten das Modell schließlich über eine Template Engine in eine Seite, die dann an den Browser des Benutzers zurückgegeben wurde. Es ist einfach ein Prozess. Ich erinnere mich, dass wir damals eine Menge Vorlagen auf der Serverseite definiert haben, Vorlagen, um einige Stellen auszuhöhlen, um später Daten zu speichern. Oder Sie definieren eine kleine Kartensteuerung, fügen die for-Anweisung ein und verwenden dann die Template-Engine, um eine Vielzahl von Karten zu erzeugen. Zu diesem Zeitpunkt muss ich als Backend-Entwickler jeden Aspekt berücksichtigen, einschließlich der Schönheit der Seite, der Datensicherheit, der schnellen Reaktion und so weiter.
Im nächsten Jahr kam ich dann mit dem Spring-Framework in Berührung, insbesondere mit SpringBoot. Diesmal verstand ich nur die relationale Datenbank. Es stellte sich heraus, dass mein Verständnis von relationalen Datenbanken nur darin bestand, sie zu installieren und zu konfigurieren. Ich erinnere mich noch gut daran, als ich mit der Idee der Trennung von Front-End und Back-End in Berührung kam, die ich für eine gute Sache halte. Ich nahm die Idee auf und diskutierte sie mit Herrn Wang, indem ich sagte, dass es am besten wäre, die Trennung von Front-End und Back-End für unser System zur Verwaltung der gesamten Bildung zu verwenden. Herr Wang war sehr aufgeschlossen, hat viel mit mir gesprochen und meinem Vorschlag zugestimmt. Die Trennung von Front-End und Back-End bedeutet, wie der Name schon sagt, dass das dynamische Rendering der Seiten auf die Benutzerseite verlagert wird und der Server nur für die Datenverarbeitung und -speicherung zuständig ist. Das fördert die Arbeitsteilung und Entkopplung, obwohl es damals auch viele Zweifel im Internet gab, glaube ich immer noch, dass dies der Trend ist. Damals war ich besessen von einer Art RestfulAPI-Schnittstellenspezifikation und ich dachte, dass wir damit sogar das Schreiben von Projektdokumenten vermeiden könnten. Aber die Realität sieht ganz anders aus. In der Praxis ist es für einige komplexe Fälle schwierig, den Stil von RestfulAPI beizubehalten.
Durch die Beschäftigung mit SpringBoot habe ich eine Menge über das Backend gelernt, und diese ursprünglichen Erfahrungen nutze ich jetzt. Während meines Studiums habe ich eine Menge SpringBoot-Projekte geschrieben. Inzwischen war ich in das Unternehmen eingetreten und hatte herausgefunden, dass der Tech-Stack der Abteilung Java war und das Framework, das für neue Projekte verwendet wurde, SpringBoot war, in umgekehrter Richtung. Obwohl ich gesagt habe, dass ich von Java angewidert bin, weil ich es für aufgebläht und schwerfällig halte, habe ich auch jetzt kein gutes Gefühl, aber das Java-Ökosystem ist in der Tat sehr leistungsfähig, es ist sehr einfach, eine Komponente zu finden, und die Java-Komponenten sind ausgereift, gut gewartet und gut dokumentiert. Java-Technologie-Stack für produktionsorientierte Back-End-Projekte, es ist wirklich eine problemlose, gute, einen Job für den Technologie-Stack zu finden.
Ich arbeite seit einem halben Jahr in dem Unternehmen, wenn man die Praktika mitzählt, ist es sogar schon fast ein Jahr. Im Allgemeinen habe ich mich für den Hintergrund dieses Artikels mit Optimierung, Caching, Threading und diesen Dingen beschäftigt. Ich habe jeden Tag alle Arten von Meldungen analysiert, von denen einige geschäftlicher und einige technischer Natur sind. Bei geschäftlichen Problemen können Sie nur den Hintergrund gut verstehen. Bei technischen Problemen müssen Sie Ihr Wissen erweitern und in Ruhe studieren. So gibt es z.B. bei der Bereitstellung von Containern immer wieder Timeout-Probleme. Ich konnte nicht feststellen, ob es sich dabei um ein Container-Problem oder ein Problem mit einer Hintergrundanwendung handelt. Ich denke jetzt, dass dieses Stück etwas tiefer gehendes Wissen erfordert, wie die Virtualisierung von CPU, Speicher und Netzwerk.
Das war’s für heute, es gibt noch ein paar andere Dinge zu tun.
