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

3. REQUISITOS Y CALENTAMIENTO
Brazos, Piernas y Vergüenza

4. PREGUNTILLAS
¡Se admiten en cualquier momento!

5. NIVEL DE SUFRIMIENTO
¿Cuál es vuestro nivel de tolerancia al dolor?

6. BROKEN WINDOW PARADIGM
Claaaro, como ya está rota...

7. TECHNICAL DEBT
¡Atención a los intereses!

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

9. CONSEJILLOS DE LA ABUELA
Remedios, infusiones y cataplasmas

10. TAGS DE LA CHARLA
• IDE, Coding Standards, Inline Documentation, Control de
Versiones, Issue Tracker, Wiki, Metodología, Frameworks,
Seguridad, Debugging, Performance, Entornos, Deployment,
Search and Indexing (Solr), Logging

11. ¿POR QUÉ?
...

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)

14. IDE
Escribiendo código...

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.

16. CODING STANDARD
Vamos a ver si nos aclaramos todos :)

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

18. INLINE DOCUMENTATION
Documentar es un rollo!

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!

20. CONTROL VERSION SYSTEM
¿Qué ha pasado? ¿La has liado parda?

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”

22. ISSUE TRACKER
Quién hizo qué, cuándo y dónde

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.

24. WIKI
¿Cómo se hace...?

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)

26. METHODOLOGY
Uno para todos y todos para uno

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”

28. PHP FRAMEWORKS
Había una vez, un circo...

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

30. LIBRARIES & COMPONENTS
Que ya existe, que sí, que te lo digo yo...

31. LIBRARIES & COMPONENTS
• Don’t reinvent the wheel
• Not invented here syndrome
• Extender y participar, no modificar
• Típicos: ORM (Doctrine, Propel), Templates (Smarty, Twig)
• Recomendaciones
• PEAR
• PHP Extensiones
• Github (http://github.com)

32. SECURITY
Ohmmm...

33. SECURITY
• Mantra: “Filter your input, scape your output” + Filter extension enabled
• Problemas típicos (80/20):
• SQL Injection (prepared statements)
• XSS (escapar la salida)
• Recomendaciones:
• “Essential PHP Security” (Chris Shiflett)
• “Guide to PHP Security” (Ilia Alshanetsky)

34. DEBUGGING & PROFILING
Paso a paso...

35. DEBUGGING
• Sobre Alt-tab debugging, Echo-debugging
• Recomendaciones:
• Xdebug (http://www.xdebug.org)
• Zend Debugger
• Profiling:
• Xdebug + Visualizador: (KCacheGrind, Webgrind, Xdebugtoolkit)

36. UNIT TESTS
Que te digo yo que funciona...

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

38. AUTOMATED TESTS
Está vivo! Está viiiiiiivooooo!!

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

40. CONTINUOUS INTEGRATION
5 minutos de ejercicio al día!

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)

42. METRICS
En ocasiones... veo...

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.

44. PERFORMANCE
Que se las pela!

45. PERFORMANCE
• Cache
• APC + Memcached (Output y Datos)
• Background Processing (Colas)
• Gearman, ActiveMQ, etc.
• Sharding
• Entornos de alta escritura (redes sociales)
• Client Side: CDN + YSlow and PageSpeed Suggestion

46. DEPLOYMENT
Vamos que nos vamos...

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)

48. ENVIRONMENTS
¿Dónde estoy?

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)

50. LOGGING
¿Qué ha pasao’?

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

52. SEARCH
¿Dónde está Wally?

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

54. EQUIPO
El motor que mueve todas las cosas

55. EQUIPO
• Formación interna semanal
• “Exigir” certificaciones
• Delegar y hacer que asuman responsabilidades por igual
• Positive thinking (ayudar a los demás)

56. CONCLUSIONES
Y para acabar...

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

58. PREGUNTILLAS
Ánimo!

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