Buenas prácticas para el desarrollo en equipo
Ante la necesidad de coordinar un equipo de programadores que van a desarrollar una aplicación de forma colaborativa, se recomienda trabajar cada programador con su servidor de desarrollo individual, más uno corporativo donde mantener integrado el desarrollo de todo el equipo.
A continuación se detalla la metodología a seguir por el equipo de programadores, así como una serie de recomendaciones muy importantes que de forma conjunta nos ayudarán a que el desarrollo día a día sea lo más sencillo, productivo y fiable posible.
Cada programador deberá disponer de un servidor personal, será donde realizará de forma aislada y segura sus desarrollos. Además, tendrá sus propios datos de pruebas independientes del resto del equipo y nunca entrará en conflicto de concurrencia con otros desarrolladores.
El equipo dispondrá además de un servidor corporativo común, donde encontraremos la versión más actualizada al contener las integraciones de todos los miembros del equipo.
Haciendo uso de los servidores de desarrollo que Velneo facilita, podemos asignar sin problemas uno a cada desarrollador y disponer de otro corporativo.
Para garantizar la calidad de nuestros desarrollos se recomienda programar en Cloud, por ese motivo todos los desarrolladores disponen de su propio servidor en Velneo Cloud. Esta buena práctica consigue que el código desarrollado esté optimizado.
Lógicamente todos los servidores, corporativo y personales deben estar con la misma versión de la plataforma Velneo. Se recomienda que esta versión sea siempre la última disponible porque nos aporta más funcionalidad y estabilidad.
En todos los servidores de desarrollo instalaremos el componente Velneo vVersion encargado de almacenar las diferentes versiones de desarrollo de nuestras soluciones, lo que nos garantiza disponer de copias de seguridad y un comparador versiones para conocer los objetos y propiedades que han cambiado en un proyecto.
Cuando trabajamos con este componente en Cloud, para evitar un excesivo consumo de disco, debemos configurarlo indicando el número de días de copias de seguridad que se guardarán.
Después crearemos una tarea en el servidor que se encargará de limpiar las versiones caducadas que no estén marcadas para no ser borradas, por ejemplo versiones o revisiones cerradas que nos pueden interesar mantener. Consultar la documentación y especificaciones del componente.
Para comenzar a desarrollar debemos instalar la solución tanto en el servidor corporativo como en los servidores personales y si es posible con datos, que siempre ayudan al desarrollador en su trabajo.
Para esta primera instalación con datos debemos usar un fichero de instalación, con extensión .vin, creado con el componente Velneo vInstallBuilder que se instalará desde el componente Velneo vAdmin.
A partir de esta primera instalación, si solo queremos actualizar el código fuente de los proyectos de una o varias soluciones será más cómodo y operativo utilizar la opción Importar soluciones compartidas incluida en el menú soluciones de Velneo vDevelop.
Estas buenas prácticas de desarrollo ayudan a que todo el equipo funcione de forma homogénea y sea más productivo. Al trabajar orientados a aportar valor en ciclos de desarrollo cortos, entre 2 y 4 semanas, tanto el equipo como el cliente compartirán los constantes avances en el desarrollo y la validación de los mismos se realiza de forma constante y no una única vez al finalizar el proyecto. Existe abundante información sobre estos frameworks de trabajo ágil tipo Scrum.
A partir de aquí cada programador desarrolla la tarea asignada en su servidor personal con sus datos, sin interferencias ni bloqueos en su trabajo que le puedan causar otros miembros del equipo de desarrollo.
Una vez finalizada la tarea deberá testarla en su equipo para garantizar que cumple con los requisitos marcados.
Tras verificar que la programación ha pasado los tests solicitados en la tarea, debemos proceder a integrar los objetos creados o cambiados en el servidor corporativo.
Debemos tratar de integrar siempre tras finalizar la tarea ya que tendremos frescos los objetos a integrar y la prueba a realizar. Una vez integrados los objetos creados o modificados debemos proceder al testeo de la funcionalidad integrada, una vez más, pero ahora en el servidor corporativo. De esta forma verificaremos que la integración ha sido completa y correcta.
En este proceso de integración debemos tratar de ser lo más precisos que podamos, de forma que si hemos modificado un subobjeto, solo actualicemos dicho subobjeto y no todo el objeto. De este modo minimizamos el riesgo de pisar los cambios de otro programador del equipo.
Para poder realizar la integración de los desarrollos cada programador debe poder conocer detalladamente qué objetos ha modificado, creado y eliminado.
Si las modificaciones se han realizado en una sola sesión de edición con Velneo vDevelop podremos usar el botón de la toolbar objetos/últimos modificados, esta opción nos muestra la lista de objetos que debemos integrar.
Las líneas de separación entre objetos indican que el proyecto ha sido guardado.
Si las modificaciones se han realizado en varias sesiones o si queremos conocer con seguridad y al detalle las propiedades y subobjetos modificados Velneo vVersion nos permite comparar 2 versiones de un proyecto.
En nuestro caso como queremos integrar los cambios desarrollados para una tarea concreta seleccionamos el proyecto que teníamos al iniciar la tarea y el proyecto final de nuestro desarrollo y con el botón derecha del ratón seleccionamos la opción comparar versiones del menú contextual.
La operativa de integración consiste simplemente en editar la solución del servidor corporativo en una ventana de Velneo vDevelop y la versión de nuestro servidor personal en otra ventana de Velneo vDevelop e ir copiando de uno a otro las modificaciones documentadas.
Para esto nos aprovechamos de la potencia del portapapeles que permite copiar cualquier objeto entre 2 Velneo vDevelop de la misma versión. Podemos copiar y pegar tanto un objeto como subobjeto y también podemos copiar y pegar múltiples objetos o subobjetos a la vez.
Para evitar que otro desarrollador pise mis modificaciones en un objeto que ya existe, antes de importar componentes de la solución debo cambiar el color del objeto con mi color asignado, cada desarrollador debe tener su color específico, de esta forma otro desarrollador cuando importe componentes antes de editar ese objeto verá que está con el color de otro desarrollador lo que implica que hay concurrencia de más de un desarrollador sobre el mismo objeto.
El desarrollador que se encuentra con el objeto de otro color diferente al negro debe ponerse en contacto con el otro desarrollador para consensuar los cambios que vayan a realizar en el objeto, ya que se puede acordar no integrar el objeto completo sino solo los subobjetos modificados.
Una vez actualizado el servidor corporativo, debemos realizar el testeo de nuevo en este servidor, para comprobar que se ha realizado correctamente la integración.
El paso de todos los test nos garantiza que hemos integrado todos los objetos y subobjetos y que no se ha producido ninguna incompatibilidad con el código desarrollado por otros miembros del equipo.
Además, el realizar las pruebas en Cloud nos garantiza que nuestros desarrollos están optimizados, ya que en caso contrario lo vamos a detectar.
La funcionalidad de abrir un proyecto en modo lectura nos es muy útil durante la integración, ya que permite que mientras un programador tiene bloqueado un proyecto, el resto lo puedan abrir en modo lectura.
Esto nos permite no solo ver los objetos sino también copiar los objetos del proyecto, sin necesidad de esperar a que el otro programador finalice y libere el proyecto.
También podemos acceder a un proyecto en modo solo lectura cuando no vamos a realizar modificaciones, dejándolo disponible para su edición y evitando problemas de bloqueos.
Una vez finalizada la integración en el servidor corporativo, el último paso que debemos realizar es la actualización de la solución de nuestro servidor personal. Para esta labor se recomienda utilizar la opción ya mencionada de importar soluciones compartidas.
De este modo el programador ya está en disposición de comenzar de nuevo el ciclo de desarrollo de una nueva tarea.
Para que un equipo de programadores sea lo más productivo posible y pueda trabajar de una forma cómoda y segura es necesario que los programadores compartan sus normas de programación, esto ayuda a que el código tenga mayor calidad y claridad lo que facilita que sea homogéneo y fácil de mantener por cualquier miembro del equipo.
El uso de normas a la hora de programar es imprescindible para desarrollar aplicaciones robustas y mantenibles. La documentación incluye un conjunto de buenas prácticas recomendadas, que pueden servir de base para que cada equipo defina las suyas. Para este fin podemos utilizar cualquier aplicación estándar o desarrollada por nosotros mismos.
- Diccionario de abreviaturas. Son muchas las razones por las cuales programar utilizando abreviaturas en los identificadores de objetos. Tan importante como esto es que las abreviaturas sean de uso común, para lo que es importante contar con una base de datos con las abreviaturas, sus significados y sinónimos. En Velneo vTutor existe una base de datos de ejemplo que se puede usar de punto de partida.
- La organización de objetos en carpetas es muy útil para que al intentar acceder a un objeto lo podamos encontrar rápidamente.
- Comentar bien el código que realizamos a fin de que cualquier otro programador lo pueda entender y mantener mejor.
La comunicación debe ser continua entre el equipo de programación, por lo que se recomienda disponer de un chat conjunto del proyecto.
Antes de abrir Velneo vDevelop cada programador debería conectarse al chat del equipo y ver si hay algún comentario relevante, que no haya leído para poder comenzar a programar.
Da igual el sistema que utilicemos, puede ser Skype, Hangout, Messenger, Mensajería interna, etc. lo importante es la comunicación directa e instantánea entre los miembros del equipo, y que la resolución de dudas sea ágil para facilitar un desarrollo continuo.
Es recomendable que la comunicación sea por escrito, independientemente de la localización física de los programadores. De esta forma no produce ruido ni distracciones en el ambiente de trabajo y permite que exista un histórico de todo lo comentado donde recurrir ante dudas o ausencias.
Es recomendable que siempre que cerremos una versión o revisión, entendiendo por versión cualquier instalación o modificación del código para cliente final, realicemos una copia del código fuente.
Cada versión debe estar numerada e identificada de forma inequívoca. Con el uso de Velneo vVersion y la posibilidad de bloquear los proyectos, ya podemos disponer de la versión, pero siempre será más cómodo y seguro disponer de un instalable que incluye todas las soluciones y proyectos de una determinada versión.
Es aconsejable tener definido un protocolo de numeración y que sea sencillo de leer e identificar la versión y revisión. Por ejemplo:
miapp_setup_1_0_5276
- mi_app es el nombre del producto.
- setup indica a los usuarios no programadores que es un fichero de instalación.
- El 1 es el nº de versión.
- El 0 es el nº de revisión.
- 5276 es el nº historia. Es recomendable incluir algún dato identificativo que relacione el fichero vin con el código de la solución. Un buen dato puede ser el nº historia del proyecto de ejecución o el más representativo de nuestra solución.
Última actualización 3yr ago