¿Cómo trabajan los programadores en un proyecto?


81

Siempre he programado solo, todavía soy un estudiante, así que nunca programé con nadie más, ni siquiera he usado un sistema de control de versiones antes.

Ahora estoy trabajando en un proyecto que requiere conocimiento de cómo los programadores trabajan juntos en una pieza de software en una empresa.

¿Cómo se compila el software? ¿Es del sistema de control de versiones? ¿Es por programadores individuales? ¿Es periódico? ¿Es cuando alguien decide construir o algo así? ¿Hay alguna prueba que se haga para asegurarse de que "funciona"?

Cualquier cosa servirá.


24
Eliminé la etiqueta "no relacionada con la programación" porque la forma en que las personas programan como equipo está definitivamente relacionada con la programación.
Brendan Long

@Brendan Long: Gracias por volver a etiquetar.
Leo Jweda

Respuestas:


60

En realidad, existen tantas variaciones en estos procesos como empresas existen. Significado: cada empresa tiene convenciones un poco diferentes a otras, pero existen algunas mejores prácticas comunes que generalmente se utilizan en la mayoría de los lugares.

Mejores prácticas que siempre son útiles

  • Todo el código fuente del proyecto y todo lo que se requiere para construirlo está bajo control de versiones (también llamado control de fuente). Cualquiera debería poder construir el proyecto completo con un solo clic.
    Además, los archivos innecesarios (archivos de objetos o binarios compilados) no deben agregarse al repositorio, ya que se pueden regenerar con bastante facilidad y solo desperdiciarían espacio en el repositorio.
  • Todos los desarrolladores deben actualizar y comprometerse con el control de versiones varias veces al día. Sobre todo cuando han terminado la tarea en la que están trabajando y la han probado lo suficiente como para saber que no contiene errores triviales.
  • Nuevamente: cualquiera debería poder construir el proyecto con un solo clic. Esto es importante y facilita la prueba para todos. Gran ventaja si los no programadores (por ejemplo, el jefe) también pueden hacerlo. (Les hace sentir poder ver exactamente en qué está trabajando el equipo).
  • Cada desarrollador debe probar la nueva función o corrección de errores que están agregando antes de enviarlas al repositorio.
  • Configure un servidor que regularmente (en intervalos predeterminados) se actualice desde el repositorio e intente compilar todo en todo el proyecto . Si falla, envía correos electrónicos al equipo junto con las últimas confirmaciones al control de versiones (desde qué confirmación no se pudo compilar) para ayudar a depurar el problema.
    Esta práctica se denomina integración continua y las compilaciones también se denominan compilaciones nocturnas .
    (Esto no implica que los desarrolladores no deban compilar y probar el código en sus propias máquinas. Como se mencionó anteriormente, deberían hacerlo).
  • Obviamente, todos deberían estar familiarizados con el diseño / arquitectura básica del proyecto, por lo que si se necesita algo, los diferentes miembros del equipo no tienen que reinventar la rueda. Escribir código reutilizable es algo bueno.
  • Se necesita algún tipo de comunicación entre los miembros del equipo. Todos deben ser conscientes de lo que hacen los demás, al menos un poco. Mientras más, mejor. Es por eso que el standup diario es útil en los equipos SCRUM.
  • La prueba unitaria es una muy buena práctica que hace que probar la funcionalidad básica de su código automáticamente.
  • Un software de seguimiento de errores (a veces llamado software de seguimiento del tiempo ) es un medio muy bueno para realizar un seguimiento de los errores que hay y las tareas que tienen los diferentes miembros del equipo. También es bueno para las pruebas: los probadores alfa / beta de su proyecto podrían comunicarse con el equipo de desarrollo de esta manera.

Estas cosas simples aseguran que el proyecto no se salga de control y que todos trabajen en la misma versión del código. El proceso de integración continua ayuda cuando algo sale terriblemente mal.

También evita que las personas envíen cosas que no se compilan en el repositorio principal.
Si desea incluir una nueva función que tardaría días en implementarse y evitaría que otras personas construyan (y prueben) el proyecto, utilice la función de ramas de su control de versiones.

Si eso no es suficiente, puede configurarlo para que también realice pruebas automatizadas, si eso es posible con el proyecto en cuestión.

Algunos pensamientos mas

La lista anterior puede ser muy pesada a primera vista. Le recomiendo que lo siga según sea necesario : comience con un control de versiones y un rastreador de errores, luego configure el servidor de integración continua, si lo necesita. (Si es un proyecto grande, lo necesitará muy pronto). Empiece a escribir pruebas unitarias para las partes más importantes. Si no es suficiente, escribe más.

