Arquitectura y diseño de un entorno de desarrollo - decharlas

organizan patrocinan

colaboran

Jornadas Symfony 5 y 6 de julio 2010Universitat Jaume I, Castellón

http://decharlas.uji.es/symfony

Arquitectura y diseño de un entorno de desarrolloRicardo Borillo, Universitat Jaume [email protected]

Jornadas Symfony 5 y 6 de julio 2010Universitat Jaume I, Castellón

http://decharlas.uji.es/symfony

sesión patrocinada por

http://www.lsi.uji.es/

Jornadas Symfony http://decharlas.uji.es/symfony

Índice

Características, requisitos y arquitectura de los entornos de desarrollo actuales

Metodologías de desarrollo: Clásicas vs Ágiles

Herramientas de documentación y gestión del conocimiento

Sistemas de control de versiones

Herramientas de construcción

Integración contínua

Gestión de proyectos e incidencias

Pruebas unitarias del software

Repositorio de componentes

Aseguramiento de la calidad: Análisis estático del codigo

IDE para el desarrollo de aplicaciones. Conexión entre todos los elementos



Los tres aspectos más importantes en un equipo de desarrollo:

Personas, personas y personas



Objetivos para el equipo humano: Formación:

Todos conocen el entorno y herramientas Todos conocen la tecnología Transferencia de conocimiento de los más expertos

a los menos expertos

Motivación: Todos pueden asumir tareas de innovación A cualquiera se le puede asignar cualquier tarea



Características del entorno: Equipos de trabajo de tamaño limitado Visión integrada de producto:

Pautas comunes Reutilización de código Módulos específicos para cada necesidad

Estándares de desarrollo bien definidos (directrices a seguir)



Objetivos: Producir software de calidad (sin bugs) Producir software mantenible y documentado Entorno de trabajo adecuado:

Integrado Predecible Alto de nivel de interacción entre desarrolladores

Propiedad colectiva del código



En definitiva ...

QAJornadas Symfony http://decharlas.uji.es/symfony


Arquitectura deseable: Separación entre desarrollo y producción Despliegue controlado de aplicaciones Compartición de código Registro global de bugs, tareas y mejoras Testeo automático de aplicaciones Documentación de funcionalidades y procesos



¿¿¿Cómo consigo todo esto???


Índice






Integración continua




Aseguramiento de la calidad: Análisis estático del código




Metodologías clásicas:

Análisis, diseño, implementación y pruebas Análisis apoyado en notaciones gráficas: DFD, E/R,

UML Estricto, rígido y poco reactivo a cambios (toma de

requisitos inicial) Metodologías ágiles:

Desarrollo iterativo El código es la base Ágil, dinámico y muy flexible



XP: eXtreme Programming



El Manifiesto Ágil valora: A los individuos y su interacción, por encima de

los procesos y las herramientas El software que funciona, por encima de la

documentación exhaustiva La colaboración con el cliente, por encima de la

negociación contractual La respuesta al cambio, por encima del

seguimiento de un plan



XP es una metodología ágil: Diseñada para entornos dinámicos Pensada para equipos pequeños (hasta 10

programadores) Orientada fuertemente hacia la codificación Énfasis en la comunicación informal, verbal



Programador:

Responsable de decisiones técnicas y de construir el sistema

Sin distinción entre analistas, diseñadores o codificadores

En XP, los programadores diseñan, programan y realizan las pruebas

Jefe de Proyecto:

Organiza y guía las reuniones

Asegura condiciones adecuadas para el proyecto

Cliente:

Es parte del equipo

Determina qué construir y cuándo

Establece las pruebas funcionales



Captura de requisitos: Historias del Usuario (User-Stories) Establecen los requisitos del cliente

Trozos de funcionalidad que aportan valor

Se les asignan tareas de programación con un nº de horas de desarrollo

Las establece el cliente

Son la base para las pruebas funcionales



Planificación: Planificación por entregas (releases)

Se priorizan aquellas user-stories que el cliente selecciona porque son más importantes para el negocio

Entregas:

Son lo más pequeñas posibles Se dividen en iteraciones (iteración = 2 o 3 semanas) Están compuestas por historias

