• Save
Guía de buenas prácticas para desarrolladores web
Upcoming SlideShare
Loading in...5
×
 

Guía de buenas prácticas para desarrolladores web

on

  • 7,510 views

Guía de buenas Prácticas para desarrolladores PHP

Guía de buenas Prácticas para desarrolladores PHP

Statistics

Views

Total Views
7,510
Views on SlideShare
7,277
Embed Views
233

Actions

Likes
8
Downloads
0
Comments
0

2 Embeds 233

http://blog.juanminaya.com 140
http://www.juanminaya.com 93

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Guía de buenas prácticas para desarrolladores web Guía de buenas prácticas para desarrolladores web Presentation Transcript

  • Guía de Buenas Prácticas para Desarrolladores PHP
    Juan Minaya leónminayaleon@gmail.com
  • Agenda
    Programación
    IDE
    Base de Datos
    Código Estándar
    Documentación
    Herramientas y Procesos
    Colaboración
    Control de Código
  • IDE (Integrated development environment)
    NetBeans ¿Por que?
    Soporte HTML, JavaScript y CSS
    Autoformato de Código
    Refactoring
    Autocompletado
    Generador de Código
    Cliente SQL (SQL Server, MySQL, Oracle, etc.)
    Resaltado de código (PHP, JS,CSS,HTML,SQL, etc.)
    Clientes: FTP, SVN, etc.
    Plugins: phpDocumentor, Zend Framework, Symfony, Smarty, phpUnit, phpDebug, etc.
  • IDE (Integrated development environment)
    MySQL Workbench
    Generación de Diccionario de Datos
    Ingeniería Inversa , Sincronización
    Generación de Formal Normales (1FN, 2FN, 3FN)
  • Diseño de Base de Datos
    • ¿Usar Mayúsculas, Minúsculas ó ambas?
    • ¿Cuál se ve mejor?
    CLIENTE, cliente, Cliente, ClienteCuenta, cliente_cuenta, CLIENTE_CUENTA
    • ¿Qué nos dicen nuestros Proveedores?
    Mysql Server, SQL Server, Oracle
  • Diseño de Base de Datos
    Mysql Server
    Distingue entre mayúsculas y minúsculas sólo los nombres de la base de datos y tablas, más no de sus columnas.
    Variable de configuración lower_case_table_names, valor:
    0 -> Las tablas se almacenan con la sensibilidad especificada en la sentencia de creación (Linux). SELECT * FROM cliente; SELECT * FROM CLIENTE; (ERROR)
    1 -> Las tablas se almacenan convirtiendo sus nombres a minúsculas (Windows y Mac). SELECT * FROM cliente; SELECT * FROM CLIENTE; (OK)
    2 -> Los tablas se almacenan con la sensibilidad especificada en la sentencia de creación. SELECT * FROM cliente; SELECT * FROM CLIENTE; (OK)
  • Diseño de Base de Datos
    Mysql Server
    Cita 1: Crear y referirse a bases de datos y tablas usando siempre minúsculas. Esto es lo recomendado para lograr máxima portabilidad y facilidad de uso. Fuente: Documentación Mysql.
    Cita 2: Si se utilizan tablas InnoDB, se debería establecer lower_case_table_names en 1 en todas las plataformas para forzar a que los nombres sean convertidos a minúsculas. Fuente: Documentación Mysql.
  • Diseño de Base de Datos
    • ¿Usar Plural, Singular ó ambas?
    Todo parte del concepto de entidad (cliente, cuenta, factura, producto, etc.)
    Modelo ER pretende representar la “realidad”, nombrar las tablas en plural sería la mejor opción, pero….
    En la implementación usas muchos identificadores: botones, formularios, grillas, etc. Todos referidos a una entidad (btnCliente, frmCliente) no colocas (btnClientes, frmClientes, chkClientes).
    Si tuviésemos que representar (cuentas de un cliente) al estilo plural tendríamos estas opciones: cuentas_clientes ó cuentas_cliente, si usaríamos el estilo singular sólo habría una opción: cuenta_cliente.
    En otras palabras es una cuestión de costo/beneficio
  • Diseño de Base de Datos
    ¿Se debe usar prefijos?
    ISO/IEC 11179 (normalización de metadata y metada registry )
    No recomienda el uso de Prefijos ni Sufijos, salvo en los casos que en una sola base de datos se compartan muchos proyectos
    Ejemplos de buenas practicas: Cliente_Cuentas, Cliente_Cuenta
    SQL Server y Oracle han adoptado este estándar
    MySQL recomienda usar minúsculas
  • CONSEJO A
    En MySQL nombra las base de datos y tablas con minúsculas usando el estilo singular, para el caso de nombres compuestos usar underscore ( _ ), para SQL Server y Oracle sigue el estándar ISO/IEC 11179
  • PHP Código Estándar
    Seguir la Guía de Estilos Zend (DRAFT)
    General
    Para archivos que sólo contengan código PHP la etiqueta de cierre ( “?>” ) debe ser omitida.
    Indentation
    Usar como indent (sangría) 4 espacios.
    La longitud máxima de cualquier línea de código PHP es de 120 caracteres.
  • PHP Código Estándar
    Convención de Nombres
    Se seguirá la guía de estilos desarrollada por Zend para su proyecto opensource ZF.
    Clases
    El nombres de las clases relaciona directamente con los directorios donde se almacenan. Db/Mysql/Adapter.php -> Db_Mysql_Adapter
    Sólo permitido caracteres alfanuméricos y el underscore (sólo reemplaza el separador de ruta)
    El uso de números no está recomendado.
  • PHP Código Estándar
    Interfaces
    Debes seguir la misma convención para las clases, pero deberán terminar en _Interface, ejemplos:
    Application_Db_Interface, Zend_Log_Interface, etc.
    Funciones y Métodos
    Sólo permitido caracteres alfanuméricos, underscore no está permitido. El uso de números no está recomendado.
    Deben empezar siempre con letra minúsculas. Si contiene más de una palabra, la 1ra letra de cada palabra debe empezar con mayúculas (CamelCase).
    Ejemplos: obtenerDatos, registrarUsuario, etc.
  • PHP Código Estándar
    Variables
    Sólo permitido caracteres alfanuméricos, underscore no está permitido. El uso de números no está recomendado.
    Como las funciones debe empezar con letra minúscula y usar la convención CamelCase.
    Para variables que son declaradas como privadas o protegidas se debe agregar underscore al inicio. Ejemplo: $_tipos, $_nClientes, etc.
    Las variables deben describir los datos que van a almacenar, usar $i, $n, $j sólo en bucles.
  • PHP Código Estándar
    Constates
    Deben ir en letras mayúsculas.
    Sólo permitido caracteres alfanuméricos y carácter underscore para separar palabras que conforman la constante.
    Para las constates definidas como miembros de una clase se usará el modificador “const”, para constantes globales se usará “define”.
  • PHP Guía de Estilos
    Shorttags ( “<?” )no están permitidos.
    Strings
    Para cadenas se usará comilla simple.
    Para cadenas que contengas apostrofes o variables de sustitución se usará comilla doble
    Para concatenar cadenas use el operador “.”
  • PHP Guía de Estilos
    Clases, Métodos y Funciones
    Deben ser nombradas de acuerdo a la convención de nombre de Zend.
    La llave de inicio deben ser escrita una línea debajo del nombre de la clase, métodos ó función.
    Deben tener un bloque de documentación que se ajusta al estándar de phpDocumentor.
    Sólo se permite una sola clase en cada archivo PHP.
    Los métodos deben ser declarados especificando su visibilidad (private, protected, o public)
  • PHP Guía de Estilos
  • CONSEJO b
    Zend es la empresa oficial detrás de PHP, la guía de buenas prácticas desarrollada por esta empresa es de lectura obligatoria par5a todo programador
  • Documentar tu Código
    Programa pensando que la persona que mantendrá tu código es un psicópata maniaco que sabe donde vives … que si te encuentra te meterá terror!!!.
  • Documentar tu Código
    phpDocumentor
    Herramienta estándar para documentar código PHP.
    Crea documentos HTML, PDF, CHM.
    Se puede usar desde la consola de comandos ó integrarlo a un IDE (NetBeans Zend Studio ó Eclipse)
    Recomiendo documentar las funciones, clases y métodos que forman pate del dominio de la aplicación (capa de negocio).
  • Documentar tu Código
    Clases
    Deben tener una pequeña descripción sobre el uso de la clases
    Las variables definidas deben tener usar el tag @var
    Métodos
    Los parámetros de las funciones deben usar el tag @param
    Si tienen variables de retorno se debe usar el tag @return
    Si existen bucles condicionales se deberá detallar el funcionamiento básico del mismo usando comillas dobles (“//”)
  • Documentar tu Código
  • Documentar tu Código
  • Documentar tu Código
  • ¿PREGUNTAS FINALES?
    ¿Dudas?
  • Bibliografía
    Zend Best Practices
    ISO/IEC 11179
    SQL Server Best Practices
    Java Best Practice
    PHP Architect