Algunos enlaces útiles:
Integración continua , Las compilaciones diarias son tus amigos , Control de versiones , Prueba unitaria

Ejemplos:

Para el control de versiones, hoy en día tiendo a usar Git para mis proyectos personales. Subversion también es popular y, por ejemplo, VisualSVN es bastante fácil de configurar si usa un servidor Windows. Para el cliente, TortoiseSVN funciona mejor para muchas personas. Aquí hay una comparación entre Git y SVN.

Para el software de seguimiento de errores, Jira y Bugzilla son muy populares. También usamos Mantis en un lugar de trabajo anterior.

Para el software de integración continua, existe Teamcity para uno (también, CruiseControl y su contraparte .NET son notables).

Responda a su pregunta "¿quién decide el diseño principal del proyecto?"

Por supuesto, ese sería el desarrollador principal.
En las empresas, el desarrollador líder es la persona que habla con la gente de finanzas / marketing del proyecto y decide la arquitectura de acuerdo con la capacidad financiera de la empresa, las características planificadas, los requisitos de los usuarios y el tiempo disponible.

Es una tarea compleja y, por lo general, participan más de una persona. A veces, a los miembros del equipo también se les pide que participen o intercambien ideas sobre el diseño de todo el proyecto o partes específicas.


4
Debería considerar Git sobre Subversion. Subversion es mejor que CVS y Git es mucho más superior que Subversion. Además, la subversión tiene algunas peculiaridades, aunque es fácil de aprender. Especialmente en forma de complementos. Aunque TortoiseSVN es dulce (cuando se trabaja en sistemas Windows).
Shyam

5
@Shyam - De hecho, he oído hablar de Git. Tiene sus ventajas, pero yo no diría "mucho más superior". Especialmente si se considera que aún no tiene un cliente de Windows decente. Aún así, es más una preferencia personal, así que lo agregué a mi respuesta.
Venemo

@Venemo: ¿No hace eso aburrida la programación? ¿No poder probar su código de inmediato y tener que esperar la compilación y luego ver poco o ningún efecto de lo que escribió? Además, ¿quién decide el diseño principal del proyecto? (lenguaje, funciones, bibliotecas, marcos, arquitectura, etc.)
Leo Jweda

2
@Laith J: 1. El trabajo en general es aburrido. 2. Ser paciente es una virtud. 3. No importa quién diseñe el proyecto, el cliente decide. No importa 'cuán' innovadora, fantástica o fabulosa tenga la idea. Entregables. Trabaja para estar vivo, no estés vivo para trabajar.
Shyam

1
@Shyam: personalmente no sé nada sobre Git, y no juzgo las cosas de las que sé poco. No es necesario convertir esto en llamas. Las diferencias se explican bien aquí: stackoverflow.com/questions/871/… y no cambiaré a Git hasta que esta cosa simple y cotidiana sea tan difícil de lograr: stackoverflow.com/questions/2733873/… . También me gusta más el enfoque de SVN y es mucho más sencillo de aprender. Y me gusta lo simple.
Venemo

13

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

Definitivamente utilice 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 la subversión es que si alguien rompe el código, puede volver a una versión anterior y evaluar qué salió mal a partir de ahí. Sin embargo, la comunicación sigue siendo clave, sepa qué están haciendo sus compañeros de equipo para que no haya conflictos. Tampoco se quede sentado en su código, realice confirmaciones rápidas y significativas en el repositorio para que sea más efectivo.

** 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 serán de gran ayuda. ¡La mejor de las suertes! Espero que esto haya ayudado :-)


parece que aprendiste una lección realmente valiosa en el proyecto grupal tan bien hecho para tu universidad. Trabajar con personas ES difícil pero vas a pasar mucho tiempo haciéndolo. Y también puede ser gratificante.
Marca de alto rendimiento

+1 para el rastreador de errores: el que usamos (no conozco a otros) nos permite agregar notas, y podemos seguir el historial completo del error y recordar las cosas mucho mejor si surge algo 3 meses después de que se solucionó
Rox

Cuando estaba en la universidad, cada proyecto que involucraba a un grupo no se cumplía debido a la dinámica del grupo, la comunicación o los vínculos débiles. La ventaja de trabajar para una empresa es que los colegas totalmente incompetentes o desmotivados (por lo general) no se quedan tanto tiempo.
Benjol

@Benjol - ¡No podría estar más de acuerdo! Gracias por la retroalimentación a todos :-)
Elaina R

8

