¿Cómo trabajan juntos los programadores en un proyecto?

También soy un estudiante, que completó un curso de ingeniería de software recientemente donde todo el semestre consistió en un proyecto grupal gigante. Permítanme empezar diciendo que podríamos haber hecho con 3 personas lo que nos tomó a 12 de nosotros todo el semestre para hacer. Trabajar con la gente es algo difícil. La comunicación es clave.

Definitivamente utilizar un repositorio. Cada persona puede acceder de forma remota a todo el código y agregar/eliminar/cambiar cualquier cosa. Pero la mejor parte de subversion es que si alguien rompe el código, puede volver a una versión anterior y evaluar lo que salió mal a partir de ahí. Sin embargo, la comunicación sigue siendo clave, sepa lo que están haciendo sus compañeros de equipo para que no haya conflictos. Tampoco te quedes sentado en tu código, haz confirmaciones rápidas y significativas al repositorio para que sean las más efectivas.

**También recomendaría un rastreador de errores, como Redmine. Puede configurar cuentas para todos y asignar tareas a las personas con diferentes prioridades, y también realizar un seguimiento y ver si las personas se han ocupado de ciertos problemas, o si han surgido más.

Y, como se ha dicho antes, las pruebas unitarias ayudarán mucho. ¡Mucha suerte! Espero que esto haya ayudado : -)

Las grandes cosas son:

• Un plan - Si la gente no sabe a dónde va, no irá a ninguna parte. Por lo tanto, el inicio de cualquier proyecto necesita unas pocas personas (a menudo los osos grises del proyecto) para reunirse y elaborar un plan; el plan no necesita ser muy detallado, pero aún así es necesario.
• Sistema de control de versiones - Sin esto, no están trabajando juntos. También necesitas el firme compromiso de que si las cosas no están comprometidas, no cuentan. "Oh, en una de mis cajas de arena" es sólo una excusa.
• Issue tracker - No se puede realizar un seguimiento de estas cosas por carpetas de correo electrónico. Definitivamente debería estar respaldado por la base de datos.
• Sistema de notificación - La gente necesita saber cuando las cosas están comprometidas con el código que mantienen o se hacen comentarios a los errores de los que son responsables. Email puede trabajar para esto, como puede IRC (siempre que todo el mundo lo use, por supuesto).
• Sistema de compilación - No lo hace realmente importa cómo esto sucede, siempre y cuando con una acción pueda obtener una compilación completa del estado actual de las cosas, tanto de su entorno de pruebas de desarrollo como del repositorio principal. La mejor opción para esto depende de qué idioma(s) estés usando.
• Test suite - Un test suite ayuda a las personas a evitar errores tontos. Tiene que ser tan fácil de ejecutar como la compilación (ser parte de la compilación es bueno). Tenga en cuenta que las pruebas son solo un sustituto crudo para la corrección, pero son mucho mejor que nada.

Finalmente, necesitas estar dispuesto a trabajar juntos para cumplir el plan. Esa es con demasiada frecuencia la parte difícil.

Generalmente es una buena práctica no comprobar artefactos de compilación en el repositorio. El repositorio contendrá el árbol de fuentes, la configuración de compilación, etc.-cualquier cosa escrita por un humano. Los ingenieros de software revisarán una copia de su código en su sistema de archivos local y lo construirán localmente.

También es una buena práctica tener pruebas unitarias que se ejecutan como parte del proceso de compilación. De esta manera, un desarrollador sabrá instantáneamente si sus cambios han invalidado cualquiera de las pruebas unitarias, y tendrá la oportunidad de arreglarlos antes de comprobar en sus cambios.

Le gustaría buscar en la documentación de un sistema de control de versiones (uno de Subversion, CVS, Git, etc.) y para un sistema de compilación (por ejemplo, en Java hay Ant y Maven).

Cómo los programadores trabajan juntos en un pieza de software en una empresa

Los desarrolladores nunca trabajan en equipo. Los equipos apestan. Dilbert es gracioso no porque sea un personaje cómico como Goofy. Es gracioso porque es real y la gente reconoce las situaciones en las que está.

No hay un estándar para las cosas que estás preguntando. Por el contrario, existen convenciones que dependen en gran medida del tamaño y la madurez de la organización. Si estás en una organización pequeña, digamos un par de programadores, entonces las cosas probablemente serán algo informales con los desarrolladores individuales haciendo codificación, compilaciones y pruebas.

En organizaciones más grandes, puede haber un ingeniero de construcción dedicado y un proceso. Este tipo de organización generalmente hará una construcción formal sobre una de forma regular, digamos una vez al día, usando cualquier código fuente que esté registrado. El proceso también suele incluir BVT (Build Validation Tests) y quizás algunas pruebas de regresión. Los desarrolladores comprobarán el código del repositorio, trabajarán en su propia parte localmente, y luego lo comprobarán.

En las organizaciones más grandes, como Microsoft o Google, tendrán un grupo completamente dedicado y un laboratorio completo que se construirá sobre una base más o menos continua, haciendo que los resultados de cada carrera disponible. Estas organizaciones tienen procesos y procedimientos muy formales en su lugar sobre qué se registra y cuándo,cuáles son los procesos de revisión de código, etc.

