Je veux partager avec vous l'histoire d'une belle vie et de la mort longue, lente et douloureuse d'un portail immobilier autrefois grand. Qui n'était pas prêt à changer et à faire des mouvements brusques pour s'adapter à un marché en évolution. Un produit qui en 10 ans est passé du TOP 10 au plus bas. Il s'agit d'une histoire sur l'importance du fil qui relie les développeurs, avec leur compréhension et leur esprit doux, et les gestionnaires / directeurs / gestionnaires avec leur approche de la gestion de projet.
Commencer
Je suis arrivé à ce poste en 2014, un simple .net junior. PN (ci-après dénommé le portail immobilier) était un agrégateur immobilier, sur lequel, en plus de la base de données des annonces, il y avait une section d'actualité thématique de qualité. Nouvelles, articles, lois et nombreux documents différents sur l'immobilier. Un grand département de journalistes sympas a écrit des articles très sympas, dont l'intérêt était très vif parmi les utilisateurs.
Le site lui-même était libre de placer des annonces, ce qui a attiré les utilisateurs (vendeurs privés, agences immobilières). Tous les revenus ont été générés en raison du placement publicitaire habituel dans ce domaine des blocs de texte-graphique (TGB) des développeurs faisant la promotion de leurs nouveaux bâtiments et bâtiments résidentiels.
À son apogée (2008 - 2012), le site avait un trafic de plus de 1 000 000 de visiteurs uniques par mois. Et il a donné une bonne conversion aux annonceurs. Ces indicateurs étaient excellents, étant donné que PN ne fonctionnait que pour Moscou et Saint-Pétersbourg. Le personnel était composé de 2 programmeurs et de nombreux journalistes et éditeurs. En fait, tout l'entretien, le support et le raffinement du PN ont été effectués par seulement 2 employés (combien de personnes ont initialement conçu et développé l'histoire du PN est silencieuse).
C'est là que se termine la partie positive de l'histoire.Automne
Après la première vague de crise, le site a commencé à avoir des problèmes de circulation et très graves. Il a juste commencé à tomber. Le marché a commencé à changer assez rapidement. Les concurrents ont commencé à écraser, car alors que notre PN reposait sur ses lauriers et ne se développait nulle part, d'autres ont rendu leurs produits plus modernes et répondant aux attentes des utilisateurs.
De plus, les moteurs de recherche ont commencé à ressembler de moins en moins à notre site, qui était d'ailleurs pratiquement sans PDG. Oui, il y avait quelques modèles pour le premier semestre, le titre, la description, un peu de reconnexion, et en général, c'est tout (après le début de l'automne et jusqu'à la fin, le chef du monastère a commencé une bataille de PDG, ce que nous faisions depuis près de 5 ans).
Avec la deuxième vague de crise en 2014, les performances sont tombées en dessous de 300 000 visiteurs uniques par mois. A cette époque, j'ai trouvé un travail.
C'est là que commence ma partie technique de l'histoire .
Immersion
Les 2 premières années, j'ai travaillé en tant que développeur junior. Il a fait tout ce qu'ils m'ont donné. J'ai dû apprendre beaucoup à partir de zéro. Cependant, j'ai eu de la chance avec mon directeur de développement. Il avait un peu plus de 40 ans, un programmeur de la vieille école, qui en savait beaucoup et savait comment. Son principal credo était probablement - cela fonctionne et est bon (je lui en suis très reconnaissant, car j'ai adopté beaucoup de connaissances et diverses approches du développement).
Notre pile technologique était la suivante:
MS SQL Server 2012 + ASP.NET MVC 3 . La base a tout gardé en elle-même. Même des photos sous forme binaire, pour 3 tailles définies (grande, grande, petite).
Le backend comprenait plusieurs modules:
- Mon site
- Zone d'administration générale
- Administrateur SEO
- Analyseur de robot KLADR
- Robot d'importation de flux XML
Pendant tout ce temps, je faisais juste des tâches pour que le code fonctionne et qu'il n'y ait pas eu d'erreurs. Surtout sans plonger dans le développement ni y penser. Mais le moment est venu et c'est devenu nécessaire.
En deuxième année de travail, mon manager a quitté le projet. Et je me suis retrouvé face à face avec cet ancien colosse, dans lequel se trouvait 3% de mon code par la force.
C'était un stress sauvage . Le PDG m'a tout demandé, et parfois je n'avais aucune idée de quoi et comment cela fonctionnait. Naturellement, la vie m'a fait et progressivement j'ai plongé dans tous les processus et j'ai réalisé que cette approche «fonctionne - bien» n'est pas pour moi. À cette époque, j'ai lu beaucoup de matériaux de conception, j'ai été formé dans le domaine des technologies et des cadres populaires. Je rentrais chez moi du travail et je pensais à quoi et comment je ferais demain. Et quand je conduisais au travail, je me suis demandé si ce que j'avais décidé hier était bien. Je voulais comprendre comment tout faire correctement et commodément. Afin de ne pas avoir à faire de béquilles, dupliquez le code, testez tout en direct, déployez tout manuellement et refusez les bonnes idées en raison d'erreurs de conception dans le passé.
À cette époque, nous avions beaucoup fait sur le référencement, abandonnant les tâches visant à améliorer l'interface utilisateur. Cependant, le trafic a diminué de plus en plus. Et à un moment donné, le projet a été gelé. J'ai commencé à m'occuper uniquement du support et de la correction des bugs ... Donc ça sonnait officiel.
En fait, j'ai commencé à réécrire complètement le système à partir de presque 0. J'ai dû le faire secrètement à partir du manuel. Après tout, ils ne nous ont jamais donné de temps. Ils ont toujours dit que nous avions besoin de plus en plus vite. Que nous sommes derrière tout cela. Et vous devez faire un produit compétitif à 4 mains et mieux que les autres. Par conséquent, si j'ai dit que j'avais l'intention de tout refaire, vous comprenez vous-même quelle réponse j'entendrais.
Montée imaginaire
Alors, retroussant mes manches, j'ai commencé à concevoir. J'ai choisi l'architecture classique à trois niveaux.
Le backend .Net Core + SQL + Mongo, le frontend est Bootstrap + JQuery + KnockoutJS .
Organisé une couche de données. Les interfaces, abstractions, référentiels sont corrects. La couche fonctionnait sur des procédures stockées (heureusement, j'ai commencé à bien comprendre SQL). Pour la cartographie, j'ai choisi Dapper. C'est simple et direct. Refusé InMemoryCache en faveur de Redis afin d'amener le cache sur un serveur séparé. Vient ensuite le niveau de la logique métier. Toutes les mêmes interfaces, services, DI. Ainsi, la fondation est apparue sous la forme de Data-Layer (procédures stockées + Dapper + Redis) et Logic-Layer. Cela a pris environ 3 mois.
Et ici, après presque un an de travail, j'ai réussi à obtenir un assistant pour moi seul, insistant sur le fait qu'il y avait beaucoup de tâches (et il y en avait beaucoup). Ensemble, tout est allé beaucoup plus vite et mieux, et surtout encore plus rationnellement.
- Tout d'abord, nous avons développé une API pour les photographies . Il s'agissait d'un simple WebApi qui, sur demande, donnait l'image de la qualité et de la taille souhaitées à partir du disque. Nous sommes passés au SSD et avons oublié la base de données d'images comme un cauchemar. Il est difficile de décrire à quel point la page moyenne du site a commencé à se charger plus rapidement après avoir alloué un pool distinct pour cela.
- Nous avons abandonné KLADRA au profit de FIAS . Ils ont écrit un service de haute qualité pour analyser les données de FIAS dans notre base de données, en tenant compte de nos fonctionnalités. Ils lui ont vissé un service de géocodage de maisons. Tout fonctionnait presque comme une horloge. Seulement occasionnellement, il y avait des bogues associés à des emplacements ou des rues en double dans la base de données FIASA.
- Ils ont ensuite écrit un nouveau compte personnel pendant longtemps, le partageant depuis le site. Il a été conçu et planifié depuis longtemps pour être convivial. Ainsi que rapide et fonctionnel. Ils lui ont foiré le paiement, puis la fiscalisation des chèques (oui, on ne pouvait pas se permettre d'utiliser des solutions intégrées toutes faites). Dans l'ensemble, nous avons fait un bon service aux utilisateurs. Et ils étaient contents de lui.
- Enfin, nous sommes arrivés au robot pour importer des flux XML . Fait un validateur pratique et une bonne journalisation pour les clients. Le nouveau service s'est avéré si optimisé que si l'ancien (utilisant EF) fonctionnait pendant environ 6 à 8 heures, le nouveau traitait la même quantité de données en 2 à 3 heures.
- Après tout, ils ont créé un domaine avec de la documentation pour tout ce qui existe. Ils ont exposé tous les points pour les utilisateurs et les clients du portail, et ont également décrit une partie de la documentation qui sera utile aux développeurs. Et c'est vraiment important!
- La dernière étape a été d' optimiser la base . Nous l'avons complètement retravaillé. Nous avons nettoyé tout ce qui n'était pas nécessaire. Ils ont atteint une accélération de la vitesse de recherche de 4-5 secondes à ~ 300 ms . Ils ont créé des index, écrit des requêtes complexes, utilisé des astuces et même créé des partitions de tableaux statistiques.
Malheureusement, les mains n'ont pas réussi à se rendre sur le site lui-même. Parce que presque toutes les tâches du site étaient liées au référencement, ce qui prenait un temps décent. Nouvelles pages, nouvelles collections, nouvelles règles. De plus en plus de pages. J'ai dû constamment modifier quelque chose dans le moteur du site, ce qui ne m'a pas permis de le transférer simultanément sur la base créée.
Ici, l'histoire technique se termine et le triste épilogue commence.
Il convient de commencer par le fait que le PDG du site n'était pas connecté à la sphère informatique. Par conséquent, beaucoup de décisions ont été prises par eux de manière incorrecte et individuelle. Très souvent, les discussions sont au point mort, nos nouvelles idées n'ont pas été acceptées, car
"Ce n'est pas nécessaire, je vous le dis en tant qu'expert immobilier"
ou
"Donc, personne ne regarde, c'est une requête basse fréquence, je suis sûr"
Et après un certain temps, quand il en est venu à lui-même, nos idées leur ont été proposées avec une revendication, pourquoi nous ne l'avions pas dit auparavant, ou avec une sincère surprise
"Je ne pourrais pas le dire, c'est absurde"
Nous n'avons pas pu parvenir à un consensus, à la suite de quoi, nous (les développeurs) étions tout simplement inférieurs. Et ils ont fait comme demandé. Douleur du programmeur - pour rendre les «fonctionnalités» inutiles à personne.
Je voudrais mentionner que la finance a toujours eu des problèmes.
Il n'y a eu aucun investissement, sauf dans le référencement . Même garder 2 programmeurs coûtait cher. Il était évidemment impossible de concurrencer les nouveaux portails du TOP-10 avec un tel niveau de financement et de gestion.
En conséquence, nous avons une plate-forme pour un portail d'agrégateur immobilier. Évolutif, extensible, rapide et techniquement prêt pour toute catastrophe. Avec un grand potentiel. Bon code, béquilles minimales et quelques goulots d'étranglement.
Cependant, cela n'a pas donné de résultat positif. Lors de ma dernière journée de travail, malgré la présence de 4 millions de pages uniques dans les moteurs de recherche, le trafic du portail a fluctué autour de 1 400 pages uniques par jour. Et cela, il me semble, déclare la mort.
PS: De toute l'histoire que j'ai pu personnellement, j'ai tiré une conclusion principale. Vous pouvez faire un bon produit du point de vue du développeur, mais il ne sera absolument pas demandé, car n'a pas une bonne gestion. Si le fil entre les employés qui maintient l'entreprise à flot est déchiré, votre produit ira certainement au fond.