A cada programador se le asigna una tarea de la user-story



Programación: La programación de tareas se realiza por parejas

La pareja diseña, prueba, implementa e integra el código de la tarea

Código dirigido por las pruebas (TDD)

Código modular, intentando refactorizar siempre que se pueda



Practicas: El juego de la planificación

Entregas pequeñas

Diseño simple

Pruebas

Refactoring

Programación en parejas (compartir experiencia / detectar fallos)

Propiedad colectiva


Cliente in situ

Estándares de programación



SCRUM



Roles principales: Scrum Master, Product Owner y Team. El resto son “gallinas”



Conclusión: No todo es blanco ni negro

Método = Conjunto ordenado de buenas prácticas


Índice














Requisitos: Formato estándar de representación Documentación accesible online Fácil modificación y mantenimiento Conversión a otros formatos como PDF Búsqueda y buena gestión del conocimiento



Posibles alternativas y puntos fuertes: Wiki:

Sintaxis sencilla Herramienta online Multitud de herramientas (MediaWiki, Confluence,

DokuWiki) DocBook:

XML Fácilmente convertible a otros formatos



Wiki:



DocBook:


Índice














Requisitos: Repositorio unificado para el código Soporte para el versionado Soporte para realizar comparaciones entre

versiones Compartición de código entre desarrolladores Integrado con las herramientas de desarrollo



Tipos de repositorios: Centralizados (CVS o Subversion):

Existe un repositorio centralizado con todo el código

Para trabajar sobre un recurso, hay que descargar una copia local

Los ficheros modificados hay que subirlos de nuevo para que estén accesibles para todos

Los desarrolladores sólo tienen en su copia local aquellos fuentes que han solicitado del servidor



Tipos de repositorios: Distribuidos (GIT o Mercurial):

No hay un repositorio central Todos los desarrolladores tienen su propia copia del

repositorio, con todas las versiones y toda la historia. Permiten que dos desarrolladores puedan compartir

cambios (sincronizarse). Suele haber un repositorio de fuentes que se considera

oficial o central (obtener la primera copia, versiones probadas, backup)


Índice














Requisitos: Evitar compilación, construcción y despliegue manual

del código

Independencia del IDE

Flexibilidad y soporte para casi cualquier tipo de herramienta necesaria

Integración de las pruebas unitarias, generación de documentación, despliegue en pre-producción, métricas de código … Todo en uno y desde un único sitio!!



Objetivos: Evitar errores Aplicación desplegable por cualquiera sin

conocimientos concretos de la misma Control automático de las dependencias Integración completa con el entorno Necesario ejecutar siempre los controles de

calidad



Apache Ant o Phing: Similar a los makefiles, pero con sintaxis XML

Originalmente para Java, aunque se usa para cualquier lenguaje. Phing ofrece funcionalidades específicas PHP

Proceso de construcción = Secuencia de ”targets”

Cada ”target” realiza un paso del proceso y ejecuta ”tasks”

Muchas ”tasks” ya predefinidas: Compilación, SCP, empaquetado, ejecución de tests unitarios, etc

Muy buena integración con Eclipse/Netbeans si usamos Ant



<?xml version=”1.0”?>

<project name="Money" default="build">

<target name="clean">

<delete dir="${basedir}/build"/>

</target>

<target name="prepare">

<mkdir dir="${basedir}/build/logs"/>

</target>

<target name="phpunit">

<exec dir="${basedir}" executable="phpunit" failonerror="true">

<arg line="--log-xml ${basedir}/build/logs/junit.xml

--coverage-clover ${basedir}/build/logs/clover.xml MoneyTest" />

</exec>

</target>

</project>



Apache Maven o php-maven: Desarrollo Java + extensión PHP

Todos los proyectos tienen la misma estructura y siguen el mismo proceso de construcción: Life-cycle

Gestión automática de dependencias

Multitud de plugins existentes para distintas necesidades

Puede utilizar Ant



<project>

<modelVersion>4.0.0</modelVersion>

<groupId>com.mycompany.app</groupId>

<artifactId>my-app</artifactId>

