¿Por qué parece tan difícil que los programadores no entiendan las versiones? [duplicar]

12

Anteriormente, he trabajado con diseñadores, licenciados y gerentes de proyectos, todos los que producen artefactos de proyectos con regularidad, pero realmente comprenden el concepto de control de versiones. Cuando trato de explicárselo (incluso en su forma más simple de múltiples archivos con nombres diferentes) parecen tener algún tipo de bloqueo mental. ¿Por qué crees que esto es?

    
pregunta Andrew Cox 20.09.2010 - 12:28

10 respuestas

14

Esto se debe a que el humano tiene dificultades para proyectarse a sí mismo en el tiempo.

Usa la analogía de la máquina del tiempo. Tu vida está versionada. Cada día tienes una nueva versión de tu vida: cosas nuevas y cosas perdidas. Ojalá más activos, menos deudas, ... pero más gordos, menos pelos, ... ojalá más conocimiento, menos dudas, ...

Luego tendrás que explicar la ramificación;) Y ahí esperas que sean fanáticos de Fringe;)

    
respondido por el user2567 20.09.2010 - 13:00
8

Puedes usar la analogía del libro.

Cuando escribes un libro, primero escribes una versión preliminar. Luego lo lees, haces algunos cambios y lo relees. Hasta que se lo das a alguien más para que lo lea. Y, por supuesto, también tienen comentarios.

Cada cambio hace una nueva versión. Y aunque normalmente usa la última versión, a veces, se arrepiente de un cambio y desea revertir. Posiblemente todo el libro, posiblemente un solo capítulo. La versión le da esta oportunidad.

Luego el tema de la ramificación.

El libro está casi terminado y necesita ser traducido al francés. Así que haces una copia del libro y lo envías al traductor. Mientras tanto, haces algunos cambios en el libro original. Algunos de ellos se agregan a la traducción al francés y otros nunca lo hacen allí.

    
respondido por el Toon Krijthe 20.09.2010 - 13:17
6

Porque, en el mundo sin programación, cambiar un producto competido es muy difícil. Los cambios intencionales, que están pensados, no son fáciles, como los edificios, por ejemplo. Y una vez que se realizan los cambios, es difícil "revertir" a la versión anterior.

Contrariamente a eso, cambiar de software es muy fácil (más fácil que incluso otros productos de medios; por ejemplo, una película), y "verificar una versión anterior" es una tarea común en el mundo del software.

Por lo tanto, la noción de versión contradice la experiencia cotidiana, que generalmente confirma que solo existe una versión actual de una cosa (para el software no es cierto). Por eso es difícil.

    
respondido por el P Shved 20.09.2010 - 13:01
2

En mi experiencia, se dan cuenta con bastante rapidez.

Versión 1.0 - Vendemos por dinero.

Versión 1.1 - Pequeñas mejoras para algunos clientes: vendemos por una cantidad de dinero menor.

Versión 2.0 - Grandes mejoras. Vendemos por mucho dinero.

Versión 2.1 - Pequeñas mejoras para algunos clientes: nos ... "Espere un minuto", dice PM / BA "Cambié el nombre a 2.5 y le cobraremos 5 veces más". Ninguna cantidad de discusión de ingeniería los convencerá de lo contrario.

Versión 2.2 3.0 etc ...

    
respondido por el danio 20.09.2010 - 14:37
2

Mencionas que incluso la versión simple de los documentos le está dando dificultades a las personas, así que quizás no lo estés explicando bien o tu equipo no sea tan inteligente.

Nuestros desarrolladores usan git en la línea de comandos para las versiones, y una vez que están en la curva de aprendizaje, todos lo superan. No me he molestado en tratar de explicar git a personal no técnico porque con ellos hay mucha menos colaboración directa en documentos individuales, para esto utilizamos DropBox y no he visto a nadie luchando todavía.

    
respondido por el Armand 02.12.2010 - 12:53
1

Deben estar al tanto de varios escenarios de "día del juicio final". Computadora, servidor, disco duro, lo que sea, fallas, ¿no es bueno tener una copia de seguridad? Si no puede lograr que estén de acuerdo con este concepto, no puede seguir adelante.

