¿Es posible que un buen programador nunca haya usado el control de versiones? [cerrado]

73

Estoy buscando un programador experto para ayudar a resolver una situación difícil.

Las entrevistas hasta ahora han sido sorprendentemente decepcionantes. El mejor candidato hasta ahora es un programador con mucha experiencia que nunca ha utilizado un software de control de versiones.

El problema en sí mismo podría no ser demasiado grave porque es algo que se puede aprender en poco tiempo.

Pero hay un aspecto más profundo, que me preocupa:

¿Cómo es posible desarrollar software activamente durante 10-15 años sin necesidad de control de versiones?

¿El hecho en sí mismo de no buscar una solución al problema del seguimiento cambia un signo de una actitud incorrecta hacia la programación?

lortabac
fuente
25
¿Quién dice que no necesitaba control de versiones? Lo necesitaba, y supongo que lo hizo manualmente. Dicho esto, un programador que hace esto parece ser muy resistente a aprender algo nuevo: prepárate para eso.
Doc Brown
66
@ e-MEE depende, puede aprender a actualizar / resolver / confirmar en 30-60 minutos, pero nadie aprende cómo funciona un (d) vcs en una hora. La mayoría de las personas que lo usan durante años todavía no lo entienden.
atamanroman
3
@ConradFrix Carrot Cake :)
Chad Harrison
77
Es posible que un buen programador nunca haya usado el control de versiones, si el calendario dice que hoy es 1981.
Kaz
77
Esto suena como un caso clásico de alguien que no tiene 10 años de experiencia, sino más bien 1 año de experiencia repetido 10 veces.
Jeanne Pindar

Respuestas:

90

Trabajé durante aproximadamente 11 años en empresas que no usaban el control de fuente. Lo gestionamos (principalmente comentando los cambios y manteniendo el código en un servidor central que podría recuperarse en cualquier fecha). Realmente nunca preguntamos si había una mejor manera. Dicho esto, esto también fue en los días en que tenía toda la biblioteca de MSDN en forma de libro en mi escritorio.

Sí, había programación antes de internet.

Me cuesta ver cómo puede pasar más de 10 años en la industria ahora sin haberse topado con el control de código fuente. Pero, tendría algo de simpatía, creo que era posible y no rechazaría al candidato solo con ese detalle. Investigaría y descubriría cómo el candidato ha logrado esto.

Alternativamente, podría cuestionar si mi proceso de entrevista fue el problema. ¿De qué manera era el mejor candidato? ¿Hay otras técnicas modernas de programación que él no tiene y que simplemente no estoy haciendo las preguntas correctas? Si estuviera haciendo las preguntas correctas, ¿brillaría otro candidato?

Sin embargo, como nota final, no tenga miedo de rechazar a todos los candidatos si tiene dudas. Comenzar de nuevo lleva mucho tiempo, pero es más lento contratar a la persona equivocada.

pdr
fuente
17
+1, es una respuesta interesante. Sin embargo, no estoy del todo de acuerdo con "en esos días, el control de la fuente costaba mucho dinero" . RCS ha existido por 30 años, CVS - 21 años; Ambos son de código abierto.
vartec
8
+1: sigo trabajando aquí . Finalmente estamos obteniendo control de fuente administrado este año (en gran parte debido a mí). No creo que todos seamos desarrolladores terribles como resultado de no tenerlo hasta ahora, pero estoy muuuy contento de que llegue
oliver-clare
3
Si el candidato comprende los principios del control de origen, no veo ningún problema. Un desarrollador experimentado debería ser capaz de elegir la "sintaxis" de cualquier sistema que use bastante rápido. Una pregunta que haría: ¿es toda esta experiencia en un solo sitio? Si es así, tal vez no tenía la autoridad para poder introducir un sistema. Si su experiencia ha sido con diferentes compañías, entonces investigaría un poco más. El número de empresas, con equipos de desarrollo, que no utilizan el control de fuente debe ser mínimo hoy en día.
BIDeveloper
44
+1 para el punto sobre hacer las preguntas correctas. Me preguntaba qué lo convertía en el mejor candidato también.
shambulator
3
@Ramhound: ¿y cree que al hacer el control de fuente manualmente necesita menos hardware y menos tiempo para realizar copias de seguridad? Según mi experiencia, lo contrario es bastante cierto.
Doc Brown
49

Creo que depende de su actitud. Si es un programador muy experimentado y un buen programador, creo que podría elegir un sistema de control de versiones rápidamente. Puede hablar sobre esto de dos maneras:

  • Bueno

    Nunca he usado el control de versiones, pero estoy muy emocionado de aprender, y parece que realmente ayudaría a hacer que el desarrollo sea más eficiente. No lo he necesitado tanto porque he trabajado solo en proyectos.

  • Malo

    El control de versiones es solo una palabra de moda que está muriendo lentamente en la industria. Estoy por encima del control de versiones.

Píldoras de explosión
fuente
17
Estoy de acuerdo en que podría haber sido válido hace 10 años, ¿pero hoy en día? Yo diría que no es "Bueno / Malo" sino "Malo / Horrible"
vartec
24
Incluso si está trabajando solo, usar un VCS es extremadamente valioso. Después de hacer que un proyecto pasara de "está casi funcionando" a nunca volver a funcionar correctamente, y no tener ninguna forma de volver a la versión "casi funcionando", prometí poner todo en un VCS sin importar cuán pequeño sea el proyecto .
alroc
11
"Estoy muy emocionado de aprender", este no es un producto comercial costoso como Coherence. El control de fuente es algo con lo que cualquiera puede familiarizarse. Si lee algún blog sobre desarrollo de software, debe tenerlo en cuenta.
Andy arranca el
77
+1 por esta respuesta. No es la marca de un buen programador que él / ella tiene todas las habilidades. Es que él / ella puede recoger cualquier habilidad requerida.
Steven
2
@ Steven: No. En absoluto. De acuerdo con esa lógica, un niño de 8 años podría ser contratado porque podría retomar la programación. En mi opinión, hay, o debería haber, habilidades básicas necesarias para ser considerado un programador. El dominio de un lenguaje de programación es uno, el conocimiento y el uso de cualquier VCS es otro. Hay mas.
Steven Evers
34