<packaging>php</packaging>

<version>1.0-SNAPSHOT</version>

<dependencies>

<dependency>

<groupId>org.phpunit</groupId>

<artifactId>phpunit5</artifactId>

<version>3.2.9-SNAPSHOT</version>

</dependency>

</dependencies>

</project>



Creación de nuevos proyectos:

mvn archetype:generate \

-DarchetypeGroupId=org.phpmaven \

-DarchetypeArtifactId=php5-lib-archetype \

-DarchetypeVersion=1.0 \

-DgroupId=org.sample \

-DartifactId=my-app \



Layout resultante:


my-app

|-- pom.xml

`-- src

|-- main

`-- php

`-- org.sample

`-- app.php

`-- webapp

`-- index.php

|`-- test

`-- php

`-- org.sample

`-- apptest.php

Índice














Martin Fowler:”Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.”



Hudson: Independiente del lenguaje Construcción de software y monitorización de

procesos tipo CRON Centenares de plugins Responsable de generar todos los artefactos

necesarios para una aplicación: Documentación, binarios, tests, informes, análisis del código, etc.



Ejemplo disponible online: http://hudson.highsource.org/

Configuración para PHP: http://bit.ly/3PuA3p http://bit.ly/9EgmN http://bit.ly/151csf


http://hudson.highsource.org/

http://bit.ly/3PuA3p

http://bit.ly/9EgmN

http://bit.ly/151csf


PhpUnderControl:http://phpundercontrol.org/about.html

Testing con phpUnit Documentación con PhpDocumentator Análisis del código con PHP_CodeSniffer y

CheckStyle


http://phpundercontrol.org/about.html


CruiseControl:http://cruisecontrol.sourceforge.net/

Atlassian Bamboo:http://www.atlassian.com/software/bamboo/


http://cruisecontrol.sourceforge.net/

http://www.atlassian.com/software/bamboo/

Índice














Requisitos: Registrar todas las posibles modificaciones que

se hagan sobre el software: Bugs, tareas, mejoras, etc.

Reparto de la carga entre los desarrolladores Planificación de versiones en nuestro software Histórico de acciones: Changelog. Cada tarea

añade todos los comentarios hasta que se cierra



JIRA: Integración con Netbeans y Eclipse

(Mylyn) Interfaz altamente usable Muchas métricas de evolución del

proyecto API XML-RPC disponible



Ejemplo disponible online: http://jira.codehaus.org/


http://jira.codehaus.org/

Índice











IDE para el desarrollo de aplicaciones. Conexión con los distintos elementos de la arquitectura



Unit testing Wikipedia:

”In computer programming, unit testing is a software verification and validation method in which a programmer tests if individual units of source code are fit for use. A unit is the smallest testable part of an application”



Beneficios: Facilitar el cambio y el refactoring Integración más sencilla Documentación del código Diseño siempre y modular del código

(sino no se puede hacer unit testing)



Tipos de pruebas: Unitarias o de desarrollo Integración Rendimiento o estrés Funcionales



Unit testing en symfony: symfony 1.x: Lime:

Simplicidad, pero difícil uso en herramientas de integración continua

Soporte para Mocks y Stubs http://martinfowler.com/articles/mocksArentStubs.html

symfony 2.0. Paso a PhpUnit.


http://martinfowler.com/articles/mocksArentStubs.html


class MoneyTest extends PHPUnit_Framework_TestCase

{

protected $f12EUR;

protected $f14EUR;

protected function setUp()

{

$this->f12EUR = new Money(12, 'EUR');

$this->fMB1 = MoneyBag::create($this->f12EUR, $this->f21USD);

}

public function testBagMultiply()

{

$expected = MoneyBag::create(new Money(24, 'EUR'), new Money(14, 'USD'));

$this->assertTrue($expected->equals($this->fMB1->multiply(2)));

}




phpunit:

[exec] PHPUnit 3.4.14 by Sebastian Bergmann.

[exec] ....................F.

[exec] Time: 1 second, Memory: 6.25Mb

[exec] There was 1 failure:

[exec] 1) MoneyTest::testSimpleNegate

