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

Trabajé durante aproximadamente 11 años en compañías que no usaban el control de código fuente. 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 ocurrió 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.

Lucho para ver cómo puedes pasar más de 10 años en la industria ahora sin haberte encontrado con el control de código fuente. Pero, tendría algo de simpatía, creería que era posible y no rechazaría al candidato solo con ese detalle. Yo 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 fue el mejor candidato? ¿Hay otras técnicas modernas de programación que él no tenga, para las que 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 alguna inquietud. Para volver a empezar se requiere mucho tiempo, pero es más lento contratar a la persona incorrecta.

Creo que depende de su actitud. Si él es un programador muy experimentado y un buen programador, creo que sería capaz de adquirir un sistema de control de versiones rápidamente. Puede hablar de ello 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 se está muriendo lentamente en la industria. Estoy por encima del control de versiones.

Permítame darle una perspectiva del 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 la década de los 90. Visual Sourcesafe (VSS) era el mejor basado en Windows, pero podía ser peculiar y muchos programadores lo odiaban. Algunos equipos simplemente no entretendrí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 soluciones eran costosas y las soluciones de código abierto no fueron tan aceptadas como lo son hoy.

En muchos casos, a fines de los 90, a principios de los 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 aún no usan un VCS a pesar de la sofisticación de Team Foundation Server (TFS) y las excelentes opciones gratuitas como git y SVN.

Es posible que alguien que haya trabajado durante años en un pequeño equipo de desarrollo de Windows no haya utilizado un VCS durante años. He entrevistado e incluso he realizado trabajos por contrato en algunos lugares que no los usaban o que eran muy imprecisos acerca de 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 más 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ó seguir en su posición anterior o creen que es una pérdida de tiempo?

¿No puede tener el control de versiones sin el software de control de versiones? pregunte cómo administraron su código. Tal vez ya existía un sistema propio.

Querer hacer las cosas manualmente, reinventar la rueda y ser resistente al cambio no son nada nuevo para la programación. ¿Vas a babear sobre un candidato que usa Visual Source Safe y "solo" VSS?

Cuando intentas encontrar talento, debes poder distinguir la diferencia entre: no puedes, no quieres y no.

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

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

• SCCS se lanzó en 1972 ( hace 40 años )
• RCS se lanzó en 1982 ( hace 30 años ), y es completamente de código abierto y gratuito
• CVS se lanzó en 1990 ( hace 21 años ), también de código abierto y gratuito

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

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

No sería religioso por la falta de experiencia en el control de versiones. Es solo una herramienta. Al final, puede aprender lo básico de svn o git en uno o dos días. El resto lo recogerás con el tiempo. Y no puedo creer que un candidato medio decente no podría encajar si trabajara en un entorno que utiliza el control de código fuente.

Usar el control de código fuente es más un hábito que una habilidad. Alguien que nunca lo ha 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 código fuente, crecerá para apreciarlo.

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

Dejas mucha información sobre su experiencia.

Básicamente, diría que es muy posible que un programador tenga 10-15 años de experiencia sin tener que conocer el control de versiones. Codificar 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 antiguos y "experimentados" cuyo código nunca querría tocar. Dicho esto, podría ser muy talentoso, pero supongo por la poca información, dado que no lo es.

Buena suerte.

Personalmente, lo más alarmante para mí es que el candidato nunca ha encontrado los sistemas de control de versiones como un concepto, o ha decidido que no vale la pena utilizarlo. Considero que el primer escenario es altamente improbable, pero si ese es el caso, entonces me lleva a suponer que el candidato ha estado significativamente aislado durante toda 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, en el que decidieron activamente en contra del control de versiones, entonces asumo que o nunca trabajaron en algo de importancia, o son extremadamente arrogantes. O, en el mejor de los casos, tienen formas realmente terribles de mantener el código, como comentar los bloques y atribuir cada línea de código a un autor, fecha y número de error.

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

Personalmente, considero que el software de control de versiones es una herramienta invaluable. Pero, no todos tenemos opciones y controles sobre las herramientas y los 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 VCS. ¿Eso me hace un buen programador?

