In letzter Zeit haben sich die Anforderungen an die Einhaltung von Vorschriften immer mehr in die technische Seite der Dinge eingeschlichen. In letzter Zeit kommen immer wieder Produkte auf den Tisch, bei denen es um die Umsetzung dieser und jener Compliance-Anforderungen geht. Oder sie führen eine Art Compliance-Fragebogen aus. Meiner Meinung nach geht es bei der Einhaltung der Vorschriften vor allem um die Speicherung von Benutzerdaten. Der Zugriff muss standardisiert werden, und dann können die Benutzer allmählich anfangen, ihre eigenen Daten zu kontrollieren. Dann gibt es auch einige personelle und organisatorische Veränderungen, die sich auf die technische Ebene auswirken. Zum Beispiel wurde ein Geschäftsbereich in andere Abteilungen verlagert, und wir haben dann Ressourcen wie Datenbanken mit diesem Geschäftsbereich geteilt. Hier tritt die Kostenfrage in den Vordergrund, d.h. das Geld sollte dort gezählt werden. Es handelt sich zwar um ein Unternehmen, eine Unternehmensgruppe, aber ich habe das Gefühl, dass es an den internen Buchhaltungsmechanismen des Unternehmens liegen könnte, denn diese Kostenfragen sind immer noch schwerwiegender, werden immer argumentieren, was: sie nutzen unsere Datenbank, das Geld ist immer noch auf unserer Seite und so weiter. Manchmal habe ich das Gefühl, dass es sich dabei um internen Verbrauch handelt, nicht um eine Entwicklungsperspektive. Hinzu kommt, dass andere Unternehmen möglicherweise einige gemeinsame Datenbankstrukturen oder Schnittstellen aufgrund von Bedarfsanpassungen ändern müssen, was noch problematischer ist. Denn derzeit erhalten wir keine Anerkennung für die Arbeitsstunden, die sie für diese Dinge aufwenden. Allerdings werden wir jeden Tag von den Leuten dort gehetzt und bombardiert. Es ist noch schwieriger, wenn man in der Mitte gefangen ist.
Die Migration des PHP-Gateways, die ich in meinem letzten Wochenbericht erwähnt habe, war in den ersten ein oder zwei Monaten tatsächlich in Arbeit. Tatsächlich wurde er schon vor langer Zeit geschrieben, aber bei der anschließenden Umstellung des Datenverkehrs auf den neuen Dienst traten immer wieder solche und solche Probleme auf. Eine Besonderheit ist, dass in der Testumgebung lange Zeit niemand zu finden war, während in der offiziellen Umgebung immer eine Person zu finden war. Diese Schnittstelle kann plötzlich nicht mehr verwendet werden, die Schnittstelle meldet plötzlich Fehler und so weiter. In diesem Fall, weil das Problem auf der Leitung auftritt, können Sie nur zuerst den Verkehr zurückfahren und dann das Problem analysieren. Nach zwei Durchgängen wird eine Woche vergehen. Manchmal dauert es 4 oder 5 Tage, bis jemand das Problem findet. Ein solcher Prozess dauert sogar noch länger. Der Leiter sagt zwar, dass dies schon lange so gemacht wird, aber die tatsächliche Situation ist so. Obwohl die anschließende spezifische Code-Schreib- und Wartungsarbeit des Dienstes nicht meine Aufgabe ist, aber ich weiß auch, dass ein neuer Dienst, der den bestehenden Dienst vollständig ersetzen soll, einen Prozess haben muss. Denn in Ermangelung von Dokumentation und Testfällen wissen Sie nicht, welche versteckten Mechanismen eine Schnittstelle hat, und es ist nicht ganz klar, ob der von mir geschriebene Code dem Original entspricht. Auf der Implementierungsebene wurden also viele Dinge nicht explizit gemeldet, aber ich war der Meinung, dass das Management auch in der Lage sein sollte, dies zu verstehen. Obwohl der Prozess ziemlich iterativ und schwierig war, wurde das Refactoring dieses Dienstes schließlich in dieser Woche abgeschlossen und der gesamte Datenverkehr wurde auf den neuen Dienst migriert. Das heißt, der Lebenszyklus dieses alten PHP-Gateways ist vorbei.
Ich habe das Hauptgeschäft im Backend-Bereich jetzt fast ein halbes Jahr lang übernommen, und jetzt wird mir klar, dass ich bei meiner ersten Übernahme aufgrund mangelnder Erfahrung immer das Gefühl hatte, dass die Technologie anderer Leute undurchschaubar ist. Nach einer langen Zeit des Kontakts weiß ich jedoch, dass sie so und so viele Unzulänglichkeiten aufweist. Es gibt auch einige Designfehler, die sehr schwerwiegend sind. Zum Beispiel die Verwendung von Redis als Datenbank. Um es ganz offen zu sagen, es gibt keine festgelegte Ablaufzeit für den Cache, so dass die Daten in Redis nicht verloren gehen können. Es gibt auch einige alte Dienste, für die es keine Dokumentation mehr gibt und die schon lange nicht mehr gewartet werden, so dass es im Grunde unmöglich ist, sie genau zu untersuchen. Es gibt jedoch immer ein oder zwei dieser Dienste, auf die noch zugegriffen wird oder die schon lange nicht mehr zugänglich sind, und die Kunden entdecken sie plötzlich in den letzten Tagen und drängen uns, sie zu lösen. Viele Sicherheitsprobleme müssen ebenfalls behoben werden, eine bestimmte Anzahl von API-Konten hat eine hohe Anzahl von Berechtigungen, die angeglichen werden müssen, aber ich weiß nicht, was diese verschiedenen Konten genau tun. Diese Probleme treten einfach täglich auf, und es ist schwer, sie zu vermeiden.