Permítame darle una perspectiva desde el desarrollo de software en DOS y Windows durante más de 20 años.

El software de control de versiones en el mundo de Windows / PC a menudo no era confiable a principios de mediados de los 90. Visual Sourcesafe (VSS) era el mejor basado en Windows, pero podría ser peculiar y muchos programadores lo odiaban. Algunos equipos simplemente no considerarían su uso después de lidiar con esta situación.

La mayoría de las otras opciones de VCS en ese momento no estaban basadas en Windows y, por lo tanto, rara vez se usaban en los equipos de desarrollo de Windows. Algunas de estas eran soluciones costosas y las soluciones de código abierto no eran tan aceptadas tan fácilmente como lo son hoy.

En muchos casos, a fines de los años 90, principios de los años 00, si un equipo de Windows no usaba VSS, no usaban nada para el control de la fuente aparte de las convenciones internas. Algunos de ellos todavía no usan un VCS a pesar de la sofisticación de Team Foundation Server (TFS) y excelentes opciones gratuitas como git y SVN.

Es posible que alguien que trabajó durante años en un pequeño equipo de desarrollo de Windows durante años no haya utilizado un VCS. Me entrevisté e incluso trabajé por contrato en algunos lugares que no los usaban o que estaban muy al azar sobre su uso.

Por lo tanto, no creo que la falta de experiencia de su candidato en esta área sea un "no" definitivo, pero es probable que desee profundizar en su situación laboral anterior para descubrir por qué esto no se encuentra en su experiencia. También querrás explorar su actitud hacia el control de versiones. ¿Piensan que es una buena idea pero no se les permitió seguirla en su posición anterior o creen que es una pérdida de tiempo?

jfrankcarr
fuente
18
VSS no era "peculiar", era simplemente malo. Los depósitos corruptos y la pérdida de datos eran comunes, pero es posible que no lo descubra durante semanas o meses después de que ocurriera el problema, a menos que haya realizado una verificación de integridad diaria (y buena suerte recuperándose de eso incluso en ese momento). El bloqueo y el intercambio de archivos fueron atroces. Los programadores lo odiaban porque les hacía la vida un infierno, exactamente lo contrario de lo que debería hacer un VCS.
alroc
@alroc - Créalo o no, había algunos menos confiables y más extravagantes. Tuve la desgracia de usar uno alrededor de 1995. Nunca tuve un problema serio con la confiabilidad de VSS pero escuché historias de problemas de otros. Conozco algunas organizaciones que dejaron de usar cualquier VCS después de malas experiencias con VSS.
jfrankcarr
UGGH, probamos el control de fuente de Powerbuilder en el pasado. Nos hizo perder activamente el código fuente. PB colapsaría, y cualquier pbl desprotegido se volvería inaccesible para todos los demás. Menuda broma fue aquella.
GrandmasterB
Trabajé durante 1,5 años en una tienda que usaba Visual Source Safe. Uno de los mejores programadores arruinaría el repositorio cada vez que intentara verificar su código por teléfono (sí, esto fue hace un tiempo). Uno de mis sistemas VCS menos favoritos.
GlenPeterson
Utilizamos tlib ( burtonsys.com/index.html ) en un trabajo en un entorno DOS. De acuerdo, esto fue en 2005, pero parecía que lo habían estado usando por un tiempo.
Doug T.
29

¿No puede tener control de versiones sin software de control de versiones? Pregunte cómo gestionaron su código. Quizás ya existía un sistema de cosecha propia.

Querer hacer las cosas manualmente, reinventar la rueda y resistir los cambios no son nada nuevo en la programación. ¿Vas a babear sobre un candidato que usa Visual Source Safe y "solo" VSS?

Al tratar de encontrar talento, debe ser capaz de distinguir entre: no puede, no tiene y no quiere.

JeffO
fuente
Antes de descubrir el control de versiones y su utilidad (lo descubrí después de 2 años de programación no profesional y aficionada), no era raro que tuviera cinco carpetas con "copias de seguridad" de los hitos del proyecto: un VCS primitivo.
orlp
"¿No se puede, no se hizo y no se me permitió"? He oído hablar de lugares que no aceptarían ejecutar el control de fuente porque les gustaba la jungla que eran sus unidades de red.
Philip
19

No hay excusa para no usar el control de versiones, incluso para un pequeño proyecto desarrollado por un solo desarrollador. Configurar el control de versiones local es más que trivial, los beneficios enormes Cualquier desarrollador que no sepa eso no puede considerarse bueno ni experimentado.

En cuanto a las empresas que perciben el control de versiones como "novedad", que no están dispuestas a introducir:

  • SCCS fue lanzado en 1972 (hace 40 años )
  • RCS fue lanzado en 1982 (hace 30 años ), y es completamente de código abierto y gratuito
  • CVS fue lanzado en 1990 (hace 21 años ), también de código abierto y gratuito
