¿Cuándo comenzar a utilizar el control de fuente en las primeras etapas de desarrollo?

Question

Tenemos 2 tipos de personas en mi tienda:

1. Los que se inicia el registro de entrada en el código desde la primera compilación exitosa.
2. Los otros que solo comprueban el código cuando el proyecto está casi listo.

Soy parte del grupo 1 y trato de convencer a las personas del grupo 2 de que actúen como yo. Sus argumentos son como los siguientes:

1. Soy el desarrollador individual de este proyecto.
2. Es solo un prototipo, tal vez tendré que volver a escribir desde cero.
3. No quiero contaminar el Source Control con versiones incompletas.

Si tengo razón, ayúdenme a plantear argumentos para convencerlos. Si está de acuerdo con ellos, dígame por qué.

Answer 1

Intento escribir solo el código que compila (todo lo demás está comentado con una etiqueta TODO/FIXME) ... y también agregar todo para controlar la fuente

Argumento 1: A pesar de que un solo dev que es agradable volver a una versión en funcionamiento, para seguir su progreso, etc.

Argumento 2: A quién le importa si es sólo un prototipo? Puede tropezar con un problema similar en seis meses más o menos, y luego simplemente comenzar a buscar este otro código ...

Argumento 3: ¿Por qué no utilizar más de un repositorio? Me gusta registrar cosas misceláneas en mi repositorio personal.

Answer 2

Si soy el único desarrollador en un proyecto (en otras palabras, el repositorio, o parte de él, está bajo mi completo control), entonces empiezo a confirmar el código fuente tan pronto como está escrito, y tiendo a registrarse después de cada cambio incremental, ya sea que funcione o represente cualquier tipo de hito.

Si estoy trabajando en un repositorio en un proyecto con otros, entonces tienden a tratar de hacer mis confirmaciones de tal manera que no se rompen el desarrollo de la línea principal, pasar todas las pruebas, etc.

Sea o no es un prototipo, merece entrar en control de fuente; los prototipos representan mucho trabajo, y las lecciones aprendidas de ellos son valiosos. Además, los prototipos tienen un horrible hábito de convertirse en código de producción, lo que querrás en el control de la fuente.

Answer 3

Yo diría que debería comenzar a agregar la fuente y registrar en antes de que incluso compila la primera vez. Entonces es mucho más fácil evitar el ingreso de artefactos generados. Siempre uso algún control de fuente, incluso para mis pequeños hacks de pasatiempos, solo porque filtra automáticamente lo relevante del ruido.

Así que cuando empiece a crear prototipos puedo crear un proyecto y luego, antes de compilarlo, hago "git init, git add., Git commit -a -m ..." para que cuando quiera mover las partes interesantes Me limito a clonar el uso de git y luego puedo agregarlo al repositorio de subversión o lo que sea que use donde estoy trabajando en este momento.

Answer 4

Comience a usar el control de fuente unos 20 minutos antes de escribir la primera línea de su primer artefacto. Nunca es un buen momento para comenzar después de que ha comenzado a escribir cosas.

Answer 5

algunas personas solo pueden aprender de la experiencia.

como una falla en el disco duro. o usted mismo codificación en un callejón sin salida después de eliminar código que realmente trabajó

ahora, estoy no decir que usted debe borrar su disco duro y luego burlarse de ellos con "si el control de fuente única se hubiera usado" .. .pero si sucediera algo así, con suerte habría una copia de seguridad hecha primero ;-)

Answer 6

Creo un directorio en control de fuente antes de comenzar a escribir el código para un proyecto. Hago el primer commit después de crear el esqueleto del proyecto.

Answer 7

Cuando alguien pidió good excuses not to use version control, obtuvieron 75 respuestas y 45 votos positivos.

Y cuando le preguntaron Why should my team adopt source control, obtuvieron 26 respuestas.

Quizás encuentres algo útil allí.

Answer 8

Aquí está mi punto de vista.

1) Incluso los desarrolladores solo necesitan un lugar donde guardar su código cuando falla su PC. ¿Qué sucede si borran accidentalmente un archivo sin control de origen?

2/3) Los prototipos pertenecen al control de fuente para que otros miembros del equipo puedan ver el código. Colocamos nuestro código de prototipo en una ubicación separada de la sucursal principal. Lo llamamos Spike. Aquí hay un excelente artículo sobre por qué debe mantener el código de Spike: http://odetocode.com/Blogs/scott/archive/2008/11/17/12344.aspx

