¿Cómo trabajan los programadores en un proyecto?

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

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.

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

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.

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

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.

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.

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.

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.

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.

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!

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.

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.

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.