🐁 🤹🏽 👨🏾‍💻 Maldito viejo CRM 👐 ⏰ 🌌

Todo el año pasado, nuestros muchachos terminaron CRM 2.0 con BPMS Camunda y solo diez procesos en lugar de cientos de estados, y luego trataron de implementarlo a los usuarios y servicios sin perder nada. Espero que después de cortar finalmente el primer tcm-ku (la parte más antigua de todos los Skyeng) de nuestro ecosistema, compartan el rastrillo y lo encuentren aquí.

Mientras tanto, habiéndome interesado en el tema, encontré un caso similar, y decidí preguntarle a Dmitry Kosov de Finam sobre su experiencia de abandonar la herencia de principios de 2010.

Hola , soy el mismo "Seryozha de Bryansk" que decidió impulsar el conocimiento del desarrollo mediante blogs y screencasts sobre el tema de PHP. Este año quiero agregar un podcast a mis actividades: invitar a colegas de la industria. En el primer episodio, la historia del movimiento del primer Zend a Symfony. Si desea más detalles técnicos, también consulte la charla de Dima en Youtube . Bueno, en nuestra discusión después del informe sabrás:

cómo no perder y encontrar motivación, si entiendes que es todo un año antes de lanzar tu código en producción,

por qué cualquier documentación si no está mintiendo, está mintiendo,

y cómo se organiza el proceso de refactorización de dos años sin detener la producción de características utilizando el ejemplo de un proyecto y equipo reales.

Disfruta leyendo o escuchando .

¿Qué marcos fueron elegidos entre 2011? Y cómo elegir uno nuevo en 2016

Dima, Finam: específicamente miré, preparándome para el lanzamiento: tenemos exactamente 4,600 archivos en el papá, donde exactamente nuestro código no es vendedor, no todo tipo de js. Este papá pesa 16 metros. Y el primer compromiso que habríamos hecho ya en diciembre de 2011, su autor todavía está trabajando, este es nuestro líder de equipo.

Inicialmente, la pila se seleccionó correctamente. E incluso en 2012, era bastante moderno: el primer Zend era bastante relevante. Luego trabajé en otro trabajo, pero recuerdo que justo en el 12 en algún lugar a fines de la primavera, elegimos la pila para un nuevo proyecto. Mirábamos:

Zend: el segundo acaba de salir, pero era demasiado joven, no había comunidad para él,

primero Yii, pero no nos gustó el concepto ActiveRecord,

Phalcon

y algo más de exótico.

Y también eligieron el primer Zend. En ese momento fue una buena y relevante elección. Pero la lengua se adelantó. Pero desea usar espacios de nombres normales, en lugar de nombrar clases a través de guiones bajos. Me gustaría conectar algunas bibliotecas listas para usar de código abierto, que, por supuesto, nadie escribe bajo el primer Zend. Me gustaría atraer empleados al equipo, un par de veces cuando buscábamos nuevas personas, para algunos fue escrito directamente en la cara: "No lo aceptaré".

Finalmente, el primer Zend simplemente dejó de soportarlo. Por ejemplo, en 7.0 todavía lanzaron un parche de actualización de seguridad, y nosotros mismos aplicamos parches 7.2 y 7.3.

Nos detuvimos un poco con el comienzo del proceso de reubicación.

No hubo riesgo global: solo miramos lo que es moderno y relevante. Comparado con eso en otros proyectos: no somos el único equipo de PHP en la empresa. Nos dimos cuenta de que Symfony estaba contento con todos: parecía un proyecto que vivirá durante varios años, tiene una comunidad extensa, muchas bibliotecas listas para usar, nuevas utilidades, etc.

Comencé este negocio: estaba cavando en los primeros momentos solo por moverme, en el movimiento hacia Symfony. Cuando llegué, estaba inmerso en diferentes partes del proyecto para poder conocerlo lo más ampliamente posible, y para cuando comenzó la refactorización a gran escala, lo sabía muy bien. Y otro compañero vino después de que empezamos. Lo sumergimos en el proceso, pero tratamos de no asustarlo mucho. Al menos al principio)

OKAY. Hemos elegido un marco. ¿Que sigue?

Seryozha, Skyeng: Hay dos formas: puedes reescribir todo a la vez. Puedes intentar arrastrar y soltar lentamente. Por donde empezaste

Dima, Finam: Comenzamos con el holivar, qué camino tomar. Nadie ha tenido la experiencia de reescribir tal volumen. Por ejemplo, en mi trabajo anterior tuve experiencia en la reescritura de un pequeño servicio autónomo: allí solo congelamos el desarrollo durante un mes, reescribimos todo y continuamos. Aquí no hubiéramos sido suficientes por un año. Tal vez hubiéramos logrado ganar el 80 por ciento en un año, pero, ya sabes ...

Hay un principio: el primer 80% del trabajo lleva el 80% del tiempo. El 20% restante del trabajo llevará otro 80% del tiempo.

Era imposible detener la aplicación y sus tareas actuales. Y hay exactamente dos conceptos para este caso: o está haciendo algo con la aplicación actual o está implementando una nueva. Descartamos la opción de implementar uno nuevo, porque hay mucho código. Como resultado, implementamos la aplicación Symfony no cerca de la anterior, sino por encima.