Sería fantástico si todos pudiéramos utilizar solo las herramientas, los idiomas y las tecnologías más recientes y mejores. Pero la profesión de 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 aceptaría un trabajo que no usara ..." o "los obligaría a usarlo". .. ". No todos estamos rodeados por una oferta infinita de oportunidades laborales 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 las decisiones (posiblemente erróneas) tomadas por las personas a cargo en sus trabajos anteriores.

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

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

Puedo GSD (Get Something Done) rápidamente, lo cual para el desarrollo web generalmente ha complacido a mis clientes. Es posible que no vean un 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, que creo que está muy "atrasado" en términos de estándares de programación modernos. También empecé a hacer proyectos de Rails y Django después de haber hecho solo PHP, Flash e iOS en el pasado. Desde entonces obtuve contratos para desarrollar sitios tanto para clientes como para mí, no ha sido demasiado doloroso aprender algo nuevo a los 30 años de edad y unos pocos años sin programar.

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

Prefiero preguntar a los candidatos a los desarrolladores qué es lo que les apasiona, cuál es el mejor sistema que han creado en su propia opinión y en qué pasan su tiempo libre desarrollando 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 tienes algunas respuestas geniales a esta pregunta de parte de la gente de aquí y eso debería ayudarte a tomar tu propia decisión informada en función de tus requisitos.

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

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

¿Cuál es tu experiencia de desarrollo de software? ¿Está en posición de preguntarle sobre arquitectura, patrones de diseño, problemas comunes de desarrollo de software, preguntas sobre el rendimiento del sistema, preguntas sobre la seguridad del sistema, etc.?

Si salió fuerte en ese tipo de cosas, quizás podría pasar por alto la falta de conocimiento de control de fuente.

  

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

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

  

¿Cómo es posible desarrollar software de forma activa durante 10 a 15 años sin necesitar nunca el control de versiones?

Personalmente, introduje el control de versiones a 2 compañías pequeñas, actualicé 1 compañía mediana de algo horrible a SVN (la mejor opción en ese momento) y trabajé en otra compañía pequeña que solo tenía algo de VC, escribió su propia solución de VC para Algunos códigos y muchos códigos simplemente no están en ningún VC.

  

¿El hecho mismo de no buscar una solución al problema del seguimiento de los cambios es un signo de una actitud equivocada en la programación?

Bueno, no es un error 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 con alguien antes en el mismo código? base, y que métodos usaste para evitar choques?

Me gustaría estar de acuerdo con Explosion Pills (pero mi reputación es demasiado baja, atm ...) ... la actitud es mucho más importante.

Hay algunas cosas que buscar, que creo que hacen para la excelencia de la programación:

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

Y, a menudo, más que un pequeño TOC.

Sabes el tipo ... los que están sentados ahí tratando de resolver un problema, perdiéndose completamente en su código mientras exploran las opciones. Estos son los que toman notas a medida que avanzan, dejan comentarios en su código para asegurarse de que comprenden sus propias rutas lógicas (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 anterior!), y transmita de manera rápida y clara ideas complejas a los tomadores de decisiones en la cadena para que los problemas se puedan abordar de manera eficiente.

Un programador excelente pudo haberse quedado estancado durante años en un entorno que no aceptaba la idea de VCS, tuvo malas experiencias con VCS (a la VSS), lo que hizo que no se atrevieran a probar nuevos sistemas, pero garantizaría que un excelente programador en esa situación aún hubiera establecido algún tipo de rutina para protegerse de perder todo su trabajo ante un par de iteraciones de diseño incorrecto.

El tipo de programador a tener en cuenta, por lo tanto, es el que afirma no haber necesitado VCS, ni ninguna medida de protección contra los inevitables errores. Su actitud es de "bueno, la construí, por lo tanto, no puede estar equivocada". Esos son los que más temo que cualquier noviciado que sale de la universidad, porque un principiante puede aprender a apreciar las fortalezas de VCS porque se da cuenta de lo poco que saben.

  