Answer 9

Early and Often. Como dicen los programadores pragmáticos, el control de la fuente es como una máquina del tiempo, y nunca sabes cuándo querrás volver.

Answer 10

No necesita "argumentos para convencerlos". El discurso no es un juego, y no debes usar tu trabajo como plataforma de debate. Para eso está su cónyuge :) En serio, sin embargo, necesita explicar por qué le importa cómo otros desarrolladores trabajan en proyectos individuales en los que otras personas no están involucradas. ¿Qué es lo que hace falta porque no usan el control de fuente? ¿Necesita ver sus primeras ideas para comprender su código posterior? Si puede hacer eso con éxito, es posible que pueda convencerlos.

Personalmente utilizo el control de versiones en todo momento, pero solo porque no ando por la cuerda floja sin una red. Otras personas tienen más coraje, menos tiempo para invertir en infraestructura, etc. Tenga en cuenta que en 2009, en mi opinión, los discos duros rara vez fallan y el código reescrito a menudo es mejor que el código que reemplaza.

Mientras contesto una pregunta con una pregunta, permítanme hacerme otra: ¿su código necesita compilar/trabajar/no romper la construcción para que se registre? Me gusta que mis ramas se vuelvan buenas y rotas, luego corregidas, funcionando, depuradas, etc. Al mismo tiempo, me gusta que otros desarrolladores usen el control de fuente como quieran. Las sucursales se inventaron por esa razón: para que las personas que no se llevan bien no tengan que convivir.

Answer 11

Para mí, se trata de tener un proceso constante. Si está escribiendo código, debe seguir el mismo proceso de control de origen que su código de producción. Eso ayuda a construir y aplicar buenas prácticas de desarrollo en todo el equipo de desarrollo.

La categorización del código como un prototipo u otro tipo de proyecto que no sea de producción solo debe usarse para determinar en qué parte del árbol de control de origen lo coloca.

Utilizamos tanto CVS (para proyectos que no sean .NET) como TFS (para proyectos .NET) donde trabajo, y el repositorio TFS tiene una carpeta Developer Sandbox donde los desarrolladores pueden verificar proyectos experimentales personales (prototipos).

Si un proyecto comienza a utilizarse en producción, el código se mueve de la carpeta Developer Sandbox a su propia carpeta en el árbol principal.

Answer 12

Yo les diría ...

yo soy el desarrollador de este proyecto en solitario.

Y cuando salga o la mano si fuera poco tendremos 0 desarrolladores. Razón de más para usar el control de fuente.

El código pertenece a la empresa, no usted y la empresa desean cierta responsabilidad. El registro del código no requiere demasiado esfuerzo:

svn ci <files> -m " implement ajax support for grid control 

próxima vez que alguien nuevo quiere hacer algunos cambios en el control de la red o hacer algo relacionado, que tendrán un gran punto de partida. Todos los proyectos comienzan con una o dos personas. El control de la fuente es más fácil ahora que nunca. ¿Han organizado una demostración de 30 minutos de Tortoise SVN con ellos?

Es solo un prototipo, tal vez tendré que volver a escribir desde cero.

¿Les preocupa el almacenamiento? El almacenamiento es barato. ¿Les preocupa el tiempo perdido en el control de versiones? Tarda menos tiempo que las verificaciones rápidas de correo electrónico. Si están reescribiendo bits, entonces el control de la fuente es aún más importante para poder hacer referencia a los bits antiguos.

No quiero contaminar el Source Control con versiones incompletas.

Eso es realmente una buena preocupación. Solía ​​pensar lo mismo en un punto y evité verificar el código hasta que estuvo bien y limpio, lo que no es malo en sí mismo, pero muchas veces solo quería hacer el tonto. En este punto, aprender sobre la ramificación ayuda. Aunque desearía que SVN tuviera soporte completo para purgar carpetas como Perforce.

Answer 13

Vamos a ver sus argumentos:

1. yo soy el desarrollador de este proyecto en solitario.
2. Es solo un prototipo, tal vez tendré que volver a escribir desde cero.
3. No quiero contaminar el Source Control con versiones incompletas.

Primero, el 3er.Puedo ver el razonamiento, pero está basado en una mala suposición.
En el trabajo, utilizamos Perforce, un VCS centralizado, y de hecho solo revisamos el origen que compila con éxito y no rompe nada (¡en teoría, por supuesto!), Después de la revisión por pares.

