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

Tenemos 2 types de personas en mi tienda:

  1. Los que comienzan a registrar el código desde la primera compilation exitosa.
  2. Los otros que solo ingresan 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 arguments 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 de nuevo.
  3. No quiero contaminar el Source Control con versiones incompletas.

Si estoy en lo cierto, ayúdenme a plantear arguments para convencerlos. Si está de acuerdo con ellos, dígame por qué.

Intento escribir código que comstack (todo lo demás está comentado con una label TODO / FIXME) … y también agregar todo al control de código fuente.

Argumento 1: Incluso como un solo desarrollador, es bueno retroceder a una versión en ejecución, seguir su progreso, etc.

Argumento 2: ¿A quién le importa si es solo un prototipo? Puede encontrarse con un problema similar en seis meses más o less, y luego simplemente comenzar a search este otro código …

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

Cuando alguien pidió buenas excusas para no usar el control de versiones , obtuvieron 75 respuestas y 45 votos ascendentes.

Y cuando preguntaron por qué mi equipo debería adoptar el control de la fuente , obtuvieron 26 respuestas.

Quizás encuentres algo útil allí.

No necesitas "arguments 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.

Yo personalmente uso el control de versiones en todo momento, pero solo porque no ando por la string floja sin una networking. Otras personas tienen más coraje, less time para invertir en infraestructura, etc. Tenga en count 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ítame preguntarle a otra: ¿necesita su código comstackr / trabajar / no-romper-la-construcción para ser registrado? Me gusta que mis twigs se vuelvan buenas y rotas, luego corregidas, funcionando, depuradas, etc. Al mismo time, me gusta que otros desarrolladores usen el control de fuente como quieran. Las sucursales se deviseon por esa razón: para que las personas que no se llevan bien no tengan que convivir.

Aquí está mi vista de tus puntos.

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

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

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

Si estoy trabajando en un repository en un proyecto con otros, entonces bash probar y comprometerme de tal forma que no rompan el desarrollo de la línea principal, pasen las testings, etc.

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

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

algunas personas solo pueden aprender de la experiencia.

como un fallo en el disco duro. o codificándote a ti mismo en un callejón sin salida después de borrar el código que realmente funcionó

ahora, no estoy diciendo que debas borrar su disco duro y luego burlarte de ellos "si hubieras usado el control de código fuente" … pero si sucediera algo así, con suerte habría una copy de security primero 😉

Temprano y a menudo. Como dicen los progtwigdores pragmáticos, el control de la fuente es como una máquina del time, y nunca sabes cuándo querrás volver.

Yo les diría …

Soy el desarrollador individual de este proyecto.

Y cuando te vayas o lo entregues tendremos 0 desarrolladores. Razón de más para usar el control de fuente.

El código pertenece a la compañía, no a usted, y la compañía desea cierta responsabilidad. Verificar el código no requiere demasiado esfuerzo:

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

La próxima vez que alguien nuevo quiera hacer algunos cambios en el control de la grilla o hacer algo relacionado, tendrá 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 de nuevo.

¿Están preocupados por el almacenamiento? El almacenamiento es barato. ¿Les preocupa el time perdido en el control de versiones? Tarda less time 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 reference a los bits antiguos.

No quiero contaminar el Source Control con versiones incompletas.

Esa 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 cual 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.

Veamos sus arguments:

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

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

Entonces, cuando comienzo 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 bash fracasara y quisiera regresar. Tenga en count 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 directory de origen (todos los datos están en un directory en la raíz del proyecto), etc.
Al hacer una gestión de fuente paralela, no contaminará la fuente de otros desarrolladores, mientras mantiene la posibilidad de retroceder 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 security a nivel del desarrollador.

Me gustaría agregar dos cosas. Con el control de versión puedes:

  • Vuelve a la última versión que funcionó, o al less comtesting cómo se veía. Para eso, necesitaría SCM, que admite sets de cambios / utiliza commit de tree completo.
  • Úselo para encontrar errores, usando la denominada " debugging de errores " al encontrar el compromiso en el historial que introdujo el error. Querrá SCM que lo soporte de manera automatizada o semiautomatizada.

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

Me pregunto por qué nadie mencionó los sistemas de control de versiones distribuidas en este context: si pudieras cambiar a un sistema distribuido (git, bazaar, mercurio), la mayoría de los arguments de tu segundo grupo serían inútiles ya que pueden iniciar su repository localmente y enviarlo al server cuando lo deseen (y también pueden eliminarlo, si quieren reiniciar desde cero).

Para mí, se trata de tener un process consistente. Si está escribiendo código, debe seguir el mismo process de control de origen que su código de producción. Eso ayuda a build 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é lugar del tree de control de origen lo ubica.

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

Si y cuando un proyecto comienza a utilizarse en producción, el código se mueve desde la carpeta Developer Sandbox a su propia carpeta en el tree principal.

Diría que deberías comenzar a agregar la fuente y verificar antes incluso de comstackr 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 pasatimes, solo porque filtra automáticamente lo relevante del ruido.

Entonces, cuando empiezo a crear prototypes, puedo crear un proyecto y luego, antes de comstackrlo, hago "git init, git add., Git commit -a -m …" solo para que cuando quiera mover las partes interesantes solo clone usando git y luego puedo agregarlo al repository de subversión o lo que sea que use donde estoy trabajando en este momento.

Se llama branching people try to get with the program: p Prototyping? Trabaja en una twig. ¿Experimentando? Trabaja en una twig. ¿Nueva caracteristica? Trabaja en una twig.

Combina tus twigs en el tronco principal cuando tenga sentido.

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 less importantes. Es una de esas cosas que se pospone cada día cuando en realidad no debería.

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

Comprobo el proyecto en control de fuente antes de comenzar a codificar. Lo primero que hago es crear y organizar los proyectos y files de soporte (como files .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, también lo agrego, 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ístrese …

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

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

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

Cualquier plataforma decente de control de fuente moderna (de la cual VSS no es una) no debería de ninguna manera contaminarse al poner files 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 security, se trata de errores e historial a largo ploop.