Este documento resume una presentación sobre buenas prácticas para el desarrollo web en PHP. La presentación cubre temas como el uso de IDEs, estándares de codificación, documentación interna de código, control de versiones, seguimiento de incidencias, uso de wikis, metodologías ágiles, frameworks de PHP, bibliotecas, seguridad, depuración, pruebas unitarias, pruebas automatizadas, integración continua, métricas, rendimiento, despliegues, entornos, búsqueda y equipo.
1. “AL RICO” PHP
Cositas que deberíais saber y que probablamente
ya sabéis y que en caso contrario deberías saber, porque
sino lo sabéis, vais a sufrir...
Carlos Buenosvinos (@buenosvinos)
Castellón, Universitat Jaume I (decharlas.com)
16 de Mayo de 2010
18:00 - 20:00
2. CARLOS BUENOSVINOS
Certified Zend PHP and Zend Framework Engineer
Certified Scrum Master (CSM)
PHP Barcelona User Group Cofounder
Scrum Master and Tech Lead at Emagister.com
@buenosvinos
carlos@quepimquepam.com
8. OBJETIVOS
1.Desarrolladores: Conocer qué se espera de un buen
profesional del desarrollo web en PHP.
2.Tech Leads y CTOs: Evaluar el nivel de madurez de
vuestro equipo y ciclo de desarrollo.
3.Todos: Descrubir conceptos nuevos que investigar en casa y
aplicar en vuestro día a día
4.Yo: Comerme un buen arrocito
12. CARACTERÍSTICAS (I)
• Lenguaje pensado por y para la Web
• Fácil y Popular
• Hasta en la sopa
• Pragmático
• Time to Market
13. CARACTERÍSTICAS (II)
• Easy to learn, difficult to master
• Inconsistencia (a mejorar en PHP 6.0)
• Relación con otros lenguajes (Ruby, Python, JAVA, .NET,
Perl)
15. IDE
• ¿Todos los developers el mismo IDE o cada uno el que quiera?
• Existentes: Eclipse PDT, NetBeans, Zend Studio, Komodo, VIM, etc.
• A considerar: Cross referencing, Control de Versiones, Search and Replace
potente (+ integraciones con Check Style, Unit Tests, etc.)
• Trucos
• Intentar unificar al máximo el entorno de desarrollo (menos
documentación, casos y mejor soporte interno)
• Meter en la WIKI todo lo relacionado con la instalación, configuración, etc.
17. CODING STANDARDS
• Define reglas de codificación y garantiza la legibilidad del código
• Uno propio vs. uno ya existente (DRW)
• Existentes en PHP (PEAR y Zend Framework)
• Herramientas
• phpcs (PHP Code Sniffer): Analiza el código fuente y genera resultados sobre las violaciones
• Trucos
• Documentarlo en la Wiki y crear un responsable
• Integrarlo como un precommit hook en vuestro VCS
• Integrarlo con vuestro servidor de integración continua para tener informes semanales con la
evolución de la violaciones en la codificación y tomar acciones
19. INLINE DOCUMENTATION
• ¿Documentamos el código o no?
• A: “No haría falta documentar si los nombre de los métodos son claros”
• B: “Lo documentamos todo” (type hinting del IDE)
• Herramientas
• phpDoc
• Doxygen
• Trucos
• Política de documentación a la Wiki
• Integrarlo con el servidor de integración continua para tener la documentación actualizada con cada build
• ¡La documentación no está en el Control de Versiones!
21. CONTROL VERSION SYSTEM
• SVN, GIT o Mercurial (A poder ser, los dos primeros)
• Herramienta web de visualización (por ejemplo, websvn)
• Evitar las branches tanto como sea posible (no inventéis políticas de branching
especiales)
• Trucos
• Utilizar los hooks para realizar acciones interesantes (Vincular commits con
tareas en un Bug tracker, php -l, comprobar los errores de conding standard,
etc.)
• Uso de “externals”
23. ISSUE TRACKER
• Necesitáis un sitio donde gestionar el avance de los proyectos y tener visibilidad del qué,
quién y cuándo.
• Opciones
• JIRA (Atención con la versión “starter” - 60 $ - Todos los productos hasta 10 usuarios)
• Redmine, Mantis, Trac, Bugzilla, etc.
• Trucos
• Buscar soluciones que se integren fácilmente con otros elementos del sistema (Tracker
+ SVN, Tracker + IDE, etc.)
• Buscar plugins que faciliten el Code Review siempre que sea posible.
25. WIKI
• Todas las políticas de Coding Standard, Inline Documentation, Especificaciones, aspectos
de arquitectura, cómo pedir las vacaciones, etc.
• Opciones:
• Confluence (hermana de JIRA)
• Twiki, Mediawiki, etc.
• Trucos
• Cread apartados diferentes y asignadles responsable (es una miniresponsabilidad
asumible)
• Flexibilidad con los permisos (de menos a más)
27. METHODOLOGY
• “Es mejor una metodología de desarrollo mala que no tener metodología”
• Clasificación
• Pesadas: Waterfall, UP, etc.
• Ágiles: Scrum, XP, etc.
• La tendencia del mercado es utilizar Scrum y los resultados presentan incrementos de
productividad entre el 200% y 300%. Algunos ejemplos: Softonic, Emagister, Infojobs, etc.
• Cómo empezar:
• http://www.scrumalliance.org/pages/scrum_student_resources
• “Scrum and XP from the trenches”
29. PHP FRAMEWORKS
• Agrupan algunos principios fundamentales: DRY, DRW, KISS, etc.
• Ventajas: Desarrollador más competitivo, facilidad de contratación, mejora
del tiempo de adaptación, reducción de mantinimiento, etc.
• Opciones: Zend Framework, Symfony, CodeIgniter, CakePHP, etc.
• Trucos
• Usadlos ya! Empezad con nuevos proyectos.
• Migrar componentes sueltos (Base de datos, templates, controladores,
mails, etc.)
37. UNIT TEST
• Una tarea no está acabada sino tiene los unit tests escritos, en verde y con una cobertura
de > 80%
• Mantras: “Red, Green, Red, Green”, “Test, Code, Test, Refactor, Test”
• Coupling / Decoupling
• Herramientas
• phpUnit + (Db: commit/rollback | fixtures | DbUnit)
• Recomendaciones:
• Integrar los unit tests con el servidor de integración continua (*)
• La ejecución ha de durar del order de segundos
39. AUTOMATED TESTS
• Selenium RC + Selenium Grid (http://seleniumhq.org/projects/)
• Dentro del Control de Versiones
• Utilizar el package “Selenium” que hay dentro de phpUnit.
• Vais a necesitar hierro! (Virtualización!)
• Recomendaciones:
• Integrar los tests funcionales con el servidor de integración continua (que los
ejecute por la noche)
• Empezad por la funcionalidades críticas de vuestro negocio
41. CONTINUOUS INTEGRATION
• Opciones:
• Jenkins (antes conocido como Hudson)
• Cruise Control + phpUnderControl
• Xinc
• Recomendaciones
• Respetar el tempo de los jobs (unit tests = segundos, métricas = minutos, etc.)
• Mantener los builds estables lo máximo posible (si el build se rompre, la
prioridad es arreglarlo)
43. METRICS
• Algunas métricas fáciles de generar y disponer:
• phpmd (Mess detection)
• phpcpd (Copy detection)
• pdepend (Dependencia entre paquetes)
• phpcs (Coding Standards)
• Recomendaciones
• Integrarlo con la herramienta de integración continua y evaluarlo
semanalmente para poder tomar acciones al respecto.
47. DEPLOYMENT
• Características de un buen deployment
• Puedo eligir que versión y en qué servidor
• Automático (100%) - Código, CDN, BBDD, etc.
• Menos de 15 min. aprox. para aplicaciones grandes
• Recomendaciones
• Generaos un script de deployment
• Automatizarlo usando “ant” o “phing”
• Capistrano (https://github.com/capistrano)
49. DEPLOYMENT
• Asegurar que los entornos son lo más parecidos (también dentro del mismo nivel)
• php.ini, extensiones, apaches, usuarios, versiones, etc.
• Combinaciones
• Desarrollo, Test, Producción
• Desarrollo, Test, Acceptance, Producción
• Desarrollo, Test, Acceptance, Producción, Debug
• Recomendaciones
• Virtualización (VMWare Workstation)
• Puppet (https://github.com/puppetlabs/puppet)
51. DEPLOYMENT
• Utilizad el E_STRICT siempre que sea posible (¿nivel de
sufrimiento?)
• No os compliquéis la vida: Syslog
• Logad en asíncrono con time out cortos
• Recomendaciones
• Syslog
• Splunk
53. SEARCH
• ¿Necesitaréis FULL-TEXT searches?
• Soluciones nativas PHP son de bajo rendimiento
• Sphinx
• cliente propio dentro de la documentación
• Solr
• php-solr
• Solarium
55. EQUIPO
• Formación interna semanal
• “Exigir” certificaciones
• Delegar y hacer que asuman responsabilidades por igual
• Positive thinking (ayudar a los demás)
57. CONCLUYENDO
• Estandarización significa que todo sea más sencillo (sobretodo
en el largo plazo)
• Innovación significa “momentum”
• Cumplir los basics
• Crecer como empresa, equipo y profesional
59. MUCHÍSIMAS GRACIAS
“AL RICO” PHP
Cositas que deberíais saber y que probablamente
ya sabéis y que en caso contrario deberías saber, porque
sino lo sabéis, vais a sufrir...
Carlos Buenosvinos (@buenosvinos)
carlos@quepimquepam.com
Castellón, Universitat Jaume I (decharlas.com)
16 de Mayo de 2010
18:00 - 20:00