¿Cómo es posible desarrollar software de forma activa durante 10 a 15 años sin necesitar nunca el 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 mismo de no buscar una solución al problema del seguimiento de los cambios es un signo de una actitud equivocada en la programación?

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

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

La experiencia es importante y tiene razón en que la mecánica de usar las herramientas de control de origen 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?
• ¿Deberán aprenderse 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 empezaron a hacer lo que pensaban que tenía sentido, empezaron con algunos libros sobre programación y no hicieron un estudio sistemático del desarrollo de software. A veces, más en los viejos tiempos, las carreras de informática se graduaban 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 altamente inmaduros.

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

Podría valer la pena preguntar si su candidato tiene algunas preguntas más de sondeo.

• Hábleme de alguna vez que trabajó como parte de un equipo?
• Háblame de un momento en que un equipo en el que trabajaste tuvo un conflicto entre los miembros del equipo.
• Hábleme de un momento en que recibió el código de otro desarrollador y siguió adelante con su proyecto.
• Dígame cómo usted y otros miembros de su equipo se mantuvieron alejados de los demás al crear código juntos.
• Háblame sobre un problema reportado por un cliente relacionado con una característica que solía funcionar, pero ¿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 estar en una función en la 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:

• Hábleme de alguna vez que usó o ayudó 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 reescribir el código de otra persona?
• Hábleme de alguna vez que estuvo involucrado en revisiones de software o documentación por parte de otros expertos.
• ¿Puede informarme sobre una propuesta o contrato para el desarrollo de software en el que participó por escrito?
• Hábleme de su administrador o supervisor de software favorito?
• Hábleme de su compañero de trabajo o subordinado favorito.

En el año 2012, para alguien con 15 años de experiencia en la industria, el hecho de no haber usado el control de versiones es una bandera roja. Puede que no sea una bandera roja si el año fuera 1982, o incluso 1992. Pero hoy, será 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 recibió tanta grasa.

Por supuesto, untarse de grasa no solucionará 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 absolutamente limpio es absolutamente inconsistente con el aspecto que tienen los mecánicos de los automóviles cuando están trabajando. En ese trabajo, te engordas.

Si está entrevistando a alguien con experiencia que admite que no tiene experiencia en el control de versiones, es probable que esté exagerando o fabricando parte de su experiencia (y que ni siquiera sepa que el control de versiones es algo muy usado e importante, y que también debería mentir sobre!)

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 inserta un nodo al principio de una lista vinculada. Sin embargo, reclamaron 20 años de experiencia laboral.

Incluso se puede esperar que los recién graduados de ciencias de la computación tengan una familiaridad pasiva con el control de versiones, incluso si aún no lo han usado extensivamente.

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

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

Antes de convertirme en profesional, era un aficionado y no usaba ningún control de fuente, sabía vagamente que era pero no me molestaba.

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 sentiría absolutamente renuente a aprender y comenzar a usarlo en el trabajo contra él ...

Mi propio 2c es que depende de cómo reaccionó cuando se le preguntó acerca de VC. Las posibles reacciones podrían ser:

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

En el caso de 4, el chico obtendría un pase de mi parte, tiene la actitud correcta y probablemente lo recogerá 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 factoides sobre VC (enumere algunos de los paquetes de VC que hay). Tomar eso como evidencia de alguna curiosidad y podría pasarlo.

Si él contestó 1 o 2, es decir, si lo supiera y no le importara saber acerca de 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 ardua batalla en todas estas cuestiones si no está dispuesto a probar nuevas enfoques.

Como la mayoría de la gente aquí, creo que sería injusto poner en desventaja al candidato solo porque su empleador no estaba en condiciones de hacerlo; Para mí, todo depende de cómo reaccionaron.

Escribir lo que ha cambiado es bueno cuando miras hacia atrás. Me ha salvado muchas veces cuando me di cuenta de lo que estaba mal y solucioné muchos problemas rápidamente porque lo tenía escrito. En mi opinión, es bueno mantener un registro. Especialmente si estás programando con más personas que tú mismo.

