He estado en esa posición exacta y puedo darle algunas ideas sobre cómo administrar el proceso. Estoy de acuerdo con Anton Melnik en que si asumes esto, aprenderás más sobre Ruby y Rails que sobre cualquier otra posición.
Antecedentes: Hace aproximadamente 4,5 años me mudé a Silicon Valley para tomar una posición en una pequeña startup. Ese inicio en particular fue un desastre en ciernes, tanto que me fui después de 11 meses (un mes antes del chaleco de opciones de un año) porque comenzaron a mentir a posibles inversores y sentí que las acciones no valdrían nada de todos modos. (Yo tenía razón.)
Tomé una posición con una startup más grande que era diferente día y noche. El personal fue competente y el más acogedor de todos los trabajos que he tenido en mis más de 35 años de carrera. Cuando asistí a las reuniones, PIDIERON mi opinión, a pesar de que apenas sabía lo que estaba pasando, y me dieron un bono de firma retroactiva porque anunciaron un bono para todos mi tercer día y había * solo * perdido el corte.
Sin embargo, tenían una aplicación enorme (25,000+ líneas de Ruby, HTML, Javascript, etc.) Rails 2, Ruby 1.8.7 que orquestó completamente su servicio basado en la nube. Los desarrolladores originales se habían ido, el nuevo código solo se había eliminado una vez en el año anterior (seis meses antes de que yo llegara) y eso había sido un desastre.
La aplicación tenía pruebas, pero no se ejecutaban, dependía de un conjunto particular de datos (que no se podía encontrar) y, para empezar, eran malas pruebas. (Almacene 5 en la base de datos. Lea la base de datos. ¿Obtuvimos un 5?)
Habían intentado comenzar a reescribir por completo, pero esos intentos solo habían desaparecido mientras trabajaban para mantener las cosas en funcionamiento.
Mi primer paso fue hacer que la aplicación se ejecutara en modo de desarrollo y ver si podíamos resolver algunos de sus problemas inmediatos. Siempre miro el registro de Rails mientras trabajo en una aplicación de Rails y vi un gran número de solicitudes de bases de datos, muchas de ellas casi idénticas. Esto grita como un problema de “N + 1” (búscalo).
Mi primera semana en el trabajo comencé a acelerar la carga de la página en más de un factor de 4 simplemente agregando cláusulas “incluye” a muchas de las recuperaciones de ActiveRecord.
Conseguir que la aplicación actualizada fuera aprobada para su distribución tardó casi un mes, fueron muy difíciles. Lo ejecutamos en un entorno de prueba, golpeándolo duro, luego lo implementamos lentamente sin problemas.
Mientras tanto, configuré un plan de ataque para obtener una aplicación Rails 2 / Ruby 1.8.7 refactorizada a Rails 4 / Ruby 2. (Las reescrituras totales rara vez tienen éxito, especialmente cuando el código actual es necesario para continuar con las operaciones).
Esto es lo que se me ocurrió.
- Primero, ni siquiera * intente * saltar directamente a las versiones actuales. Los cambios son demasiado masivos y no podrá mantener la aplicación ejecutándose mientras tanto.
- Actualice solo * una * cosa a la vez. Comience con la actualización de Ruby de 1.8.7 a la versión 1.9.3 (apropiado para Rails 3). Siguiente trabajo en Rails 2 -> Rails 3. Luego actualice Ruby, luego Rails, etc.
- Echa un vistazo a newrelic / rails3_upgrade. Es una gema que le permite * cambiar * las versiones de Rails utilizando variables de entorno y mantener ambos conjuntos de configuraciones.
- Utilicé RVM para administrar Ruby y Gemsets y escribí un par de pequeños scripts para intercambiar mis archivos .ruby-version y .ruby-gemset dependiendo del entorno que estaba ejecutando / probando.
- Me deshice de todas las pruebas anteriores. No valían nada. Conserve los suyos si funcionan, pero no pase mucho tiempo manteniéndolos en funcionamiento a menos que sean pruebas de “comportamiento” (pruebas que solo verifican los resultados y no pruebas que prueban una implementación particular.
- Comencé a escribir * nuevas * pruebas basadas en el comportamiento utilizando una versión antigua de Rspec que se ejecutaría en Rails 2/3.
- Configure sus pruebas para que se ejecuten en TODOS sus entornos compatibles actualmente. Es decir, si aún ejecuta Rails 2 en producción, TODAS las pruebas deben pasar en modo Rails 2. Sin embargo, si está trabajando en el paso Rails 2 a Rails 3, también deben pasar en ese modo. En un momento tuve 3 entornos (Rails 2 / Ruby 1.8.7, Rails 2 / Ruby 1.9.3, Rails 3 / Ruby 1.93). Las mismas pruebas pasaron en los tres entornos.
Mientras trabajaba en este proyecto, también tuve que corregir una acumulación de errores y pequeñas solicitudes de mejoras. También tuve que convencerlos de que podíamos desplegarnos de manera segura.
Lo hice siguiendo estrictamente las “mejores prácticas”. Cada vez que trabajaba en un error, comenzaba escribiendo una prueba (fallida) que * confirmaba * el error. Publicaría una actualización del informe de error sobre la nueva prueba fallida. Luego corregiría el error hasta que la prueba pasara y actualizara el ticket.
En algunas ocasiones, a medida que aumentaba la cantidad de pruebas, solucionaba un error y obtenía la prueba para pasar solo para que una o más pruebas fallaran. Publicaría ESE estado en el ticket, explicaría lo que me había perdido en mi arreglo original, refactorizaría hasta que pasaran todas las pruebas y luego publicaría ESE estado. (Cuando otras pruebas fallan, eso debería considerarse una gran victoria y validación de sus pruebas anteriores. ¡Una de ellas simplemente lo salvó!)
Después de un mes de golpear el nuevo código, finalmente contuvieron la respiración y permitieron que se implementara. Sin problemas. Para cuando la compañía cerró (problemas no relacionados) pude implementar a pedido. Yo * nunca * eliminé la producción.
Mientras tanto, ataqué modelos y luego controladores, envolviendo el código Rails 2 en desuso y el nuevo código Rails 3 en bloques if / then. (si RAILS-2 más ).
Aquí hay algunos problemas que recuerdo:
- La actualización de Ruby de 1.8.7 a 1.93 fue bastante fácil. Me parece recordar algunos cambios en las declaraciones de caso / cuándo que requirieron algunas actualizaciones. Encontrar un conjunto compatible de gemas fue más difícil, pero finalmente logré construir dos Gemfiles (intercambiados cuando se cambiaron los entornos) que funcionaban.
- Rails 2 a Rails 3 será su paso * más grande *, especialmente si reescribe todas las solicitudes de ActiveRecord en el nuevo estilo de consulta de ActiveRecord de los Rails actuales. Actualicé cada uno, envolviéndolos en mi entorno si / de lo contrario bloquea.
- El mayor problema que encontré fue con las plantillas ERB. Uno de los cambios de Rails 2 a Rails 3 fue en el form_for helper. En Rails 2 no incluía un signo igual (“=”) pero en Rails 3 es obligatorio. Desafortunadamente, ERB evaluará * ambas * las cláusulas if y else, por lo que ERB informó un error en mis plantillas para los signos “=” de Rails 3, aunque ese código nunca se hubiera ejecutado en modo Rails 2. Ese error NO existe en el renderizador HAML que funciona en Rails 2, por lo que simplemente actualicé los ERB con plantilla a HAML (que prefiero de todos modos)
Dependiendo del tamaño de la aplicación y de lo ocupado que también esté reparando errores y haciendo mejoras a la versión actual, este proyecto puede llevar años, así que no lo subestime (¡o permita que su nuevo empleador lo subestime!).
Tuve un gran apoyo de esa compañía y volvería a trabajar con esas personas en un instante. (Incluso teníamos un gran producto que desafortunadamente era demasiado temprano para el mercado y la compañía no podía pagar los gastos necesarios para seguir funcionando hasta que el producto fuera rentable).
Espero que ayude con su decisión (difícil).