Quiero compartir con ustedes la historia de una buena vida y la muerte larga, lenta y dolorosa de un portal inmobiliario que alguna vez fue grande. Que no estaba listo para cambiar y hacer movimientos bruscos para adaptarse a un mercado cambiante. Un producto que en 10 años ha pasado de TOP-10 a la parte inferior. Esta es una historia sobre la importancia del hilo que conecta a los desarrolladores, con su comprensión y mente dulce, y gerentes / directores / gerentes con su enfoque de gestión de proyectos.
Inicio
Llegué a este trabajo en 2014, un simple .net junior. PN (en adelante denominado el portal inmobiliario) era un agregador de bienes inmuebles, en el que además de la base de datos de anuncios había una sección de noticias temáticas de calidad. Noticias, artículos, leyes y muchos materiales diferentes sobre bienes raíces. Un gran departamento de periodistas geniales escribió artículos muy interesantes, cuyo interés era muy alto entre los usuarios.
El sitio en sí era libre de colocar anuncios, que atraían a los usuarios (vendedores privados, agencias inmobiliarias). Todos los ingresos se generaron debido a la colocación publicitaria habitual en esta área de bloques de texto-gráficos (TGB) de los desarrolladores que promocionan sus nuevos edificios y edificios residenciales.
En su apogeo (2008 - 2012), el sitio tuvo un tráfico de más de 1,000,000 de visitantes únicos por mes. Y dio una buena conversión para los anunciantes. Estos fueron excelentes indicadores, dado que PN funcionaba solo para Moscú y San Petersburgo. El personal estaba formado por 2 programadores y muchos periodistas y editores. De hecho, todo el mantenimiento, soporte y refinamiento de la PN se llevó a cabo solo por 2 empleados (cuántas personas diseñaron y desarrollaron originalmente la historia de la PN es silenciosa).
Aquí es donde termina la parte positiva de la historia.Caer
Después de la primera ola de la crisis, el sitio comenzó a tener problemas de tráfico y problemas muy serios. Él solo comenzó a caerse. El mercado comenzó a cambiar con bastante rapidez. Los competidores comenzaron a aplastar, porque Mientras que nuestro PN descansaba en sus laureles y no se desarrollaba en ningún lado, otros hicieron sus productos más modernos y cumplieron con las expectativas de los usuarios.
Además, los motores de búsqueda comenzaron a gustar cada vez menos de nuestro sitio, que por cierto prácticamente no tenía ningún tipo de CEO. Sí, había algunas plantillas para h1, título, descripción, un poco de vinculación y, en general, eso es todo (después del comienzo de la caída y hasta el final, el jefe del Monasterio comenzó una batalla de CEO, que habíamos estado haciendo durante casi 5 años).
Con la segunda ola de la crisis en 2014, el rendimiento cayó por debajo de 300,000 visitantes únicos por mes. Alrededor de este tiempo, conseguí un trabajo.
Aquí es donde comienza mi parte técnica de la historia .
Inmersión
Los primeros 2 años trabajé como desarrollador junior. Hizo todo lo que me dieron. Tuve que aprender mucho desde cero. Sin embargo, tuve suerte con mi gerente de desarrollo. Tenía poco más de 40 años, un programador de la vieja escuela, que sabía mucho y sabía cómo. Probablemente su credo principal fue: funciona y es bueno (estoy muy agradecido con él, porque adopté muchos conocimientos y varios enfoques de desarrollo).
Nuestra pila de tecnología fue la siguiente:
MS SQL Server 2012 + ASP.NET MVC 3 . La base guardaba todo en sí mismo. Incluso fotos en forma binaria, para 3 tamaños de set (grande, grande, pequeño).
El backend incluyó varios módulos:
- Sitio lun
- Área administrativa general
- Administrador de SEO
- Analizador de robots KLADR
- Robot de importación de feed XML
Todo este tiempo solo estaba haciendo tareas para que el código funcionara y no hubiera errores. Especialmente sin profundizar o pensar en un mayor desarrollo. Pero ha llegado el momento y se ha vuelto necesario.
En el segundo año de trabajo, mi gerente dejó el proyecto. Y me quedé cara a cara con este antiguo coloso, en el que estaba el 3% de mi código por la fuerza.
Fue un estrés salvaje . El CEO me preguntó todo, y a veces no tenía idea de qué y cómo funcionaba. Naturalmente, la vida me hizo y poco a poco profundicé en todos los procesos y me di cuenta de que ese enfoque "funciona bien" no es para mí. En este momento, leí muchos materiales de diseño, fui educado en el campo de tecnologías y marcos populares. Estaba conduciendo a casa desde el trabajo y pensando en qué y cómo lo haría mañana. Y cuando conducía al trabajo, pensé si lo que decidí ayer era correcto. Quería entender cómo hacer todo de manera correcta y conveniente. Para no tener que hacer muletas, duplique el código, pruebe todo en vivo, implemente todo manualmente y rechace buenas ideas debido a algunos errores de diseño en el pasado.
En este momento, habíamos hecho mucho en SEO, abandonando las tareas destinadas a mejorar la interfaz de usuario. Sin embargo, el tráfico disminuyó cada vez más. Y en algún momento el proyecto se congeló. Comencé a tratar solo con el soporte y la corrección de errores ... Así que sonó oficial.
De hecho, comencé a reescribir completamente el sistema desde casi 0. Tuve que hacerlo en secreto desde el manual. Después de todo, nunca nos dieron tiempo. Siempre dijeron que necesitamos más rápido, más rápido. Que estamos detrás de todo eso. Y necesita hacer un producto competitivo en 4 manos y mejor que el resto. Por lo tanto, si digo que planeo rehacer todo, entonces usted mismo comprende qué respuesta escucharía.
Aumento imaginario
Entonces, arremangándome las mangas, comencé a concebir. Elegí la arquitectura clásica de tres niveles.
El backend .Net Core + SQL + Mongo, la interfaz es Bootstrap + JQuery + KnockoutJS .
Organizó una capa de datos. Interfaces, abstracciones, repositorios están bien. La capa funcionó en procedimientos almacenados (afortunadamente, comencé a entender SQL bastante bien). Para el mapeo elegí Dapper. Es simple y directo. InMemoryCache rechazado a favor de Redis para llevar el caché a un servidor separado. El siguiente fue el nivel de lógica de negocios. Todas las mismas interfaces, servicios, DI. Entonces, la base apareció en forma de Capa de datos (Procedimientos almacenados + Dapper + Redis) y Capa lógica. Tomó alrededor de 3 meses.
Y aquí, después de casi un año de trabajo, logré conseguir un asistente solo para mí, insistiendo en que había muchas tareas (y había muchas). Juntos, todo fue mucho más rápido y mejor, y lo más importante aún más racionalmente.
- En primer lugar, desarrollamos una API para fotografías . Era un simple WebApi, que en Get-request daba la imagen de la calidad y el tamaño deseados del disco. Cambiamos a SSD y olvidamos la base de datos de imágenes como una pesadilla. Es difícil describir qué tan rápido comenzó a cargarse la página promedio del sitio después de asignar un grupo separado para esto.
- Abandonamos KLADRA a favor de FIAS . Escribieron un servicio de alta calidad para analizar datos de FIAS a nuestra base de datos, teniendo en cuenta nuestras características. Le atornillaron un servicio para geocodificar casas. Todo funcionó casi como un reloj. Solo ocasionalmente había errores asociados con ubicaciones o calles duplicadas en la base de datos de FIASA.
- Luego escribieron una nueva cuenta personal durante mucho tiempo, compartiéndola desde el sitio. Fue diseñado y planeado durante mucho tiempo para que fuera fácil de usar. Además de rápido y funcional. Le arruinaron el pago y luego fiscalizaron los cheques (sí, no podíamos permitirnos usar soluciones integradas ya preparadas). En general hizo un buen servicio al usuario. Y estaban contentos con él.
- Finalmente, llegamos al robot para importar feeds XML . Hecho un validador conveniente y buen registro para los clientes. El nuevo servicio resultó estar tan optimizado que si el antiguo (usando EF) funcionó durante aproximadamente 6-8 horas, entonces el nuevo procesó la misma cantidad de datos en 2-3 horas.
- Después de todo, levantaron un dominio con documentación para todo lo que es. Presentaron todos los puntos para los usuarios y clientes del portal, y también describieron una parte de la documentación que será útil para los desarrolladores. ¡Y esto es realmente importante!
- El último paso fue optimizar la base . Lo reelaboramos por completo. Limpiamos todo lo innecesario. Lograron una aceleración de la velocidad de búsqueda de 4-5 segundos a ~ 300 ms . Crearon índices, escribieron consultas complejas, usaron sugerencias e incluso hicieron particiones de tablas estadísticas.
Desafortunadamente, las manos no lograron llegar al sitio en sí. Porque Casi todas las tareas con el sitio estaban relacionadas con SEO, lo que tomó una cantidad de tiempo decente. Nuevas páginas, nuevas colecciones, nuevas reglas. Más, más, más páginas. Tuve que editar constantemente algo en el motor del sitio, lo que no me permitió transferirlo simultáneamente a la base creada.
Aquí termina la historia técnica y comienza el triste epílogo.
Vale la pena comenzar con el hecho de que el CEO del sitio no estaba conectado con la esfera de TI. Por lo tanto, muchas decisiones fueron tomadas por ellos de forma incorrecta e individual. Muy a menudo las discusiones se paralizaron, ya que nuestras nuevas ideas no fueron aceptadas, porque
"Esto no es necesario, te lo digo como experto en bienes raíces"
o
"Así que nadie está mirando, esta es una consulta de baja frecuencia, estoy seguro"
Y después de un tiempo, cuando él mismo llegó a esto, se les ofrecieron nuestras ideas con un reclamo, por qué no lo habíamos dicho antes, o con sincera sorpresa.
"No podría decirlo, esto es absurdo"
No pudimos llegar a un consenso, por lo que nosotros (los desarrolladores) simplemente fuimos inferiores. E hicieron lo solicitado. El dolor del programador: hacer "funciones" inútiles para nadie.
Me gustaría mencionar que las finanzas siempre han tenido problemas.
No hubo inversiones, excepto en SEO . Incluso mantener 2 programadores era costoso. Obviamente, era imposible competir con los nuevos portales del TOP-10 con tal nivel de financiación y gestión.
Como resultado, tenemos una plataforma para un portal de agregador inmobiliario. Escalable, ampliable, rápido y técnicamente listo para cualquier desastre. Con gran potencial. Buen código, muletas mínimas y pocos cuellos de botella.
Sin embargo, esto no dio un resultado positivo. En el momento de mi último día de trabajo, a pesar de la presencia de 4 millones de páginas únicas en los motores de búsqueda, el tráfico del portal fluctuó alrededor de 1,400 páginas únicas por día. Y esto, me parece, afirma la muerte.
PD: De toda la historia que pude personalmente, llegué a una conclusión principal. Puede hacer un buen producto desde el punto de vista del desarrollador, pero no tendrá ninguna demanda, porque No tiene una gestión adecuada. Si se rompe el hilo entre los empleados que mantiene a flote el negocio, entonces su producto seguramente irá al fondo.