Las grandes cosas son:

  • Un plan : si las personas no saben a dónde van, no irán a ninguna parte. Por lo tanto, el inicio de cualquier proyecto necesita algunas personas (a menudo los barbas grises del proyecto) para formar un grupo y elaborar un plan; no es necesario que el plan sea muy detallado, pero sí es obligatorio.
  • Sistema de control de versiones : sin esto, no estarán trabajando juntos. También necesita el firme compromiso de que si las cosas no se comprometen, no cuentan. “Oh, está en una de mis cajas de arena” es solo una excusa poco convincente.
  • Rastreador de problemas : no puede realizar un seguimiento de estas cosas mediante carpetas de correo electrónico. Definitivamente debería estar respaldado por una base de datos.
  • Sistema de notificación : las personas necesitan saber cuándo las cosas están comprometidas con el código que mantienen o se hacen comentarios sobre los errores de los que son responsables. El correo electrónico puede funcionar para esto, al igual que el IRC (siempre que todos lo usen, por supuesto).
  • Sistema de compilación : realmente no importa cómo sucede esto, siempre que 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é usando.
  • Conjunto de pruebas : un conjunto de pruebas ayuda a las personas a evitar errores tontos. Debe 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 burdo sustituto de la corrección, pero son muchísimo mejores que nada.

Finalmente, necesita la voluntad de trabajar juntos para cumplir con el plan. Con demasiada frecuencia, esa es la parte difícil.


Los requisitos detallados pueden ayudar, al igual que un sistema de integración continua, pero en realidad son aspectos de las otras cosas enumeradas.
Donal Fellows

7

Por lo general, es una buena práctica no comprobar los 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 comprobará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 ejecuten como parte del proceso de compilación. De esta manera, un desarrollador sabrá instantáneamente si sus cambios han invalidado alguna de las pruebas unitarias y tendrá la oportunidad de corregirlas antes de verificar sus cambios.

Es posible que desee buscar en la documentación un sistema de control de versiones (uno de Subversion, CVS, Git, etc.) y un sistema de compilación (por ejemplo, en Java hay Ant y Maven).


Si los resultados de la compilación no están en el repositorio, ¿cómo podrán los desarrolladores de grandes proyectos ejecutar la compilación de prueba? No estoy seguro de si esta es mi mentalidad solo porque siempre he trabajado solo, pero siempre verifico que las cosas "funcionen" cuando ejecuto mi programa.
Leo Jweda

Las compilaciones de prueba (y los datos creados por el proceso de compilación) se agruparán en un instalador o como un sistema de archivos plano en un recurso compartido de red para que se puedan copiar fácilmente. Esto es útil cuando tiene probadores dedicados para que puedan proporcionar comentarios sobre correcciones de errores, etc.
graham.reeds

7

cómo los programadores trabajan juntos en una 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 divertido porque es real y la gente reconoce las situaciones en las que se encuentra.

Cómic


3

No existe un estándar para las cosas por las que pregunta. Más bien, existen convenciones y éstas dependen en gran medida del tamaño y madurez de la organización. Si está 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 y un proceso de construcción dedicado. Este tipo de organización suele realizar una compilación formal de forma regular, digamos una vez al día, utilizando el código fuente que se haya registrado. El proceso también suele incluir BVT (pruebas de validación de compilación) y quizás algunas pruebas de regresión. Los desarrolladores verificarán el código del repositorio, trabajarán en su propia porción localmente y luego lo registrarán.

En las organizaciones más grandes, como Microsoft o Google, tendrán un grupo completamente dedicado y un laboratorio completo que se desarrollará de forma más o menos continua, haciendo que los resultados de cada ejecución estén disponibles. Estas organizaciones tienen procesos y procedimientos muy formales sobre lo que se registra y cuándo, cuáles son los procesos de revisión del código, etc.


Entonces, ¿cómo prueban su código los desarrolladores de MS y Google? Seamos realistas, no importa lo que hagamos, a menos que compilemos y ejecutemos nuestro código, nunca podremos estar seguros de que funciona.
Leo Jweda

Como arriba, depende del equipo en el que estés. Los equipos más grandes, como Windows, tendrán una estructura de rama grande y complicada que facilita la prueba local de arreglos individuales, con identificación temprana de problemas de integración a medida que el cambio se mueve hacia arriba en las ramas hasta que llega a WinMain. Eso es lo que tiene que hacer cuando tiene algo así como 5000 desarrolladores y SDET trabajando en el producto. Por cierto, los SDET en MS realmente programan mucho. Su código de prueba se verifica junto con el código del producto y debe cumplir con estándares de calidad y codificación similares.
jfawcett

3

No existe un libro de recetas 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 en el que 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 solo esto justifica la instalación, configuración y mantenimiento de un sistema de control de versiones.

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 los errores de compilación antes.


2

La respuesta corta - "Depende".

