Senior Ruby on Rails — Preguntas de entrevista Ruby on Rails

¿Cómo ejecutas una migration en una tabla grande sin downtime?

Asume que la tabla está bloqueada mientras dure el statement, y diseña el cambio para que eso no pase. Agrega columnas como nullable sin un default, haz el backfill en lotes fuera de la migration, agrega índices de forma concurrente, y solo después agrega la restricción. Renombrar y eliminar son los casos peligrosos porque el código viejo sigue corriendo durante el deploy — hazlos en dos releases con una escritura dual en el medio.

¿Cómo divides un monolito de Rails que creció demasiado?

Traza los límites antes de extraer nada — normalmente a lo largo de las partes del dominio que cambian juntas. Hazlos cumplir primero dentro del mismo codebase, con módulos o engines y sin acceso a base de datos entre límites, que es donde descubres casi gratis que el límite estaba mal trazado. Extraer un servicio es el último paso, no el primero, y solo vale la pena cuando un equipo o una necesidad de escala realmente lo exige.

¿Cuándo vale la pena la metaprogramación, y qué cuesta?

Se paga en una librería pequeña donde elimina una gran cantidad de repetición — define_method sobre una lista de atributos está bien. Cuesta en el punto donde alguien busca un nombre de método y no encuentra nada, o donde un typo se convierte en un nil silencioso porque method_missing lo tragó. Si defines method_missing, define respond_to_missing? junto con él, si no el objeto miente sobre lo que puede hacer.

¿Cómo decides qué cachear?

Cachea lo que es costoso y estable, y solo después de que la consulta ya sea tan buena como puede llegar a ser — el caching no arregla un N+1, es una forma de esconderlo hasta que el caché falla. Decide la invalidación antes del caching: una clave que incluye updated_at expira sola, mientras que una limpieza manual es lo que se olvidará. Datos incorrectos cacheados son peores que una página lenta.

¿Cómo abordas una actualización mayor de Rails en un producto en producción?

Primero pon la suite de tests en un estado honesto, porque la actualización es tan segura como lo que ella pueda decirte. Después avanza una versión menor a la vez, resuelve las advertencias de deprecación antes de que se conviertan en errores, y mantén la app corriendo en la versión vieja y nueva en la misma rama donde el framework lo permita. La parte que la gente subestima son las gemas: el bloqueo suele ser una dependencia sin mantenimiento, no Rails en sí.