revs vartec
fuente
20
No estoy seguro de que SVN sea el mejor ejemplo para la configuración "más allá de lo trivial". Algunos de esos archivos que tiene que editar, directamente en el repositorio, pueden ser complicados. Configurar un DVCS local es más que trivial. Y configurar una cuenta BitBucket / GitHub y clonar repositorios a partir de ella no es mucho más complicado
pdr
9
@vartec: Lo que está más allá de lo trivial es git init. La página vinculada podría hacerme huir, ya que se siente bastante complicado.
maaartinus
77
@vartec: Yo diría que git y hg son más fáciles de entender para un novato de VCS que alguien que ha estado usando VCS centralizado durante años, y más fácil que CVCS para el novato. Simplemente mire la sección Diseño del repositorio en esa página como si aún no la entendiera. Luego piense "Tengo un repositorio aquí, quiero clonarlo aquí".
pdr
8
@vartec: Hmm. No puedo estar de acuerdo. Me gusta poder ramificar y clonar incluso cuando estoy trabajando solo. A veces tengo ideas. Y a veces son malas :).
pdr
44
He trabajado en empresas donde la gerencia rechazó el control de versiones. No era una opción. E hicimos proyectos interesantes y complejos. No creo que sea un peor desarrollador por eso. En casa tampoco lo uso, hasta ahora, aunque admito que lo he considerado.
Picarus
14

Un programador que nunca ha usado el control de versiones probablemente nunca ha cooperado con otros programadores. Probablemente nunca consideraría contratar a tal programador, independientemente de cualquier otra credencial.

JesperE
fuente
34
Estoy en desacuerdo. No usar el control de fuente requeriría un nivel mucho más alto de cooperación con otros programadores de lo normal. Incluso podría ir tan lejos como para decir que si usted ha llegado a un entorno donde no hay control de código fuente, entonces usted realmente sabe la importancia de la cooperación
Oliver-Clare
12
Esa es una declaración gloriosamente amplia y evidentemente falsa.
Murph el
3
Simplemente no quisiera contratar a un programador que no sepa cómo usar herramientas modernas. Él / ella puede saber cómo escribir código increíblemente agradable, pero consideraría que al menos el conocimiento básico del control de versiones es un requisito absoluto.
JesperE
66
Mucha gente por aquí parece ser confusa al no haber estado expuesta a VCS y se niega activamente a usarla en su nuevo trabajo. ¿Qué pasa si simplemente nunca se le ocurrió en su lugar de trabajo anterior o si la gerencia lo verboten? Dicho esto, este sería un problema crítico si estuviera haciendo la contratación, y su deseo de aprender sería un requisito difícil para mí.
György Andrasek
55
Da miedo ver a tanta gente aquí realmente encontrar la falta de control de la fuente como algo normal o aceptable.
JesperE
12

Parece una bandera roja bien, pero profundiza en por qué no la ha usado. Todavía esperaría que un desarrollador en solitario utilizara el control de versiones, especialmente en diez años, pero lo perdonaría más que si estuviera trabajando en un equipo y nunca hubiera intentado incorporar el control de versiones.

Eoin Carroll
fuente
66
+1: Me horrorizaría si estuviera desempleado simplemente porque mi gerente actual no veía la importancia del control de la fuente. Al menos hago uso de control de código fuente para todos mis proyectos personales, por lo que no sería totalmente jodido por esta situación ...
Oliver-Clare
2
@LordScree: trabajar en un sitio web de alto volumen puede ser difícil de hacer por su cuenta, pero aún puede aprender a usar el control de fuente fuera de su trabajo.
JeffO
9

No sería religioso por la falta de experiencia en el control de versiones. Es solo una herramienta. Al final, puedes aprender los conceptos básicos de svn o git en un día o dos. El resto lo recogerás con el tiempo. Y no puedo creer que ningún candidato medio decente no podría encajar si trabajara en un entorno que utiliza el control de fuente.

Usar el control de fuente es más un hábito que una habilidad. Alguien que nunca lo haya usado puede exagerar el esfuerzo requerido y subestimar los beneficios obtenidos. Después de todo, lo hizo bien hasta ahora. Solo después de que realmente use el control de fuente, crecerá para apreciarlo.

La pregunta que debe hacer es, ¿cómo se las arregló en ausencia de control de fuente? Esto podría decirle algo sobre él y cómo maneja su trabajo.

scrwtp
fuente
44
Definitivamente necesito saber cómo manejó las actualizaciones, lanzamientos, etc. sin control de versiones
ChrisF
4

Dejas mucha información sobre su experiencia.

Básicamente, diría que es muy posible que un programador pueda tener 10-15 años de experiencia sin tener que saber sobre el control de versiones. La codificación durante 10 años no equivale a aprender constantemente nuevas técnicas de programación durante 10 años.

Soy muy joven y he visto ingenieros de software viejos y "experimentados" cuyo código nunca quisiera tocar. Dicho esto, podría ser muy talentoso, pero supongo por la poca información dada que no lo es.

Buena suerte.

cubsink
fuente
4

Personalmente, lo más alarmante para mí es que el candidato nunca ha encontrado un sistema de control de versiones como concepto, o ha decidido que no vale la pena usarlo. Creo que el primer escenario es altamente improbable, pero si ese es el caso, entonces me lleva a asumir que el candidato ha estado significativamente aislado durante la duración de su carrera, lo que arrojaría serias dudas sobre su valor como parte de un equipo. Específicamente, pueden ser conceptos muy extraños sobre cómo hacer ciertas cosas y no conocer ninguna de las formas "correctas" de hacer las cosas.

Si es el segundo caso, donde han decidido activamente en contra del control de versiones, entonces me hace suponer que nunca trabajaron en algo significativo o que son extremadamente arrogantes. O, en el mejor de los casos, tienen formas realmente terribles de mantener el código, como comentar bloques y atribuir cada línea de código a un autor, fecha y número de error.

brianmearns
fuente
4

Estoy viendo algunas respuestas bastante críticas aquí que en realidad no tienen en cuenta a la persona que se está juzgando.

