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


Siempre he programado solo, todavía soy 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 el 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á


75
2018-06-08 18:33


origen


Respuestas:


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

Las mejores prácticas que siempre son útiles

  • Todas 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). Nadie debería ser capaz de construir todo el proyecto con un solo clic.
    Además, los archivos innecesarios (archivos de objeto o binarios compilados) deberían no se agregará al repositorio, ya que se pueden regenerar con bastante facilidad y solo desperdiciarían espacio en el repositorio.
  • Todo desarrollador debería actualizar y cometer al control de versiones algunas veces por día. Principalmente cuando han terminado la tarea en la que están trabajando y la han probado lo suficiente para que sepan que no contiene errores triviales.
  • De nuevo: nadie debería ser capaz de construir el proyecto con un solo clic. Esto es importante y hace que sea fácil de probar para todos. Gran ventaja si los no programadores (por ejemplo, el jefe) también pueden hacerlo. (Les hace sentir que pueden ver exactamente en qué está trabajando el equipo).
  • Todos los desarrolladores debería probar la nueva característica o corrección de errores que están agregando antes de ellos los comprometen con el repositorio.
  • Configure un servidor que regularmente (en intervalos predeterminados) se actualice desde el repositorio e intente construir todo en el proyecto entero. Si falla, envía correos electrónicos al equipo junto con las últimas confirmaciones para el control de la versión (desde qué compromiso no pudo compilarse) para ayudar a solucionar el problema.
    Esta práctica se llama integración continua y las construcciones también se llaman construcciones nocturnas.
    (Esto no implica que los desarrolladores no deban construir y probar el código en sus propias máquinas. Como se mencionó anteriormente, deberían hacerlo).
  • Obviamente, todo el mundo debe estar familiarizado 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 un código reutilizable es algo bueno.
  • Alguna clase de comunicaciónes necesario entre los miembros del equipo. Todos deberían estar al tanto de lo que los demás están haciendo, al menos un poco. Mientras más, mejor. Esta es la razón por la cual standup diario es útil en los equipos SCRUM.
  • Examen de la unidad es una muy buena práctica que hace que la prueba de la funcionalidad básica de tu código sea automática.
  • UN software de seguimiento de errores (aveces llamado software de seguimiento de tiempo) es un muy buen medio para hacer un seguimiento de los errores que existen y las tareas que tienen los diferentes miembros del equipo. También es bueno para probar: 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 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 cometan cosas que no se compilan en el repositorio principal.
Si desea incluir una nueva característica que tomaría días implementar y que bloquearía a otras personas para que no construya (y pruebe) el proyecto, use el ramas característica de su control de versión.

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

Algunos pensamientos más

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

Algunos enlaces útiles:
Integración continua, Las compilaciones diarias son tus amigos, Control de versiones, Examen de la unidad

Ejemplos:

Para el control de versiones, tiendo a usar Git para mis proyectos personales hoy en día. Subversión también es popular, y por ejemplo, VisualSVN es bastante fácil de configurar si usa un servidor de 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 utilizamos Mantis en un lugar de trabajo anterior.

Para software de integración continua, hay Teamcity para uno (también, CruiseControl y es 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 principal es la persona que habla con el personal financiero / de 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 generalmente involucran a 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.


54
2018-06-08 19:00



También soy estudiante y completé recientemente un curso de ingeniería de software en el que 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ó 12 de nosotros durante todo el semestre. Trabajar con personas 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 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 lo que están haciendo sus compañeros de equipo para que no haya conflictos. Tampoco se siente en su código, haga que las confirmaciones más rápidas y significativas para el repositorio sean las más efectivas.

** También recomendaría un rastreador de errores, como Redmine. Puede configurar cuentas para todos y asignar tareas a personas con diferentes prioridades, y también rastrear 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 enormemente. ¡La mejor de las suertes! Espero que esto haya ayudado :-)