Así que cuando empiezo un cambio no trivial, siento la necesidad de compromisos intermedios. Por ejemplo, recientemente comencé a hacer algunos cambios (de alguna manera, en solitario para esta tarea en particular, por lo que me dirijo al punto 1) en un código Java usando JDom (análisis XML). Luego me quedé atrapado y quería utilizar el análisis XML integrado de Java 1.6. Era obviamente el momento de mantener un rastro del trabajo actual, en caso de que mi intento fracasara y quisiera regresar. Tenga en cuenta que este caso de alguna manera aborda el punto 2.

La solución que elegí es simple: ¡utilizo un SCM alternativo! Aunque algunos VCS centralizados como SVN se pueden utilizar en local (en la computadora del desarrollador), fui seducido por el VCS distribuido y después de probar brevemente Mercurial (que es bueno), encontré que Bazaar se adecuaba mejor a mis necesidades y mi gusto.
Los DVCS son adecuados para esta tarea porque son livianos, flexibles, permiten ramificaciones alternativas, no "contaminan" el directorio de origen (todos los datos están en un directorio en la raíz del proyecto), etc.
Haciendo una administración de fuente paralela, no contaminará la fuente de otros desarrolladores, mientras mantiene la posibilidad de volver atrás o probar rápidamente soluciones alternativas.

Al final, al comprometer la versión final con el SCM oficial, el resultado es el mismo, pero con mayor seguridad en el nivel del desarrollador.

Answer 14

Me gustaría agregar dos cosas. Con control de versiones, puede:

• Vuelva a la última versión que funcionó, o al menos compruebe cómo se veía. Para eso, necesitaría SCM, que admite conjuntos de cambios/utiliza commit de árbol completo.
• Úselo para encontrar errores, utilizando el llamado 'depuración de diff' al encontrar la confirmación en el historial que introdujo el error. Querrá SCM que lo soporte de manera automatizada o semiautomatizada.

Answer 15

Personalmente, a menudo comienzo el control de versiones después de la primera compilación exitosa.

Me pregunto por qué nadie mencionó los sistemas de control de versiones distribuidas en este contexto: si logras cambiar a un sistema distribuido (git, bazar, mercurio), la mayoría de los argumentos de tu segundo grupo carecerían de sentido ya que pueden inicie su repositorio localmente e introdúzcalo en el servidor cuando lo desee (y también pueden eliminarlo, si desean reiniciar desde cero).

Answer 16

Se llama ramificación de personas que tratan de obtener con el programa: p Prototipado? Trabaja en una rama. ¿Experimentando? Trabaja en una rama. ¿Nueva caracteristica? Trabaja en una rama.

Combina tus ramas en el tronco principal cuando tenga sentido.

Answer 17

Supongo que la gente tiende a ser relajada cuando se trata de configurar el control de fuente inicialmente si el código nunca se puede usar. Tengo proyectos codificados pertenecientes a ambos grupos y los que están fuera del control de la fuente no son menos importantes. Es una de esas cosas que se pospone cada día cuando en realidad no debería.

Por otro lado, algunas veces me comprometo a complicar demasiado una reversión una vez que arruino un código CSS y no sé lo que cambié, p. Ej. para hacer que el pie de página del sitio termine detrás del encabezado.

Answer 18

Comprobo el proyecto en control de fuente antes de comenzar la codificación. Lo primero que hago es crear y organizar los proyectos y archivos de soporte (como archivos .sln en desarrollo .NET) con las bibliotecas y herramientas de soporte necesarias (generalmente en una carpeta lib) sé que usaré en mi proyecto. Si ya tengo un código escrito, lo agrego también, incluso si es una aplicación incompleta. Luego reviso todo. A partir de ahí, todo está como de costumbre, escriba un código, compílelo, pruébelo, regístrelo ...

Probablemente no necesite ramificarse desde este punto o revertir los cambios, pero creo que es una buena práctica es tener todo bajo control de código fuente desde el principio, incluso si no tiene nada que compilar.

Answer 19

estoy borracho y hago primero git -init y luego vim foo.cpp.

Answer 20

Cualquier plataforma decente de control de fuente moderna (de la que VSS no es una) no debe de ninguna manera contaminarse al poner archivos de código fuente en ella. Soy de la opinión de que cualquier cosa que tenga una expectativa de vida de más de 1/2 hora debería estar en control de la fuente tan pronto como sea posible. El desarrollo en solitario ya no es una excusa válida para no usar el control de fuente. No se trata de seguridad, se trata de errores e historial a largo plazo.