Personalmente, considero que el software de control de versiones es una herramienta invaluable. Pero no todos tenemos opciones y control sobre las herramientas y procesos que se utilizan en nuestros entornos de trabajo. He trabajado en el desarrollo de Windows desde 1990. Según lo publicado por otros, en ese momento no había mucho disponible para VCS en Windows. No íbamos a traer servidores UNIX solo para obtener un VCS. ¿Eso me hizo un mal programador? Más adelante en mi carrera, trabajé para una empresa con un producto comercial de mercado vertical donde el control de versiones era un proceso, no una herramienta. ¿Eso me hizo un mal programador? Mis últimos tres trabajos se han basado en gran medida en las herramientas de VCS. ¿Eso me hace un buen programador?

Sería genial si todos pudiéramos usar solo las últimas y mejores herramientas, idiomas y tecnologías. Pero la profesión del desarrollo de software no siempre funciona de esa manera. Es un poco idealista decir "Dejaría el trabajo inmediatamente, si no lo hicieran ..." o "Nunca tomaría un trabajo que no usara ..." o "Los obligaría a usar. .. ". No todos estamos rodeados de una oferta infinita de oportunidades de trabajo donde todo funciona exactamente como queremos. Tenemos facturas que pagar y necesitamos un trabajo, por lo que nos ocupamos de lo que nos rodea.

Al final, la respuesta a su pregunta es la siguiente: juzgue a este programador por sus habilidades, sus filosofías y sus decisiones, no por las decisiones (posiblemente equivocadas) tomadas por las personas a cargo de sus trabajos anteriores.

cdkMoose
fuente
44
Si solo ha trabajado con idiotas durante 15 años y no ha hecho ninguna fuente abierta inteligente, eso probablemente se reflejará en su conjunto de habilidades y actitud. Las personas son moldeadas por sus entornos. Si ese no fuera el caso, ¿por qué siquiera miraríamos el historial laboral de alguien?
Kaz
@Kaz Miramos su historial de empleo no por sus aportes de los compañeros de trabajo sino por los suyos. No puedo juzgar a alguien en el área donde crecieron; de lo contrario, podríamos comenzar a entrevistar a los vecinos también.
James Khoury
Formados por nuestros entornos, sí, pero nuestros entornos no nos definen. Solo estoy sugiriendo que OP tome una vista completa del programador y no haga un juicio severo basado en un criterio.
cdkMoose
4

Nunca me consideré un "programador" hasta que comencé a ganar dinero haciéndolo profesionalmente.

He ganado bastante dinero creando sistemas que hicieron que los clientes ganaran aún más dinero. Si soy o no un "buen" desarrollador es subjetivo.

Puedo GSD (hacer algo) rápidamente, lo que para el desarrollo web generalmente ha complacido a mis clientes. Es posible que no vean algún código feo detrás de escena, falta de comentarios, etc.

No había usado Git y no tenía un perfil de Github hasta este año, lo que creo que está "atrasado" en términos de los estándares modernos de programación. También acabo de empezar a hacer proyectos Rails y Django después de haber hecho PHP, Flash e iOS en el pasado. Desde entonces obtuve contratos de desarrollo de sitios tanto para clientes como para mí, no ha sido demasiado doloroso aprender algo nuevo a los 30 años de edad y algunos años fuera de la programación.

Demasiado en la sociedad moderna se enfoca en mantenerse al día con los Jones y preocuparse por lo que otras personas piensan. Si puede romper esos grilletes y considerar lo que necesita para su desarrollo de software (velocidad / tiempo de comercialización, administración de recursos optimizada, código bien documentado, escalabilidad, etc.), entonces eso puede ser mucho más importante que si alguien conoce Mercurial, SVN , Git o cualquier otro sistema de control de versiones.

Prefiero preguntar a los candidatos a desarrolladores qué les apasiona, cuál es el sistema más genial que han hecho en su propia opinión y en qué dedican su tiempo libre a desarrollar sus habilidades. Si las personas no avanzan sus habilidades en su propio tiempo, eso me asusta más que otras cosas, pero no significa que tenga que asustarte.

Creo que ya tiene algunas excelentes respuestas a esta pregunta de parte de la gente de aquí y eso debería ayudarlo a tomar su propia decisión informada en función de sus requisitos.

ljs.dev
fuente
2

Me parece increíble que un profesional de software nunca haya usado el control de fuente, y estaría muy nervioso por contratarlo.

Qué experiencia tiene él. Me pregunto qué más no sabe que hasta ahora no has descubierto.

¿Cuál es su experiencia de desarrollo de software usted mismo? ¿Está en condiciones de preguntarle sobre arquitectura, patrones de diseño, problemas comunes de desarrollo de software, preguntas de rendimiento del sistema, preguntas de seguridad del sistema, etc.?

Si salió fuerte en ese tipo de cosas, entonces tal vez podría pasar por alto la falta de conocimiento sobre el control de la fuente.

ozz
fuente
2

¿Es posible que un buen programador nunca haya usado el control de versiones?

Si. Muchas pequeñas empresas con programadores autodidactas no lo usan.

¿Cómo es posible desarrollar software activamente durante 10-15 años sin necesidad de control de versiones?

Personalmente, presenté el control de versiones a 2 pequeñas empresas, actualicé 1 compañía mediana de algo horrible a SVN (la mejor opción en ese momento) y trabajé en otra pequeña compañía que solo tenía algo de VC, escribí su propia solución de VC para algún código y tenía mucho código simplemente no en ningún VC.

¿El hecho en sí mismo de no buscar una solución al problema del seguimiento cambia un signo de una actitud incorrecta hacia la programación?

