Ich möchte mit Ihnen die Geschichte eines guten Lebens und des langen, langsamen und schmerzhaften Todes eines einst großen Immobilienportals teilen. Was nicht bereit war, sich zu ändern und plötzliche Bewegungen zu machen, um sich an einen sich ändernden Markt anzupassen. Ein Produkt, das in 10 Jahren von TOP-10 nach unten gegangen ist. Dies ist eine Geschichte über die Bedeutung des Threads, der Entwickler mit ihrem Verständnis und ihrem süßen Verstand und Manager / Direktoren / Manager mit ihrem Ansatz für das Projektmanagement verbindet.
Starten Sie
Ich bin 2014 zu diesem Job gekommen, einem einfachen Junior .net. PN (im Folgenden als Immobilienportal bezeichnet) war ein Aggregator von Immobilien, auf dem sich neben der Datenbank mit Ankündigungen ein qualitativ hochwertiger thematischer Nachrichtenbereich befand. Nachrichten, Artikel, Gesetze und viele verschiedene Materialien zu Immobilien. Eine große Abteilung cooler Journalisten schrieb sehr coole Artikel, deren Interesse bei den Nutzern sehr groß war.
Auf der Website selbst konnten Anzeigen geschaltet werden, die Nutzer (Privatverkäufer, Immobilienagenturen) anzogen. Alle Einnahmen wurden durch die in diesem Bereich übliche Werbeplatzierung von Textgrafikblöcken (TGB) von Entwicklern erzielt, die für ihre neuen Gebäude und Wohngebäude werben.
In seiner Blütezeit (2008 - 2012) hatte die Website einen Traffic von über 1.000.000 Besuchern pro Monat. Und er gab eine gute Konvertierung für Werbetreibende. Dies waren hervorragende Indikatoren, da PN nur für Moskau und St. Petersburg arbeitete. Das Personal bestand aus 2 Programmierern und vielen Journalisten und Redakteuren. Tatsächlich wurde die gesamte Wartung, Unterstützung und Verfeinerung des PN von nur 2 Mitarbeitern durchgeführt (Wie viele Personen ursprünglich die PN-Historie entworfen und entwickelt haben, ist still).
Hier endet der positive Teil der Geschichte.Herbst
Nach der ersten Welle der Krise gab es auf dem Gelände Verkehrsprobleme, die sehr schwerwiegend waren. Er fing gerade an zu fallen. Der Markt begann sich ziemlich schnell zu verändern. Konkurrenten begannen zu zerquetschen, weil Während sich unser PN auf seinen Lorbeeren ausruhte und sich nirgendwo entwickelte, machten andere ihre Produkte moderner und erfüllten die Erwartungen der Benutzer.
Darüber hinaus mochten Suchmaschinen unsere Website immer weniger, was übrigens praktisch ohne jegliche Art von CEO war. Ja, es gab einige Vorlagen für h1, Titel, Beschreibung, ein wenig Nachverknüpfung und im Allgemeinen ist das alles (nach dem Beginn des Herbstes und bis zum Ende begann der Leiter des Klosters einen CEO-Kampf, den wir seit fast 5 Jahren führen).
Mit der zweiten Welle der Krise im Jahr 2014 fiel die Leistung unter 300.000 Besucher pro Monat. Um diese Zeit bekam ich einen Job.
Hier beginnt mein technischer Teil der Geschichte .
Eintauchen
Die ersten 2 Jahre habe ich als Junior Developer gearbeitet. Er hat alles getan, was sie mir gegeben haben. Ich musste viel von Grund auf lernen. Ich hatte jedoch Glück mit meinem Entwicklungsleiter. Er war etwas mehr als 40 Jahre alt, ein Programmierer der alten Schule, der viel wusste und wusste wie. Wahrscheinlich war sein Haupt-Credo - es funktioniert und ist gut (ich bin ihm sehr dankbar, weil ich viel Wissen und verschiedene Entwicklungsansätze übernommen habe).
Unser Technologie-Stack war wie folgt:
MS SQL Server 2012 + ASP.NET MVC 3 . Die Basis behielt alles in sich. Sogar Fotos in binärer Form für 3 Satzgrößen (groß, groß, klein).
Das Backend enthielt mehrere Module:
- Montag vor Ort
- Allgemeiner Administrationsbereich
- SEO admin
- Roboterparser KLADR
- XML-Feed-Importroboter
Die ganze Zeit habe ich nur Aufgaben erledigt, damit der Code funktioniert und es keine Fehler gab. Vor allem, ohne sich mit Weiterentwicklung zu beschäftigen. Aber die Zeit ist gekommen und es ist notwendig geworden.
Im zweiten Arbeitsjahr verließ mein Manager das Projekt. Und ich wurde mit diesem alten Koloss konfrontiert, in dem 3% meines Codes gewaltsam waren.
Es war wilder Stress . Der CEO fragte mich alles und manchmal hatte ich keine Ahnung, was und wie es funktionierte. Natürlich hat mich das Leben dazu gebracht und nach und nach habe ich mich mit allen Prozessen befasst und festgestellt, dass dieser Ansatz „funktioniert - gut“ nichts für mich ist. Zu dieser Zeit las ich viele Designmaterialien und wurde auf dem Gebiet der populären Technologien und Frameworks ausgebildet. Ich fuhr von der Arbeit nach Hause und dachte darüber nach, was und wie ich morgen tun würde. Und als ich zur Arbeit fuhr, dachte ich darüber nach, ob das, was ich gestern entschieden hatte, richtig war. Ich wollte verstehen, wie man alles richtig und bequem macht. Um keine Krücken herstellen zu müssen, den Code zu duplizieren, alles live zu testen, alles manuell bereitzustellen und gute Ideen aufgrund einiger Designfehler in der Vergangenheit abzulehnen.
Zu diesem Zeitpunkt hatten wir viel im Bereich SEO getan und Aufgaben zur Verbesserung der Benutzeroberfläche aufgegeben. Der Verkehr ging jedoch immer weiter zurück. Und irgendwann wurde das Projekt eingefroren. Ich begann mich nur mit der Unterstützung und Korrektur von Fehlern zu befassen ... Also klang es offiziell.
Tatsächlich fing ich an, das System von fast 0 komplett neu zu schreiben. Ich musste es heimlich aus dem Handbuch machen. Immerhin haben sie uns nie Zeit gegeben. Sie sagten immer, wir brauchen schneller, schneller. Dass wir dahinter stehen. Und Sie müssen ein wettbewerbsfähiges Produkt in 4 Händen herstellen und besser als die anderen. Wenn ich also sage, dass ich vorhabe, alles zu wiederholen, dann verstehen Sie selbst, welche Antwort ich hören würde.
Imaginärer Aufstieg
Also krempelte ich die Ärmel hoch und begann zu begreifen. Ich habe mich für die klassische dreistufige Architektur entschieden.
Das .Net Core + SQL + Mongo-Backend, das Frontend ist Bootstrap + JQuery + KnockoutJS .
Organisierte eine Datenschicht. Schnittstellen, Abstraktionen, Repositories sind in Ordnung. Die Ebene arbeitete an gespeicherten Prozeduren (zum Glück begann ich SQL ziemlich gut zu verstehen). Für das Mapping habe ich Dapper gewählt. Es ist einfach und unkompliziert. InMemoryCache zugunsten von Redis abgelehnt, um den Cache auf einen separaten Server zu bringen. Als nächstes kam die Ebene der Geschäftslogik. Trotzdem Schnittstellen, Dienste, DI. Die Grundlage erschien also in Form von Datenschicht (gespeicherte Prozeduren + Dapper + Redis) und Logikschicht. Es dauerte ungefähr 3 Monate.
Und hier gelang es mir nach fast einem Jahr Arbeit, einen Assistenten für mich zu finden, der darauf bestand, dass es viele Aufgaben gab (und es gab viele davon). Zusammen ging alles viel schneller und besser und vor allem noch rationaler.
- Zunächst haben wir eine API für Fotos entwickelt . Es war ein einfaches WebApi, das auf Anfrage das Bild der gewünschten Qualität und Größe von der Festplatte lieferte. Wir sind auf SSD umgestiegen und haben die Bilddatenbank als Albtraum vergessen. Es ist schwer zu beschreiben, wie viel schneller die durchschnittliche Seite der Site geladen wurde, nachdem ein separater Pool dafür zugewiesen wurde.
- Wir haben KLADRA zugunsten von FIAS aufgegeben. Sie haben einen qualitativ hochwertigen Service zum Parsen von Daten von FIAS in unsere Datenbank unter Berücksichtigung unserer Funktionen geschrieben. Sie schraubten ihm einen Dienst für Geokodierungshäuser zu. Alles funktionierte fast wie eine Uhr. Nur gelegentlich gab es Fehler, die mit doppelten Orten oder Straßen in der FIASA-Datenbank verbunden waren.
- Dann haben sie lange Zeit ein neues persönliches Konto geschrieben und es von der Website aus geteilt. Es wurde lange Zeit so konzipiert und geplant, dass es benutzerfreundlich war. Sowie schnell und funktionell. Sie haben die Zahlung an ihn vermasselt und dann die Schecks fiskalisiert (ja, wir konnten es uns nicht leisten, vorgefertigte integrierte Lösungen zu verwenden). Insgesamt machte ein guter Benutzer-Service. Und sie waren mit ihm zufrieden.
- Schließlich kamen wir zum Roboter, um XML-Feeds zu importieren . Ein praktischer Validator und eine gute Protokollierung für Kunden. Der neue Dienst erwies sich als so optimiert, dass, wenn der alte (mit EF) etwa 6 bis 8 Stunden arbeitete, der neue die gleiche Datenmenge in 2-3 Stunden verarbeitete.
- Immerhin haben sie eine Domain mit Dokumentation für alles, was ist, erstellt. Sie legten alle Punkte für Benutzer und Kunden des Portals fest und beschrieben auch einen Teil der Dokumentation, der für Entwickler nützlich sein wird. Und das ist wirklich wichtig!
- Der letzte Schritt war die Optimierung der Basis . Wir haben es komplett überarbeitet. Wir haben alles Unnötige ausgeräumt. Sie erreichten eine Beschleunigung der Suchgeschwindigkeit von 4-5 Sekunden auf ~ 300 ms . Sie erstellten Indizes, schrieben komplexe Abfragen, verwendeten Hinweise und erstellten sogar Partitionen von statistischen Tabellen.
Leider gelang es den Händen nicht, auf die Website selbst zu gelangen. Weil Fast alle Aufgaben mit der Website bezogen sich auf SEO, was eine angemessene Zeit in Anspruch nahm. Neue Seiten, neue Sammlungen, neue Regeln. Mehr, mehr, mehr Seiten. Ich musste ständig etwas in der Site-Engine bearbeiten, was es mir nicht ermöglichte, es gleichzeitig auf die erstellte Basis zu übertragen.
Hier endet die technische Geschichte und der traurige Epilog beginnt.
Es lohnt sich, mit der Tatsache zu beginnen, dass der CEO der Site nicht mit der IT-Sphäre verbunden war. Daher wurden viele Entscheidungen von ihnen falsch und individuell getroffen. Sehr oft kamen die Diskussionen zum Stillstand Unsere neuen Ideen wurden nicht akzeptiert, weil
"Das ist nicht nötig, sage ich Ihnen als Immobilienexperte."
oder
"Also niemand schaut, das ist eine niederfrequente Abfrage, da bin ich mir sicher."
Und nach einiger Zeit, als er selbst dazu kam, wurden ihnen unsere Ideen mit einem Anspruch angeboten, warum wir es vorher nicht gesagt hatten, oder mit aufrichtiger Überraschung
"Das konnte ich nicht sagen, das ist absurd"
Wir konnten keinen Konsens erzielen, wodurch wir (Entwickler) einfach minderwertig waren. Und sie taten wie gewünscht. Der Schmerz des Programmierers - niemandem nutzlose „Funktionen“ zu machen.
Ich möchte erwähnen, dass die Finanzen immer Probleme hatten.
Es gab keine Investitionen, außer in SEO . Sogar 2 Programmierer zu behalten war teuer. Es war offensichtlich unmöglich, mit den neuen Portalen der TOP-10 mit einem solchen Finanzierungs- und Managementniveau zu konkurrieren.
Als Ergebnis haben wir eine Plattform für ein Immobilienaggregatorportal. Skalierbar, erweiterbar, schnell und technisch für jede Katastrophe gerüstet. Mit großem Potenzial. Guter Code, minimale Krücken und wenige Engpässe.
Dies ergab jedoch kein positives Ergebnis. Zum Zeitpunkt meines letzten Arbeitstages schwankte der Portalverkehr trotz des Vorhandenseins von 4 Millionen eindeutigen Seiten in Suchmaschinen um 1.400 eindeutige Seiten pro Tag. Und das scheint mir der Tod zu sein.
PS: Von der ganzen Geschichte konnte ich persönlich eine Hauptschlussfolgerung ziehen. Sie können aus Sicht des Entwicklers ein gutes Produkt herstellen, aber es wird absolut nicht gefragt sein, weil hat keine ordnungsgemäße Verwaltung. Wenn der Faden zwischen Mitarbeitern, der das Geschäft am Laufen hält, gerissen ist, wird Ihr Produkt mit Sicherheit auf den Grund gehen.