Ahora, qué tal si se les pidiera que hicieran una presentación, pero en la tercera página, al cliente le gustaría verla con y sin el gráfico. ¿Qué harías? Hacer una segunda copia con los cambios. Si te dijeran que no querían el gráfico, ¿tirarías la 'versión' con el gráfico? Probablemente no porque nunca se sabe. Si no puede lograr que estén de acuerdo con este concepto, no puede seguir adelante.

¿Alguna vez ha enviado un archivo para su revisión solo para que la persona lo cambie? ¿Mantuviste tu versión? ¿Tuvo que darles un nombre diferente al archivo que les envió porque sabe que cuando hacen cambios es demasiado difícil notar la diferencia o guardarlos en la misma carpeta? ¿Y no se están alargando estos nombres? Si no puede lograr que estén de acuerdo con este concepto, no puede seguir adelante.

¿No sería bueno si tuviéramos algo que simplemente hiciera un seguimiento de todo esto para nosotros? No más el envío de archivos adjuntos de correo electrónico. Ya no me pregunto cuál fue la razón por la que el Jefe hizo ese cambio, pero hice otro cambio y ahora no podemos reunirnos. No más nombres de archivo largos que intentan explicar en qué versión estamos. Si no puede lograr que estén de acuerdo con este concepto, solo tendrá que seguir adelante.

    
respondido por el JeffO 30.09.2010 - 14:57
1

Descubrí que los ingenieros (elec / mech, etc.) no comienzan entendiendo la administración de la configuración, sino que se desarrollan (o vuelven locos a todos)

Los desarrolladores de software pueden entender las versiones.

Las personas no técnicas en general no entienden nada de este espacio. Es técnico.

Es parte de la disciplina de ingeniería que nunca tuvieron que aprender.

Y pueden elegir no hacerlo. Así que muchos de ellos lo harán.

La única solución es trabajar en algún lugar que tenga soporte de administración para un proceso disciplinado. El cumplimiento del nivel 2 de CMMI es un 400% más productivo en tiempo y dinero, pero las personas lo evitan.

    
respondido por el Tim Williscroft 27.07.2011 - 06:33
0

¿Se refiere a la creación de versiones o la ramificación / fusión?

Creo que es bastante sencillo entender las versiones. "Guardamos la versión del martes. Luego hicimos más trabajo. Ahora es miércoles. Podemos volver a la versión del martes".

La ramificación y la fusión es mucho más difícil de explicar. "Bueno, Bob hizo cambios en 1.1 que entraron en conflicto con la visión de Alice de 1.1 y los presentó primero, así que 1.2 tiene cambios de Bob, pero 1.3 también tiene cambios de Alice, excepto que algunos de Bob se integraron más tarde, así que ..."

    
respondido por el Alex Feinman 20.09.2010 - 16:18
0

Bueno, Alice escribe un bla. Luego Bob obtiene el bla y hace algunas ediciones, y Carol obtiene el bla y hace algunas ediciones. Estas son las versiones. Entonces Dan entra y le dice a Alice que haga un montón de cambios. Esta es otra versión. Al día siguiente, Dan regresa y dice que todo lo que dijo ayer fue una mentira, y que la gerencia quiere una versión de la bla para los villancicos del martes. Tener la versión de Carols y poder encontrarla fácilmente se llama control de versión.

    
respondido por el philosodad 02.12.2010 - 04:49
0

Mi conjetura es que la mayoría de las personas tienen muchas cosas que preocuparse, por lo que las versiones no llegan a la cima de su lista. Es como un seguro, el reembolso es de baja probabilidad y no es gratis.

Para los artefactos del proyecto que describe, si solo hay una persona involucrada (por ejemplo, un documento de licenciatura que describe un cálculo), pueden evaluar razonablemente la recompensa de mantener cero las versiones anteriores.

Requerir una versión más cuidadosa de este tipo de cosas puede introducir un elemento hostil en la atmósfera de un proyecto, ya que las razones para hacerlo pueden ser adversas, es decir, las personas esperan tener argumentos sobre las versiones antiguas y nuevas, por lo que quiero que las versiones anteriores estén disponibles como prueba.

    
respondido por el John Bickers 02.12.2010 - 11:46

Lea otras preguntas en las etiquetas