Bueno, no es un fracaso instantáneo, pero sin duda estaría haciendo muchas preguntas de seguimiento. Cosas como:

¿Alguna vez has probado algún software de VC? ¿Qué? ¿Que piensas de eso? ¿Hay alguna razón por la que no lo usarías? ¿Qué has usado antes para administrar el código? ¿Has trabajado antes con alguien en la misma base de código y qué métodos utilizaste para evitar enfrentamientos?

James
fuente
1
Nada nuevo en esta respuesta.
pdr
1
Los programadores autodidactas inteligentes de hoy en día saben todo sobre el control de versiones y lo usan. El resto tiene la cabeza atrapada en alguna parte.
Kaz
@Kaz no estoy de acuerdo. Creo que eso es lo que nos gusta pensar, pero he conocido a programadores que consideraría inteligentes y que no lo hicieron, como dice mi experiencia personal. No usar el control de versiones es una gran señal de advertencia de que podrían tener la cabeza atrapada en algún lugar [frase encantadora :-)] pero no siempre es así.
James
2

Me gustaría estar de acuerdo con las píldoras de explosión (pero mi representante es demasiado bajo, cajero automático ...) ... la actitud es mucho más importante.

Hay algunas cosas a tener en cuenta, que creo que contribuyen a la excelencia de la programación:

  1. Comunicación
  2. Creatividad
  3. Compasión (¿decir qué?)

Y, a menudo, más que un poco de TOC.

Ya sabes el tipo ... los que se sientan allí martillando un problema, perdiéndose completamente en su código mientras exploran opciones. Estos son los que toman notas a medida que avanzan, dejan comentarios en su código para asegurarse de que entienden sus propios caminos lógicos (y para iluminar el camino para ellos mismos u otros programadores que puedan tener que lidiar con el código en el futuro. .. por lo tanto, "compasión" en mi lista de arriba!), y rápida y claramente transmitir ideas complejas a los tomadores de decisiones en la cadena para que los problemas puedan abordarse de manera eficiente.

Un programador excelente puede haber estado atrapado durante años en un entorno que no aceptaba la idea de VCS, tuvo malas experiencias con VCS (a la VSS), lo que los hizo tímidos para probar nuevos sistemas, pero le garantizo que un programador excelente en esa situación todavía habría establecido algún tipo de rutina para protegerse de perder todo su trabajo en un par de iteraciones de diseño erróneas.

Por lo tanto, el tipo de programador del que hay que tener cuidado es el que afirma que nunca ha necesitado VCS, ni ninguna medida de protección contra los inevitables errores. Su actitud es de "bueno, lo construí, por lo tanto, no puede estar equivocado". Esos son los que más temo que cualquier noviciado recién salido de la universidad, porque un novato puede aprender a apreciar las fortalezas de VCS porque se dan cuenta de lo poco que realmente saben.

Jason M. Batchelor
fuente
2

¿Cómo es posible desarrollar software activamente durante 10-15 años sin necesidad de control de versiones?

Si viene de equipos de la vieja escuela donde los proyectos pequeños son administrados por una sola persona, es muy posible. Puede tener 10 años de experiencia en el mismo conjunto de tecnología sin aprender y mejorar.

¿El hecho en sí mismo de no buscar una solución al problema del seguimiento cambia un signo de una actitud incorrecta hacia la programación?

Si su candidato ha estado en un entorno de desarrollo de equipo (al menos 4 o más programadores), entonces es una pregunta trivial. Sin embargo, puede haber una división de trabajo entre programadores, trabajados en módulos asignados únicamente a ellos, lo que puede reducir la necesidad de controlar el código fuente.

Sin embargo, no ser escuchado sobre el control de fuentes en la era de Internet es una situación realmente sorprendente. Por lo tanto, vería su disposición a aprender cosas nuevas (en relación con su entorno de desarrollo) y qué tan abierto está a un entorno de trabajo dinámico.

revs ElYusubov
fuente
No todos leen blogs de programación / etc. En particular, alguien cuya carrera ha sido completamente con una única plataforma heredada no va a encontrar mucho valor inmediato de ellos. ¿De cuántos blogs de software Mainframe / COBOL / RPG (no de juegos) conoce? La programación de esas plataformas realmente no ha cambiado mucho en los últimos 30 años, y muchas de las mejores fuentes de información para ellas casi seguramente todavía están en formato de árbol muerto. Si la programación es su trabajo, en comparación con lo que gira su vida, cuando trabaje en esas áreas leer blogs de tecnología, etc., no tendrá un ROI a corto plazo.
Dan Neely
1
Incluso en un proyecto de una persona, se beneficia del control de versiones. Si se encuentra un error, puede indicar "que se introdujo en la versión 3.13", por lo que los usuarios de 3.13 y posteriores se ven afectados. También puede hacer fácilmente un parche para varias versiones, para personas que no desean migrar a la última. Si puede hacer estas cosas sin control de versiones, entonces está haciendo un control de versiones ad hoc de facto. Espera que sus usuarios usen su software para eliminar el trabajo manual laborioso y propenso a errores, pero usted, el programador, ¡no lo haga usted mismo! Jajaja
Kaz
2

La experiencia importa y tiene razón en que la mecánica del uso de herramientas de control de código fuente se puede aprender con bastante rapidez. Pero tienes razón al ver una bandera roja.

  • ¿Está su candidato aislado de la profesión y sus tendencias?
  • ¿También se deberán aprender los muchos otros aspectos del trabajo en equipo?