La respuesta corta - "depende".

Actualmente, estoy trabajando en un proyecto por mí mismo, por lo que soy el que construye/utiliza VCS. Sé de otros lugares que tienen equipos trabajando en el proyecto juntos por shudder correo electrónico. O equipos grandes (+5) usando VCS.

En ese sentido, recomiendo encarecidamente aprender al menos algunos VCS, y Joel Spolsky tiene un gran tutorial introductorio para Mercurial. Bazaar (mi elección personal) es similar, y luego Git es el siguiente más cercano en términos de similitud, pero probablemente más popular que cualquiera (al menos ATM). Después de eso tienes SVN que es bastante débil en comparación.

En realidad, Joel habla sobre la mayoría de sus preguntas - yo recomendaría leer los 10 años de archivos que tiene - es toda información muy útil, y la mayor parte pertinente a su situación actual y futura.

No hay un libro de cocina para trabajar con el desarrollo de software, pero en general el sistema de control de versiones debe ser el corazón de su sistema de compilación, incluso si está trabajando en un proyecto donde usted es el único desarrollador. Incluso en este caso, poder revertir versiones y leer el registro de versiones es una ayuda muy bienvenida para corregir errores. Esta no es la única característica de un sistema de control de versiones, pero esto por sí solo justifica la instalación, configuración y mantenimiento de un sistema de control de versiones.

El la compilación puede ser realizada por cada desarrollador al agregar nuevo código, o periódicamente por un "servidor de compilación". El último enfoque requiere más configuración, pero ayuda a descubrir errores de compilación antes.

La programación adecuada es algo profundo que se beneficia enormemente de la experiencia. La programación por pares es como ejecutar múltiples procesadores de conciencia... uno puede pasar por alto algo visto por el otro y mientras se estén comunicando puede resultar en un gran progreso.

En primer lugar, los equipos trabajan utilizando repositorios (que pueden ser de control de versiones profesional, o simplemente un montón de directorios que se considera el 'vivo', sin embargo, un sistema de control de revisiones es el estándar de facto). Además, la estrategia de cómo se gestiona el proyecto depende de cómo se trabaja (cascada, ágil, etc.). Si se trabaja en iteraciones, se construyen componentes / plugins/módulos / bibliotecas que son autosostenidos, y se realizan pruebas unitarias, hasta que estén firmados como terminados. Como equipo, usted trabaje en equipo, lo que significa que no trabaja en todo el proyecto en todas partes al mismo tiempo. En su lugar, se obtiene una tarea para realizar dentro de un ámbito del proyecto. En algunas ocasiones tienes que arreglar código que no es tuyo, pero que suele venir cuando se produce un comportamiento extraño. Básicamente, usted está haciendo la prueba de las piezas que desarrolla.

Permítanme ejemplificar esto para usted. Estás dentro de un equipo de trabajadores de la construcción. El arquitecto viene con un plan para un edificio, el capataz mira lo que las necesidades son construir y luego contratar a los constructores. El albañil hace las paredes, comprueba su resistencia y las pega muy bien. El electricista hace todo el cableado dentro del edificio para que la electricidad pueda fluir. Cada hombre tiene su propio trabajo. A veces, el electricista puede querer discutir con el albañil si ciertas paredes pueden ser talladas, pero siempre en conjunto con el capataz.

Espero que esto sea algo de ayuda para usted!

Normalmente, el sistema de control de código fuente contiene el código fuente y normalmente no tiene los binarios. Si usted quiere construir y ejecutar el programa, marque el código y construir en su máquina local.

Algunos lugares ejecutan nightly builds para asegurarse de que todo funcione. Incluso puede haber algunas pruebas automatizadas que se ejecutan en el lado del servidor. Si la compilación o cualquier otra cosa falla, alguien es notificado automáticamente.

Una buena introducción a un método de uso de control de fuentes es Eric Sink's Source Control HOWTO http://www.ericsink.com/scm/source_control.html

En sus ejemplos usa SourceGear Vault desde que lo escribió, pero los métodos se pueden aplicar a otros sistemas de control de versiones.

Esta es de nuevo una buena razón por la que uno debe buscar en los proyectos de Código abierto.

Los desarrolladores principales que trabajan en grandes proyectos de código abierto (como Chromium , Mozilla Firefox, MySQL , Software Gnu Popular) son profesionales. Tienen mucha experiencia y estos proyectos han evolucionado a lo largo de los años con ideas de cientos de profesionales.

Todo lo que otros mencionaron en sus respuestas (Plan, Sistema de control de versiones , Rastreador de problemas, Sistema de notificación, Sistema de compilación, Prueba suite,) se puede encontrar en estos proyectos de código abierto.

Si realmente quieres una experiencia práctica, te sugiero que revises algunos proyectos populares y grandes de código abierto y luego obtengas el Código Fuente de cualquier proyecto (usando Control de Versiones) y lo construyas tú mismo.

PD: También soy estudiante y participar en proyectos de código abierto es lo mejor que he hecho en mi vida. ¡Confía en mí! tú también sentirás lo mismo.