Si está escribiendo una aplicación web, puede seguir agregando características sin control de versiones, ya que constantemente le está agregando cosas nuevas. Pero tal vez escriba un registro o una publicación de noticias con las novedades.

Se trata de lo que estás programando.

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

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

El segundo lugar en el que me topé con este problema fue usar 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 cerraron todo, así que volvieron a un montón de carpetas comprimidas.

Conozco desarrolladores que solo han trabajado en estas condiciones. Quieren usar estas herramientas, les encantaría usarlas, pero no tienen permiso para usarlas.

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

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 copias 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 he trabajado 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 avergüenza decirle a la gente que no uso regularmente el sistema de control de versiones, pero así es como es para mí.

Hablando de 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. Básicamente, se trataba de un archivo con un número fijo de versiones, y tenía que recordar qué versión era qué: bastante 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 yo era un programador de sistemas IBM extremadamente fácil, muy productivo y muy bueno en mi trabajo. Todas las versiones se manejaron copiando copias de seguridad en cinta y registrando qué era dónde.

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

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 pretenden ser desarrolladores de Linux / Unix / Mac OS pero nunca han usado el control de versiones, habla menos bien para ellos, y es posible que tenga que evaluar si su experiencia general es tan buena que desearía. Entrénalos en la ingeniería de software moderna. Si lo son y el programador de mainframe de la vieja escuela (y eso es lo que necesita), entonces concéntrese en si tienen las habilidades de programación que necesita, y confíe en el hecho de que tendrá que enseñárselo. Como han dicho otros, su respuesta al concepto será el factor decisivo en ese caso.

Bastante por favor! La totalidad de nuestra comunidad no vive en comunidades sociales altamente desarrolladas donde los lugares frecuentados por expertos y los eventos de hackers son demasiado abundantes, ni todos trabajamos en compañías de desarrollo de software y algunos de nosotros ni siquiera podemos encontrar recursos relevantes o publicados. en nuestros idiomas nativos, impresos o en línea, permítanos encontrarnos con un compañero programador en persona.

Por lo que puedo entender, si usted es un desarrollador de software con experiencia como usted dice, es probable que haya sido un lobo solitario trabajando como freelance para pequeñas empresas.

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

1. Trabajar en compañías que no están desarrollando software como su principal línea de negocio.
2. O si el desarrollador ha decidido usar algún otro sistema, solo es 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 frente a las herramientas que desconocen

Pero debe tener cuidado cuando se encuentre con personas que asumen:

1. Que solo hay una manera de hacer algo
2. O que todo programador debe hacerlo de la misma manera que ellos
3. O que las prácticas que utilizan las personas son fáciles de cambiar

Lo más posible, ya que un programador deficiente es un experto en control de versiones. Lo que quiero decir es que no sé qué hace el control de versiones para tus habilidades de programación o habilidades de resolución de problemas. Es una cuestión de experiencia. Muchas tiendas más pequeñas no lo usan o se lo dejan a los individuos (que a menudo trabajan solos) para que lo descubran por sí mismos.

Creo que no es tanto una cuestión de "¿Cómo es posible desarrollar software de forma activa durante 10 a 15 años sin que necesite un control de versiones?", sino que "¿Cómo es posible desarrollar software de manera activa para la última ¿10-15 años sin necesitar control de versiones? ".

La programación segura es posible sin control de versión, pero un profesional debe estar familiarizado con el estado actual de la técnica y ser capaz de seleccionar las herramientas adecuadas para hacer el trabajo. No utilizar el software de administración de versiones adecuado hace que su trabajo sea riesgoso y poco confiable, y una de las razones por las que desea contratar a un desarrollador profesional es que deben poder administrar el riesgo.

Una base de código que está debidamente anotada en un VCS vale mucho más que una que no lo es. La razón de cada cambio puede ser rastreada y entendida, haciendo posible que los mantenedores tengan un conocimiento más profundo de lo que necesitan saber. No hacerlo no es profesional, y la única excusa sería si él / ella hubiera sido limitado por gerentes deficientes en su trabajo anterior. Incluso entonces, ¿no deberían haber utilizado el control de versiones para sus proyectos privados?