Para mí, el problema del control de versiones es más un síntoma que la enfermedad. La causa puede variar y ser bastante benigna. Muchos programadores ad-hoc comenzaron a hacer lo que pensaban que tenía sentido, comenzando con algunos libros sobre programación, y no hicieron un estudio sistemático del desarrollo de software. A veces, más aún en los viejos tiempos, los graduados en ciencias de la computación se graduarían sin haber usado un sistema de control de fuente porque todos sus proyectos eran proyectos individuales y se dirigían a empresas con procesos de software muy inmaduros.

Sin embargo, llegó allí, si ha sido un lobo solitario durante una década o más, puede ser difícil vivir con personas.

Puede valer la pena preguntarle a su candidato algunas preguntas más de sondeo.

  • ¿Cuéntame sobre alguna vez que trabajaste como parte de un equipo?
  • ¿Cuéntame sobre un momento en que un equipo en el que trabajaste tuvo un conflicto entre los miembros del equipo?
  • ¿Cuénteme sobre un momento en que recibió código de otro desarrollador y llevó adelante su proyecto?
  • ¿Cuéntame cómo tú y otros miembros de tu equipo se mantuvieron al margen cuando crearon código juntos?
  • ¿Cuénteme acerca de un problema informado por un cliente relacionado con una función que solía funcionar, pero que no funcionó en una versión posterior? ¿Cómo lo resolviste?
  • ¿Qué te gusta de trabajar en equipo?

También puede estar acostumbrado a tener un control casi completo sobre sus métodos, procesos y desempeñar un papel en el que es el único experto en software. Querrás a alguien que esté abierto a una nueva forma de hacer las cosas. Más preguntas:

  • ¿Cuéntame sobre una vez que usaste o ayudaste a crear un estándar de codificación?
  • ¿Qué tipo de cosas quieres ver en un estándar de codificación?
  • ¿Cómo te sientes al volver a escribir el código de otra persona?
  • ¿Cuéntame sobre una vez que estuviste involucrado en revisiones por pares de software o documentación?
  • ¿Me puede decir acerca de una propuesta o contrato para el desarrollo de software que estuvo involucrado por escrito?
  • ¿Cuéntame sobre tu administrador o supervisor de software favorito?
  • ¿Cuéntame sobre tu compañero de trabajo favorito o subordinado?
DesarrolladorDon
fuente
2

En el año 2012, para alguien con 15 años de experiencia en la industria que nunca haya usado el control de versiones es una señal de alerta. Podría no ser una señal de alerta si el año fuera 1982, o incluso 1992. Pero hoy, es mejor que haya una excelente explicación para esta brecha desconcertante en los antecedentes de ese desarrollador.

Las situaciones extraordinarias requieren explicaciones extraordinarias.

Esto es algo así como un mecánico de automóviles que afirma que ha estado reparando automóviles durante 15 años, pero que nunca se engrasó.

Por supuesto, untarlo con grasa no arreglará una transmisión, y ninguno de los pasos en el manual de reparación requiere tal cosa, pero ese no es el punto. El punto es que estar completamente limpio es enormemente inconsistente con la apariencia de la mecánica del automóvil cuando están trabajando. En ese trabajo, te engordas a ti mismo.

Si está entrevistando a alguien experimentado que admite que no tiene experiencia en el control de versiones, probablemente esté exagerando o fabricando parte de su experiencia (¡y ni siquiera sabe que el control de versiones es algo ampliamente utilizado e importante, y algo sobre lo que también debe mentir! )

Es posible ver todo tipo de bromistas en las entrevistas. He visto personas que no pueden dibujar un diagrama de una lista vinculada, o escribir una función que inserte un nodo al principio de una lista vinculada. Sin embargo, reclamaron 20 años de experiencia laboral.

Se puede esperar que incluso los nuevos graduados de la informática tengan una familiaridad pasiva con el control de versiones, incluso si aún no lo han utilizado ampliamente.

Kaz
fuente
Lo mejor que siempre puede esperar de los nuevos graduados es: "Oh, he oído hablar de eso". Tuvimos una introducción de una semana de lo que era, basado en Subversion, pero nunca usamos el control de versiones para nada.
Izkata
Sí, y como son recién graduados, "compramos" eso y seguimos adelante.
Kaz
"familiaridad pasajera" (lo que creo que quisiste decir en la respuesta) implica que lo han usado en algún momento; Estoy señalando que ni siquiera puedes esperar eso.
Izkata
Diría que si los graduados de CS no han utilizado el control de versiones, entonces el departamento de su alma mater no ha implementado un curso de ingeniería de software adecuado y obligatorio en el que los estudiantes de grado no solo aprendan sobre conceptos de ingeniería de software, sino que también trabajen en un proyecto de equipo (con versión control y todo). Me gustaría tener una o dos palabras con el jefe de ese departamento.
Kaz
He estado programando profesionalmente durante casi 20 años. Sé qué es una lista vinculada y por qué se utilizarían. He Nunca usado, y probablemente luchar con los puntos más finos de la escritura de su función. Creo que solo porque usas técnicas de 30 años, decir que todos los demás deberían es un poco injusto.
DefenestrationDay
1

Me resultaría extraño, pero no imposible que un programa experimentado nunca haya utilizado un control de fuente dedicado. En una empresa con la que trabajé, utilizaron el control de origen ampliamente para su código tradicional C # y VB. Pero el código puro de la base de datos (procedimientos y scripts almacenados, así como las definiciones de tabla) no estaban bajo el control de la fuente a pesar de tener dos desarrolladores SQL profesionales cuyo trabajo principal era escribir, mantener y ejecutar código de base de datos puro. Defendí el control de origen para las entidades de la base de datos allí y solo tuve un éxito parcial.

En otra compañía, el equipo de desarrollo era pequeño (un hombre compró durante mucho tiempo, luego dos). El control de origen del desarrollador anterior era tener múltiples copias de los archivos de origen con una fecha agregada al final. Además de carecer de un mejor sistema de control de fuente, mi predecesor allí era definitivamente competente y un hombre inteligente.