Actualmente, estoy trabajando en un proyecto por mi cuenta, así que soy yo quien construye / usa VCS. Sé de otros lugares en los que tienen equipos trabajando juntos en el proyecto por correo electrónico estremecedor . O equipos grandes (+5) que usan VCS.

En ese sentido, recomiendo encarecidamente aprender al menos algo de VCS, y Joel Spolsky tiene un excelente tutorial de introducción a 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; recomendaría leer los 10 años de archivos que tiene; toda es información muy útil y la mayor parte pertinente para su situación actual y futura.


Sin embargo, SVN es probablemente el más útil de aprender, ya que la mayoría de las personas no usan esos VCS distribuidos novedosos (al menos en una empresa).
Brendan Long

1
Casi cualquier sistema de control de versiones es mejor que ninguno. Las excepciones son VSS, RCS y SCCS; nadie debería usarlos en estos tiempos. (Si al menos nadie estaba hecho uso de ellos, pero eso es otra historia.)
Donal Fellows

@Brendan Long: La gente ha estado usando "esos nuevos VCS distribuidos" (específicamente, git en mi caso) en las empresas en las que he trabajado durante los últimos dos años.
PTBNL

@Donal Felllows: RCS es el único VCS en su lista que he usado, pero creo que usarlo sería mejor que nada. Estoy de acuerdo con su punto más amplio de que sería mejor pasar a uno más nuevo.
PTBNL

@PTBNL: Es muy fácil migrar de RCS a CVS. ¡Lo principal de lo que debes alejarte es que alguien que se haya ido de vacaciones bloquee el repositorio! No tengo ninguna duda de que existen mejores sistemas de control de versiones que CVS, pero definitivamente puede funcionar en la práctica.
Donal Fellows

1

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, siempre que lo estén comunicando, puede resultar en un gran progreso.


5
Esto no tiene nada que ver con la pregunta.
danben

1
/ en desacuerdo - según mi cálculo, la programación por pares es la edición más interesante y, a menudo, incluso la más productiva de 'programadores que trabajan juntos en un proyecto' ... que era esencialmente la cuestión. Es cierto que es un microcosmos, pero de hecho es mi favorito.
Hardryv

1

En primer lugar, los equipos trabajan mediante el uso de repositorios (que pueden ser un control de versiones profesional o simplemente un grupo de directorios que se considera el "en 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 trabaje (cascada, ágil, etc.). Si trabaja en iteraciones, crea componentes / complementos / módulos / bibliotecas que son autosuficientes y realiza pruebas unitarias, hasta que se firma como finalizada. Como equipo, trabajas en equipo, lo que significa que no trabajas en todo el proyecto en todas partes al mismo tiempo. En cambio, obtienes una tarea para realizar dentro de un ámbito del proyecto. En algunas ocasiones tienes que arreglar un código que no es tuyo, pero que suele ocurrir cuando ocurre un comportamiento extraño. Básicamente, estás probando las partes que desarrollas.

Déjeme 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 cuáles son las necesidades para construir y luego contrata a los constructores. El albañil arregla las paredes, las revisa para comprobar su resistencia y las pega muy bien. El electricista hace todo el cableado dentro del edificio para que la electricidad fluya. Cada hombre tiene su propio trabajo. A veces, el electricista puede querer discutir con el albañil si se pueden tallar ciertas paredes, pero siempre en conjunto con el capataz.

¡Espero que esto sea de alguna ayuda para ti!


0

Normalmente, el sistema de control de fuentes contiene el código fuente y normalmente no tiene los binarios. Si desea compilarlo y ejecutarlo, debe verificar el código y compilarlo en su máquina local.

Algunos lugares ejecutan compilaciones nocturnas 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 recibe una notificación automáticamente.


0

Una buena introducción a un método de uso del control de fuente es el CÓMO de control de fuente de Eric Sink http://www.ericsink.com/scm/source_control.html

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


0

Esta es de nuevo una buena razón por la que uno debería buscar proyectos de código abierto.

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

Todo lo que los demás mencionaron en sus respuestas (plan, sistema de control de versiones, seguimiento de problemas, sistema de notificación, sistema de compilación, suite de pruebas) se puede encontrar en estos proyectos de código abierto.

Si realmente desea una experiencia práctica, le sugiero que revise algunos proyectos de código abierto populares y grandes y luego obtenga el código fuente de cualquier proyecto (usando Control de versiones) y lo cree usted mismo.

PD: También soy estudiante y participar en proyectos OpenSource es lo mejor que he hecho en mi vida. ¡Créeme! también sentirás lo mismo.


Mencionar OpenSource, esa es una forma extraña de escribirlo, cuando registran archivos de origen con información de conexión de base de datos y demás, ¿cómo protegen esa información de las personas que pueden querer estropear las cosas?
Leo Jweda
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.