Interpreto que esta situación tiene dos problemas básicos, posiblemente tres.
- Una actualización de SDK no deseada se convirtió en la fuente, donde podría afectar negativamente al producto.
- De la pregunta: el colaborador que realizó la actualización no deseada no conocía una decisión específica previa de no actualizar.
El primero de estos, en mi opinión, es el más serio. Si una actualización de SDK no deseada puede incluirla en el código, también pueden hacerlo otros problemas.
Alguien sugirió agregar un caso de prueba de unidad que fallará si detecta la actualización. Si bien evitaría que se produjera la actualización, creo que esta es una ruta peligrosa, lo que lleva a flujo de lava sobre hora. Parece inevitable que, en algún momento en el futuro, el SDK se actualice para incorporar nuevas funciones o correcciones de errores, o porque la versión anterior ya no es compatible. Imagine el rasguño de cabeza, tal vez incluso los argumentos, que se producirán cuando una prueba de unidad de este tipo falla.
Creo que la solución más general es ajustar el proceso de desarrollo. Para git, use el proceso de solicitud . Para Subversion y herramientas anteriores, use sucursales y dif. Pero tenga un proceso de algunos que permita a los desarrolladores senior detectar este tipo de problemas antes que ingresen en el código base y afecten a otros desarrolladores.
Si el proceso de solicitud de extracción se hubiera utilizado en su situación, y si cada solicitud de extracción fuera estrecha y específica, no se habría desperdiciado mucho tiempo. Se habría enviado una solicitud de extracción para actualizar el SDK y se habría rechazado con el comentario de que no se desea la actualización. Nadie más se habría visto afectado, y ahora no habría necesidad de revertir la actualización del SDK.
Pero para responder directamente a la pregunta original, estoy de acuerdo con otros en que esperar que todos los desarrolladores lean completamente el historial de revisión del código, las notas de la versión, etc. Para avisos como este es una pérdida de tiempo valioso. ¿Qué pasa con un correo electrónico corto del equipo?
Posible tercer problema: ¿Por qué no se desea la actualización en primer lugar? Claramente, al menos un desarrollador pensó que la actualización sería algo bueno. Hay muchas buenas razones para retrasar una actualización, pero también muchas malas. Tenga cuidado de evitar el flujo de lava (innecesario código de compatibilidad con versiones anteriores) y cargo sect ("no podemos actualizar eso, pero no sé por qué ") anti-patrones!