Antes de convertirme en profesional, era aficionado y no utilizaba ningún control de fuente, sabía vagamente de qué se trataba pero no me molesté.

En resumen, creo que es extraño que un profesional no esté muy familiarizado con él, pero especialmente si está acostumbrado a equipos muy pequeños, sin duda es posible ser competente sin él. Al contratar, no sostendría eso contra él. Sin embargo, me resistiría absolutamente a aprender y comenzar a usarlo en el trabajo contra él ...

TimothyAWiseman
fuente
solicite al DBA que genere scripts SQL a partir de la base de datos y luego puede poner los scripts en el control de origen.
linquize
@linquize Oh estuvo de acuerdo. Esa es una de las mejores formas de hacerlo (aunque no es la única). Simplemente menciono que he conocido a muchos profesionales competentes y un aficionado experto que no tenía experiencia con el control de fuente, especialmente en el lado de DBA. Al contratar, me resistiría a aprender el control de la fuente contra un nuevo empleado potencial, pero no me sorprendería demasiado no haberlo usado antes, especialmente si estaban acostumbrados a un equipo pequeño y estaban principalmente en el lado de la base de datos.
TimothyAWiseman
1

Mi propio 2c es que depende de cómo reaccionó cuando le preguntaron sobre VC. Las posibles reacciones pueden ser:

  1. ¿Eh? Que es eso
  2. No lo hicimos en su lugar
  3. Sin barajar avergonzado , la administración no nos permitiría
  4. Sin barajar avergonzado , pero yo mismo investigué un poco y pensé que parecía algo que deberíamos estar haciendo.

En el caso de 4, el tipo recibiría un pase de mí, tiene la actitud correcta y probablemente lo tomará bien. En el caso de 3, obtiene crédito por entender que es algo que se debe hacer, pero no tanto como 4. Si pudo nombrar un par de factoids sobre VC (enumere algunos de los paquetes de VC que existen) I ' tomaría eso como evidencia de cierta curiosidad y podría pasarlo por alto.

Si él respondió 1 o 2, es decir, si él supiera y no quisiera saber sobre VC, cuestionaría seriamente el juicio del candidato. Habrá otras herramientas (seguimiento de errores, métricas de calidad, automatización de compilación, etc.) con las que tendrá que trabajar y probablemente encontrará que tiene una batalla cuesta arriba en todos estos problemas si no está abierto a probar nuevos enfoques.

Como la mayoría de las personas aquí, creo que sería injusto perjudicar al candidato solo porque su empleador no estaba al día; Para mí, todo depende de cómo reaccionaron.

PhilDin
fuente
1

Escribir lo que ha cambiado es bueno cuando se mira hacia atrás. Me ha salvado muchas veces al calcular lo que está mal y muchos problemas se solucionaron rápidamente porque lo tenía escrito. En mi opinión, es bueno mantener un registro. Especialmente si está programando con más personas que usted.

Si está escribiendo una aplicación web, puede seguir agregando funciones sin control de versiones porque constantemente está agregando cosas nuevas. Pero tal vez escriba un registro o una publicación de noticias con las cosas nuevas.

Se trata de lo que estás programando.

Jason Stackhouse
fuente
0

He trabajado en lugares donde el proceso de aprobación del software fue de 12 a 18 meses. Si aún no estaba en la lista de software aprobado, no había forma de ponerlo en las máquinas. Las unidades de CD / DVD estaban bloqueadas y las máquinas no estaban conectadas a Internet.

El primer lugar en el que encontré el control de código fuente fue que un desarrollador escribiera el suyo, para cuando estuviera listo para probar el proyecto de varios años se estaba terminando. Apostaron a que escribirlo desde cero era más rápido que el proceso de aprobación.

El segundo lugar en el que me encontré con este problema sí utilizó el control de fuente durante los primeros meses, pero luego el cliente quería que todo el desarrollo se realizara en su red interna. Nuevamente bloquearon todo, por lo que volvieron a muchas carpetas comprimidas.

Conozco desarrolladores que solo han trabajado en estas condiciones. Quieren usar estas herramientas, les encantaría usar estas herramientas, pero no se les permite usar estas herramientas.

Investigue por qué no los han usado. No entender los procedimientos debido a la experiencia cero, es muy diferente a rechazar las herramientas.

mhoran_psprep
fuente
Nada nuevo en esta respuesta.
pdr
0

Estoy desarrollando durante los últimos 15 años. Usé el control de versiones solo unas pocas veces. Todavía estoy usando mis propios scripts y programas programados para hacer una copia de seguridad de todas las carpetas de desarrollo de forma incremental. No sé qué decir si alguien me pregunta si uso el Control de versiones. Nunca he necesitado un sistema de control de versiones, siempre trabajé en pequeños proyectos. Quiero decir que no soy el mejor programador, pero estoy seguro de que no soy el peor. La mayoría de las veces me da vergüenza decirle a la gente que no uso regularmente el sistema de control de versiones, pero así es para mí.

