¿Es común no poder hacer que la versión de desarrollo de un repositorio funcione localmente cuando comienzas un nuevo trabajo?

Común para no poder construir cosas sin ayuda: Sí, eso no es tan raro. De hecho, en muchos lugares es posible que ni siquiera sea capaz de descubrir cómo revisar el código CORRECTAMENTE sin ayuda, incluso si parece obvio.

Común para no obtener ayuda: la clave para responder a esto es por qué.

Un ejemplo que he visto que está bien: un equipo con una configuración de desarrollo compleja que no está tan bien documentada como les gustaría, pero reproducible … a alguien le tomará aproximadamente 1/2 día a 2 días resolverlo un nuevo desarrollador y enséñeles lo suficiente como para comenzar a hacer la siguiente capa de preguntas. 😉

Pueden estar en un momento en que no tienen tiempo para ayudarlo. Justo antes de un lanzamiento importante es un momento común para causar este problema. (Especialmente ~ 1–2 semanas fuera).

Si me enfrentara a este problema: hablaría con mi gerente, averiguaría qué está sucediendo y lo diagnosticaría como un problema. Si no puede reproducir la compilación … ¿y si un troyano / virus elimina los sistemas del desarrollador? De repente, no hay forma de que puedan trabajar, una vez que limpian …

Puede sonar exagerado … Pero el hecho es: sucede, al igual que los rayos, al igual que todo tipo de cosas que eliminan muchas máquinas a la vez.

Es por eso que poder configurar un entorno de desarrollo de forma rápida y fácil es una cosa clave para cada equipo. O al menos ser capaz de hacerlo, incluso si es lento y doloroso.

Además: si una empresa no puede reconstruir su software con el corte de línea de Internet, no puede reproducir sus compilaciones, punto. Eso es peligroso para la empresa a largo plazo.

Cómo un desarrollador acaba de romper Node, Babel y miles de proyectos en 11 líneas de JavaScript

Entonces … la gestión de la configuración del software moderno puede ser muy difícil … no importa realmente construirlo.

¿Es común no poder hacer que la versión de desarrollo de un repositorio funcione localmente cuando comienzas un nuevo trabajo?

Lamentablemente, no todo es inusual. Tampoco es necesariamente culpa de nadie en particular.

Podrías tener un equipo que esté usando una versión particular de un software, pero cuando vengas a instalarlo, desplegarás la última versión, que podría ser más nueva que la que usa el resto de tu oficina, y eso podría causar cosas para romper inesperadamente.

Ese es un ejemplo. Podría fabricar más, pero el hecho es que la gente registra el código que parece funcionar en su entorno establecido sin ejecutar un buen conjunto de pruebas o probarlo desde cero en un sistema limpio … y lo hacen todo el tiempo.

También podría no haber suficiente documentación. Es posible que no sepa que algo era una dependencia porque en los sistemas de todos los demás, vino junto con otro paquete. El desarrollador que configuró el entorno de desarrollo original puede haber dejado mucho tiempo antes y no haber escrito los pasos correctos para replicar su trabajo.

Este es un ejemplo de un problema que se puede resolver mediante documentación y entornos de desarrollo virtual que se pueden implementar bajo demanda (ver Docker y Vagrant) y compartir fácilmente con otros.

Como han dicho otras personas, desafortunadamente es común.

Los desarrolladores establecidos en proyectos a largo plazo a menudo tienen cosas configuradas en varios lugares que hace mucho tiempo olvidaron. Simplemente funciona Es posible que tengan un software instalado que se ejecuta detrás de escena, pero es fundamental para garantizar que se construya el repositorio. Las bases de datos pueden tener datos críticos que se han acumulado con el tiempo.

A menos que alguien cree y pruebe regularmente una copia del repositorio en una nueva máquina, estas cosas pueden pasar desapercibidas. Muchos de ellos pueden haberse configurado durante una intensa sesión de depuración en un lanzamiento atrasado. A menudo, estos no están documentados en el momento, y para cuando las cosas funcionan, el desarrollador agotado se va a casa y se cuelga. Al día siguiente, tienen que trabajar en la próxima crisis y la oportunidad de grabar cosas puede perderse.

¿Qué puedes hacer al respecto? La mejor idea es, como alguien más dijo, hablar con los otros desarrolladores y probar cosas, documentar todo lo que intentes, limpiar ese documento cuando las cosas funcionen y agregarlo al repositorio para la próxima persona nueva.

Cuando hable con esos desarrolladores, pregunte sobre cosas como los archivos de configuración (posiblemente en algún lugar de sus carpetas de inicio), haga que verifiquen el software instalado (puede despertar un pensamiento), verifique si conocen a alguien que ya no está trabajando en el proyecto Quién podría tener ideas.

Puede que tenga que intentar resolverlo por su cuenta. Úselo como una experiencia de aprendizaje; puede obtener información útil sobre el código que lo ayudará a largo plazo.

Y, por supuesto, también existe la posibilidad de que las cosas no estén en un estado estable. A veces las cosas se complican y, debido a que las personas pueden centrarse en sus cambios locales, pueden no notar que la rama de desarrollo principal no está funcionando. Si la empresa no tiene un sistema de integración continua configurado (o si las personas no están prestando atención a sus informes), problemas como este pueden continuar por un período prolongado.