11
2018-06-08 19:41



Las grandes cosas son:

  • Un plan - Si la gente no sabe a dónde van, no irán a ninguna parte. Por lo tanto, el inicio de cualquier proyecto necesita algunas personas (a menudo el proyecto Barbas grises) para formar un grupo y elaborar un plan; el plan no necesita ser muy detallado, pero aún así es obligatorio.
  • Sistema de control de versiones - Sin esto, no estás trabajando en conjunto. También necesita el firme compromiso de que si las cosas no están comprometidas, no cuentan. "Oh, está en uno de mis areneros" es solo una excusa débil.
  • Seguimiento de problemas - No se puede hacer un seguimiento de estas cosas por carpetas de correo electrónico. Definitivamente debe 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 si se hacen comentarios a los errores de los que son responsables. Email poder trabajar para esto, al igual que IRC (siempre que todos lo usen, por supuesto).
  • Sistema de compilación - Realmente no 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 limitado de desarrollo como del repositorio principal. La mejor opción para esto depende de qué idioma (s) está usando.
  • Banco de pruebas - Un conjunto de pruebas ayuda a las personas a evitar errores tontos. Tiene que ser tan fácil de ejecutar como la compilación (formar parte de la compilación es bueno) Tenga en cuenta que las pruebas son solo un crudo sustituto de la corrección, pero son muchísimo mejor que nada.

Finalmente, necesita la voluntad de trabajar juntos para cumplir el plan. Eso es demasiado a menudo la parte difícil.


8
2018-06-08 20:00



En general, es una buena práctica no verificar los artefactos de construcción en el repositorio. El repositorio contendrá el árbol fuente, la configuración de compilación, etc., cualquier cosa escrita por un ser humano. Los ingenieros de software verificará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 forma, un desarrollador sabrá instantáneamente si sus cambios han invalidado cualquiera de las pruebas unitarias, y tendrá la oportunidad de corregirlos 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 están Ant y Maven).


7
2018-06-08 18:37



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 divertido no porque sea un personaje cómico como Goofy. Es gracioso porque es real y la gente reconoce las situaciones en las que se encuentra.

Comic


5
2018-06-09 12:27



No hay un estándar para las cosas que preguntas. Por el contrario, existen convenciones que dependen en gran medida del tamaño y la madurez de la organización. Si se encuentra 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 proceso y un ingeniero de construcción dedicado. Por lo general, este tipo de organización realiza una compilación formal, por ejemplo, una vez al día, utilizando cualquier código fuente que esté registrado. El proceso generalmente también incluirá BVT (pruebas de validación de compilación) y quizás algunas pruebas de regresión. Los desarrolladores verifican el código del repositorio, trabajan en su propia porción localmente y luego lo registran.

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


3
2018-06-08 18:43



La respuesta corta - "depende".

Actualmente, estoy trabajando en un proyecto solo, por lo que soy quien crea / usa VCS. Sé de otros lugares en los que tiene equipos que trabajan juntos en el proyecto estremecimiento correo electrónico. O equipos grandes (+5) que usan VCS.

En ese sentido, recomiendo aprender al menos algunos VCS, y Joel Spolsky tiene un gran introducción tutorial para Mercurial. Bazaar (mi elección personal) es similar, y luego Git es el próximo 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 negociaciones sobre la mayoría de sus preguntas, recomiendo leer los 10 años de archivos que tiene, es información muy útil, y en su mayor parte pertinente a su situación actual y futura.


2
2018-06-08 18:45



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 donde usted es el único desarrollador. Incluso en este caso, la posibilidad de revertir versiones y leer el registro de la versión es una gran ayuda para corregir errores. Esta no es la única característica de un sistema de control de versiones, pero esto solo justifica la instalación, configuración y mantenimiento de un sistema de control de versiones.

La compilación puede ser hecha por cada desarrollador al agregar un 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 más pronto.


2
2018-06-08 22:18