Entonces
fuente
He tenido una experiencia opuesta: algunas personas me dan una mirada divertida cuando digo que uso el control de versiones en pequeños proyectos donde soy el único desarrollador. Tal vez menos hoy en día, porque el control de versiones se usa para alojar proyectos de código abierto y, por lo tanto, se entiende como un método de implementación.
Kaz
2
Debería cambiar su actitud y analizar el control de versiones porque le permite hacer muchas cosas fácilmente. Por ejemplo, el gitsistema de control de versiones tiene un flujo de trabajo automatizado ( git bisect) para encontrar un error de regresión. Esto realiza la búsqueda binaria a través del historial de versiones de un proyecto para tratar de encontrar el conjunto de cambios que introdujo el error. Todo lo que debe hacer es reconstruir, ejecutar su prueba e informar gitsi fue buena o mala; luego selecciona y recupera la línea de base que se probará a continuación.
Kaz
En gitpuedes hacer algunos cambios experimentales y luego ponerlos en a stash. Su trabajo se revierte al original y se guardan los cambios. Más tarde, puede explorar su alijo y volver a aplicar esos cambios para seguir experimentando con ellos, o tirarlos. Y, por supuesto, cualquier sistema de control de versiones decente tiene ramificaciones, con las cuales puede hacer cosas como desarrollar una característica, aisladamente, de una versión estable. O regrese y corrija un error en una versión (para dar un parche a los clientes) y combine fácilmente ese cambio con la versión de desarrollo actual también.
Kaz
0

Hablando desde mi experiencia como programador en sistemas IBM MVS: durante los primeros diez años de mi carrera laboral, el sistema operativo con el que trabajé tenía exactamente un tipo de archivo versionable disponible para el programador: el conjunto de datos de generación. Esto era esencialmente un archivo con un número fijo de versiones, y tenía que recordar qué versión era qué, prácticamente inútil para el control de versiones moderno. Junto con un sistema de archivos que no tenía directorios reales, solo más o menos calificadores (de 8 caracteres), el concepto de un sistema de administración de código fuente era completamente extraño para cualquiera que trabajara en ese entorno.

En realidad, no vi un sistema de control de código fuente hasta que me mudé a SunOS 3 y pude usar RCS. En ese momento era un programador de sistemas de IBM extremadamente fácil, altamente productivo y muy bueno en mi trabajo. Todas las versiones se manejaron copiando copias de seguridad en cinta y registrando dónde estaba.

Si todavía estuviera trabajando en mainframes en este momento, es muy posible que aún no haya estado expuesto a un sistema formal de control de versiones; Las alternativas que se admiten específicamente son ClearCase y Rational, ninguna de las cuales es gratuita (y de hecho ambas son bastante caras).

Entonces decir que alguien es incompetente por definición porque nunca ha usado el control de versiones es un argumento engañoso. Es necesario profundizar y mirar los detalles. Si afirman ser un desarrollador de Linux / Unix / Mac OS pero nunca han utilizado el control de versiones, eso les habla mal, y es posible que tenga que sopesar si su experiencia general es tan buena que estaría dispuesto a hacerlo. capacitarlos en ingeniería de software moderna. Si son un programador de mainframe de la vieja escuela, y eso es lo que necesita, entonces concéntrese en si tienen exactamente las habilidades de programación necesarias que desea, y resignarse al hecho de que tendrá que enseñarles esto. Como otros han dicho, su respuesta al concepto será el factor decisivo en ese caso.

Joe McMahon
fuente
0

¡Bastante por favor! La totalidad de nuestra comunidad no vive en comunidades sociales altamente desarrolladas donde los lugares de reunión geek y los eventos hacky son demasiado abundantes, tampoco trabajamos en compañías de desarrollo de software y algunos de nosotros ni siquiera podemos encontrar recursos publicados relevantes o actualizados. en nuestros idiomas nativos, impresos o en línea, siempre encontremos un compañero programador en la carne.

Por lo que puedo entender, si él es un desarrollador de software experimentado como usted dice, entonces probablemente haya sido un lobo solitario trabajando como freelance para pequeñas empresas.

Filip Dupanović
fuente
-1

Hay algunas razones posibles para no usar el control de versiones:

  1. Trabajando en compañías que no están desarrollando software como su principal línea de negocios.
  2. O si el desarrollador ha decidido utilizar algún otro sistema, solo válido para los experimentados.
  3. O si el desarrollador aún no ha aprendido cómo funciona cada sistema
  4. O es un problema de actitud contra las herramientas que no conocen

Pero debe tener cuidado cuando conozca a personas que asumen:

  1. Que solo hay una manera de hacer algo
  2. O que cada programador debe hacerlo de la misma manera que lo hace
  3. O que las prácticas que utilizan las personas son fáciles de cambiar
tp1
fuente
-2

De la misma manera que es posible que un programador pobre sea un experto en control de versiones. Mi punto es que no sé qué hace el control de versiones para tus habilidades de programación o para resolver problemas. Es una cuestión de experiencia. Muchas tiendas más pequeñas no lo usan o lo dejan en manos de los indaviduals (que a menudo trabajan solos) para que lo descubran por sí mismos.

aserwin
fuente
-2

Creo que no se trata tanto de "¿Cómo es posible desarrollar software activamente durante 10-15 años sin necesidad de control de versiones?", Sino de "¿Cómo es posible desarrollar software activamente durante los últimos 10-15 años sin tener que hacerlo? necesita control de versiones?

La programación segura es posible sin control de versiones, pero un profesional debe estar familiarizado con el estado actual de la técnica y poder seleccionar las herramientas adecuadas para hacer el trabajo. Si no utiliza el software de administración de versiones apropiado, su trabajo es arriesgado y poco confiable, y una de las razones por las que desea contratar a un desarrollador profesional es que deberían poder administrar el riesgo.

Un código base que está anotado correctamente en un VCS vale mucho más que uno que no lo es. El motivo de cada cambio puede rastrearse y entenderse, lo que hace posible que los encargados del mantenimiento tengan una comprensión más profunda de lo que necesitan saber. No hacerlo no es profesional, y la única excusa para ello sería si él / ella hubiera sido limitado por gerentes pobres en su trabajo anterior. Incluso entonces, ¿no deberían haber usado versiones para sus proyectos privados?

Dominic Cronin
fuente