unit-testing - test - tdd ejemplo

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

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 gracioso porque es real y la gente reconoce las situaciones en las que se encuentra.

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á

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).

En primer lugar, los equipos trabajan utilizando repositorios (que pueden ser controles de versiones profesionales, o simplemente un conjunto de directorios que se consideran "en vivo", sin embargo, un sistema de control de revisiones es el estándar de facto). Además, la forma en que se gestiona el proyecto depende de la estrategia de trabajo (cascada, ágil, etc.). Si trabaja en iteraciones, compila componentes / complementos / módulos / bibliotecas que son autosostenibles, y realiza pruebas unitarias, hasta que se cierra como terminado. Como equipo, trabajas en un equipo, lo que significa que no trabajas en todo el proyecto en todas partes al mismo tiempo. En su lugar, obtienes una tarea para realizar dentro de un ámbito del proyecto. En algunas ocasiones, debe corregir un código que no es suyo, pero eso suele ocurrir cuando se produce un comportamiento extraño. Básicamente, estás haciendo las pruebas de las partes que desarrollas.

Déjame ejemplificar esto para ti. 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 hace las paredes, las comprueba con fuerza 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 se pueden tallar ciertas paredes, pero siempre en conjunto con el capataz.

¡Espero que esto sea de ayuda para ti!

Esta es una vez más una buena razón por la que uno debe considerar proyectos de código abierto.

Los desarrolladores principales que trabajan en grandes proyectos OpenSource (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 dichos profesionales.

Todo lo que otros mencionaron en sus respuestas (Plan, Sistema de control de versiones, Rastreador de incidencias, Sistema de notificaciones, Sistema de compilación, Conjunto de pruebas) se puede encontrar en estos proyectos de OpenSource.

Si realmente quieres una experiencia práctica, te sugiero encarecidamente que pases por algunos proyectos populares y grandes de OpenSource y luego obtengas la Fuente de cualquier proyecto (usando el Control de versiones) y compórtala tú mismo.

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

La programación adecuada es una cosa profunda que se beneficia enormemente de la experiencia. La programación de pares es como ejecutar múltiples procesadores de conciencia ... uno puede pasar por alto algo visto por el otro y en tanto se comuniquen puede resultar en un gran progreso.

La respuesta corta - "depende".

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

En ese sentido, recomiendo 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 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 habla sobre la mayoría de tus preguntas, recomiendo leer los 10 años de archivos que tiene, es información muy útil y la mayoría pertinente para tu situación actual y futura.

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 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á 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.
Rastreador de problemas : no puede realizar 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. 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 limitado 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. Tiene que ser tan fácil de ejecutar como la construcción (ser parte de la construcció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.

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.

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.

Normalmente, el sistema de control de origen contiene el código fuente y, por lo general, 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 servidor. Si la compilación o cualquier otra cosa falla, alguien recibe una notificación automáticamente.

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 :-)

Una buena introducción a un método para usar el 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, utiliza SourceGear Vault desde que lo escribió y todo, pero los métodos se pueden aplicar a otros sistemas de control de versiones.

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

Todo el código fuente del proyecto y todo lo que se requiere para compilarlo está bajo control de versión (también llamado control de fuente). Cualquiera debería ser capaz de construir todo el proyecto con un solo clic.
Además, los archivos innecesarios (archivos de objeto o binarios compilados) no deberían agregarse al repositorio, ya que se pueden regenerar con bastante facilidad y solo desperdiciarían espacio en el repositorio.
Cada desarrollador debe actualizar y comprometerse con el control de versiones varias veces al 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: cualquiera debe poder 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 deben probar la nueva característica o corrección de errores que están agregando antes de enviarlos al repositorio.
Configure un servidor que regularmente (en intervalos predeterminados) se actualice desde el repositorio e intente construir todo en el proyecto completo . 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 compilaciones también se denominan 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, todos deberían estar familiarizados con el diseño / la 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.
Se necesita algún tipo de comunicación 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 el standup diario es útil en los equipos SCRUM.
Las pruebas unitarias son una muy buena práctica que hace que la prueba de la funcionalidad básica de su código sea automática.
Un software de seguimiento de errores (a veces 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 función que le llevaría días implementar y que bloquearía a otras personas para que compile (y pruebe) el proyecto, use la función de ramas del control de la 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 cuando lo necesites : comienza con un control de versiones y un rastreador de errores, y luego configura el servidor de integración continua, si lo necesitas. (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 , compilaciones diarias son tus amigos , control de versiones , pruebas unitarias

Ejemplos:

Para el control de versiones, tiendo a usar Git para mis proyectos personales hoy en día. Subversion 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 usamos Mantis en un lugar de trabajo anterior.

Para el software de integración continua, hay 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 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.