[exec] Failed asserting that <boolean:false> is true.

[exec] /tmp/Money/MoneyTest.php:238

[exec] FAILURES!

[exec] Tests: 22, Assertions: 35, Failures: 1.

[exec] Writing code coverage data to XML file, this may take a moment.

BUILD FAILED

/tmp/Money/build.xml:36: exec returned: 1


Herramientas: Pruebas de código: jUnit, Nunit,

PHPUnit, PyUnit y otras muchas Pruebas de interfaz: Selenium Pruebas de estrés: Apache jMeter con

independencia del lenguaje en el que esté desarrollado el servicio



TDD Wikipedia:”El desarrollo guiado por pruebas, o Test-driven development (TDD) involucra otras dos prácticas: Escribir las pruebas primero (Test First Development) y Refactorización (Refactoring). Para escribir las pruebas generalmente se utilizan las pruebas unitarias (unit testing). En Primer Lugar se escribe una prueba y se verifica que las pruebas fallen, luego se implementa el código que haga que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito. El propósito del desarrollo guiado por pruebas es lograr un código limpio que funcione (clean code that works). La idea es que los requerimientos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizará que los requerimientos se hayan implementado correctamente.”Jornadas Symfony http://decharlas.uji.es/symfony


Otros conceptos relacionados: Cobertura: porcentaje de nuestro

código cubierto o probado por nuestros tests unitarios

Mock o impostor: Objetos que imitan el comportamiento de objetos reales de una forma controlada. Como un dummy en una prueba de colisión


Índice














Objetivos: Repositorio Maven de artefactos

Proxy-cache que recoge cualquier librería utilizada

Si necesitamos una librería externa, nos la consigue

Control total sobre los productos y versiones utilizadas

Lugar único de publicación de nuestros artefactos

Gestión integrada de librerías, control de acceso, backup, gestión web, etc



Ejemplo disponible online: http://repo.jfrog.org/artifactory/webapp/home.html


http://repo.jfrog.org/artifactory/webapp/home.html

Índice














Análisis estático del código: El análisis estático del código es el proceso de

evaluar el software sin ejecutarlo Técnica que se aplica directamente sobre el

código fuente, sin transformaciones previas ni cambios de ningún tipo

Objetivo: Obtener información que nos permita mejorar la base de código



Objetivo. Encontrar partes del código que puedan: Reducir el rendimiento Provocar errores en el software Complicar el flujo de datos Tener una excesiva complejidad (complejidad

ciclomática) Suponer un problema en la seguridad



Algunas herramientas para PHP: PHP_Depend: Escaneo del código fuente en forma de

árboles de sintaxis abstractos (AST) para el cálculo de ciertas métricas de calidad como la complejidad ciclomática de los métodos.

PHP_CodeSniffer: Detección de patrones de error o zonas de código potencialmente peligrosas

PhpCPD: Detector de código duplicado (Copy&Paste detector).



Algunas herramientas para PHP: PhpMD. Como Php_Depend pero con algunas

funcionalidades de PHP_CodeSniffer (PHP Mess Detector).

Sonar: Servidor que ejecuta todos los anteriores en forma

de plugins + muchos otros (cobertura con clover, PhpUnit, etc)

Integrable desde Ant/Phing/Maven



Varios proyectos de libres analizados con Sonar: http://nemo.sonarsource.org/

Intergración con proyectos PHP: http://www.blacksun.fr/2009/12/sonar-for-php-is-on-its-way/


http://nemo.sonarsource.org/

http://www.blacksun.fr/2009/12/sonar-for-php-is-on-its-way/

Índice










Aseguramiento de la calidad: Análisis estático del codigo



IDE para el desarrollo de aplicaciones

Eclipse/Netbeans como elemento integrador:

Plugin Subversion Plugin Ant/Phing/Maven Plugin Mylyn integración con JIRA Plugin jUnit/phpUnit Plugin análisis estático del código aún

desde Ant/Phing


Fin

¿Preguntas?


Arquitectura y diseño de un entorno de desarrollo - decharlas

Technology

Transcript of Arquitectura y diseño de un entorno de desarrollo - decharlas