Pero por qué así. Tenemos más de 250 tablas en la base de datos, y si elimina algunas placas de servicio, estas son alrededor de 200 entidades. Están bastante conectados entre sí y, debido a este número de conexiones, es muy difícil batir el código en algunas piezas lógicas autónomas. No lo rompa, de todos modos, una conexión sobresaldrá de esta pieza: por ejemplo, las llamadas y la telefonía están conectadas con gerentes y clientes. Por lo tanto, nos dimos cuenta: si implementa una nueva aplicación, comience a escribir nuevas funciones para ella y transfiera lentamente las antiguas, esto resultará en un doble trabajo. Después de todo, el código que transferiremos a la nueva aplicación no puede eliminarse completamente de la anterior. Y tendremos que apoyarlo en dos lugares.

Luego recordamos otra experiencia que nuestro equipo ya tenía.

Esta es la experiencia de reescribir una capa para acceder a los datos. Porque había una vez, junto con el primer Zend, Mongo fue elegido como la base de datos principal. Pero la práctica ha demostrado que la elección no es muy correcta.

Seryozha, Skyeng: Sí, tiene todas las conexiones relacionales, pero ha elegido una base de datos orientada a documentos.

Dima, Finam: Sí, y cuando llegué, los chicos estaban en el proceso de copiar de Mongo a PostgreSQL ... Y tuvimos la idea de que tenemos una capa de acceso a datos. Y dado que ya sabemos cómo reescribir capas para el acceso a datos, tal vez lo separemos un poco más y tomaremos inmediatamente la capa ORM.

Si imagina la aplicación como un pastel, habrá 5 capas: ORM, acceso a datos, lógica de negocios, controlador, vistas. Y podemos tocar 2.5 capas: cambiar completamente ORM y acceder a los datos, además de parcialmente, la lógica empresarial. No los algoritmos en sí, sino aquellas clases y objetos con los que funcionan estos algoritmos. Claramente sabía que es posible digerir la doctrina por separado, bueno, lo hice.

Así que me puse en marcha, inicialicé la doctrina allí, prescribí todos los ajustes necesarios y les di a los muchachos una revisión del código con las palabras: "Bueno, alguien debería haber comenzado esto".

El comienzo del camino puede verse más o menos así. Y luego aplicamos el principio de que un mamut se debe comer en partes. A veces las piezas resultaron ser más de lo que pensábamos, pero la tarea básica del sprint de dos semanas fue dar un paso, y nos aseguramos de que no hubiera tareas de características en la misma área.

Atrapé bichos, retrocedí, desplegué

Seryozha, Skyeng: Aún así, la refactorización es una cosa crucial, ¿cómo te aseguraste?

Dima, Finam: Tenemos una serie de pruebas unitarias, que cubren puntos clave. Hay una serie de pruebas funcionales automatizadas por nuestro probador. El trabajo principal de CRM es trabajar con datos. Y para probar sin datos, con las pruebas unitarias no siempre es posible: es más fácil enviar un paquete, verifique que se procese normalmente, que se haya creado una entidad con los parámetros necesarios.

Naturalmente, verificamos mucho con nuestras manos: especialmente algunas cosas clave e importantes, como los mismos clientes y llamadas.

Recuerdo bien cómo hice esta tarea. Llamé a nuestro jefe del centro de llamadas, y acordamos que cuando se queden sin trabajo y solo quede el asistente, daré lo mejor de mí, y el asistente verificará todo en las llamadas reales. Di lo mejor de mí, observé en los registros, atrapé un montón de insectos, me alejé, los descarté, advertí al asistente, salí, volví a atrapar el siguiente paquete, retrocedí ... Y así, algunas iteraciones.

Seryozha, Skyeng: Habiendo recorrido todo el camino, pero ahora es probablemente más de la mitad, ¿qué aconsejarías entonces?

Dima, Finam:Probablemente recomendaría implementar la misma aplicación Symfony encima de la nuestra un poco antes. Para asegurarnos de que lo que escribimos, lo que hacemos, realmente funciona. Recuerdo cómo lo implementamos, lo lanzamos primero desde la consola, luego desde el controlador, activamos nuestra capa de lógica empresarial y nos aseguramos de que la aplicación lo vea, pueda acceder a todos los servicios, extraer todos los métodos y descargar los resultados.

Me acabo de dar cuenta de lo fuerte que fue un motivador al darme cuenta de que realmente escribimos todo correctamente. Para verificar que va en la dirección correcta, para asegurarse de que está haciendo todo correctamente, debe hacerse temprano.

No en los primeros pasos, pero cuando ya tienes algo escrito, tómalo así, dispara con un año de anticipación, organiza una máquina del tiempo local, asegúrate de que estás haciendo todo bien, esto te dará fuerza. Y llegarás más lejos.

PD

Gracias por leer y escuchar. Se pueden encontrar más podcasts de PHP aquí .

Y si desea informes y conversaciones más interesantes sobre ellos, "venga" a la tercera reunión virtual de PHP el 30 de mayo.

Maldito viejo CRM