Post on 10-Mar-2016
description
Comentarios acerca de la calidad de software Estimado Nerón,
En el tiempo que llevo trabajando he visto ya tres sistemas: Mall Advertising, Max Center,
Grupo BGD. Todos estos sistemas tienen el mismo estilo de programación, pero tengo entendido
que no los ha realizado la misma persona por lo que asumo que es una especie de normativa o
estandarización en la empresa.
En los años que tengo de experiencia siempre ha sido una constante realizar mi trabajo lo
más profesional posible, siempre he preferido demorarme un poco más a entregar un trabajo mal
hecho, medianamente bueno o susceptible de errores. Ha sido esa característica la que me ha
dado cierta reputación, reputación que pretendo mantener y esta es la principal motivación que
me lleva a escribir este documento.
Antes de continuar quisiera que este documento se entienda como una crítica constructiva
que busca mejorar la calidad de los trabajos de la empresa, ya que es de mi entender que la
calidad del trabajo que se entrega es el prestigio que la empresa debe asegurar a sus clientes y es
lo que hace que todos ganemos.
La crítica que hago lo hago desde el punto de vista de una auditoría de software. Por favor
leer este documento como si un consultor de Control de Calidad estuviera dando un informe de la
calidad del trabajo de esos tres sistemas. El resumen de lo que encontré es:
Los tres sistemas revisados tienen la misma característica y es que cada uno es un sistema
monolítico y salta a la vista que no ha existido un trabajo de diseño de software previo. No
sigue ninguna arquitectura de software que pueda asegurar que sean escalables, al menos
no de forma fácil y segura.
Cada uno de los sistemas tienen el código de la lógica del negocio (en este caso código
php) mezclado de forma desordenada, o al menos no de forma clara o definida, con el
código de la presentación (código html, css, javascript).
El flujo del código no presenta un orden, siquiera procedural, que pueda asegurar que el
sistema pueda ser rápidamente adaptable a los cambios en la lógica que el negocio pueda
requerir.
En ninguna parte del código se ve reflejado una estandarización en los estilos de
programación, por ejemplo: no existe una clara definición de formación de nombres para
las variables, no existe una forma estándar de ejecutar las consultas y mucho menos existe
una correcta identación en el código que permita leer con facilidad el código allí
expresado.
No existe documentación de ninguna índole, ni dentro del código siquiera.
La base de datos no está correctamente normalizada, teniendo datos (tales como la
dirección o proveedores) mal normalizados. No se ha definido un conjunto de caracteres
estándar (he visto usar sueco, binario, general). Tampoco se utilizan motores de
almacenamiento que proporcionen transacciones lo que hace peligrar los datos para
sistemas e‐commerce.
No existen mecanismos claros de filtro de los Request HTTP, y se utilizan directamente las
variables siendo esto un grave hueco de seguridad al ser posible inyectar código en los
request, comúnmente conocidos como ataques XSS.
Las características anteriormente descritas hacen que cualquier cambio que exija el cliente sea
un paso algo tortuoso, mucho más para alguien que no conoce el sistema ya que debe hacer el
trabajo de un hacker para poder ir desenmarañando el código, ir descubriendo su lógica y
sobretodo lidiar con las prácticas de programación que en el caso de los sistemas analizados es
más bien un obstáculo.
Por otra parte hay que considerar que realizar un cambio en el código en estas circunstancias
puede ser inclusive contraproducente debido al desorden y es muy probable que al añadir una
característica o cambio también se incluya un bug en el sistema.
Hay que deducir que esto implica que se demore más tiempo del necesario para realizar algo
nuevo en el sistema, en una empresa en la que exista un control de calidad del software estos
cambios serían mucho más fáciles, rápidos, seguros y confiables haciéndolas más competitivas.
¿Por qué esta crítica?
Definir una arquitectura de software para realizar un sistema, sentarse a establecer un diseño,
permitiría que se realice un software de calidad; una empresa que piense tan sólo en “sin
embargo funciona y eso es suficiente” hace que sea una empresa que se condena a sí misma al
fracaso puesto que no podrá eventualmente afrontar los cambios con la velocidad que exige el
mercado, y el mercado de software es un mercado muy exigente y sobretodo que sufre de
amnesia muy rápidamente.
Una arquitectura de software consiste en un conjunto de patrones y abstracciones coherentes
que proporcionan el marco de referencia necesario para guiar la construcción del software para un
sistema de información. Establece los fundamentos para que analistas, diseñadores y
programadores trabajen en una línea común que permita alcanzar los objetivos del sistema de
información.
Me han dicho en más de una vez: “lo de GSM Manía es fácil, es copiar y pegar lo hecho para
Max Center”, bueno, eso no es enteramente cierto. En un sistema monolítico como el que está
realizado para Max Center, donde las consultas están mezcladas de forma desordenada con el
código html es más bien realizar la tarea de un cirujano el adaptar ese código. Por otro lado, eso
significa que se están copiando los mismos errores, malas prácticas de programación, los mismos
vicios en el otro sistema, entregándole al cliente el mismo mal trabajo, aunque “funciona”, de la
misma forma como funcionó Frankenstein para su creador.
Para graficar esto puedo presentar esta parte del código que presenta el detalle de un pedido:
En parte del archivo detallepedido.php podemos ver que se mezcla el código HTML con código
PHP para realizar el detalle, e inclusive en el mismo código PHP se vuelca código HTML haciéndolo
más complicado aún. Realizar una pequeña modificación aquí requiere el trabajo de un cirujano y
no es una simple cosa de “pegar y copiar” sólo “porque funciona”.
Una razón personal por la que efectúo esta crítica es por el hecho que yo no soy un simple
programador, soy ingeniero, aunque me gusta mucho la programación; pero, soy más que un
programador. Un programador hace lo que se le pide sin más puesto que ese es su trabajo, y
ciertamente yo también puedo hacer eso mismo (como lo he venido haciendo); pero, mi búsqueda
de la profesionalización de mi trabajo me exige que no me contente con realizar un trabajo poco
profesionalizado, lo que a la larga me lleva a ensuciarme con malas prácticas y vicios en mi forma
de trabajo, que mucho esfuerzo y sacrificio (personal y de mis padres) me ha costado llevarlo al
nivel en el que está y que se me ha reconocido en diversas oportunidades. Ni siquiera en mi
primer proyecto web, en Enero del 2001 que hice el sistema de inscripción, gestión operativa y
pago en línea para un congreso de sistemas de mi universidad, realicé un trabajo sin considerar
muy bien la ingeniería y calidad de software, cosa que no encontré en los trabajos que he
revisado. Para mi estos trabajos no son profesionales y a casi más de 8 años de experiencia en la
rama no estoy dispuesto a rebajar mi trabajo a algo así.
HTML
PHP
HTML
Es justamente en virtud de esta profesionalización que no sólo me quedo en criticar sino
también en plantear soluciones, tal como siempre me decía un profesor, amigo íntimo y mentor:
“Un ingeniero no sólo describe los problemas, da soluciones”.
Planteamiento
Lo que planteo para este sistema de GSM Manía, es iniciarlo usando un modelo de
Arquitectura de Tres Capas aunque reutilizando el código SQL y el DDL ya utilizados en el sistema
de Max Center. Primero quisiera explicar de manera rápida el modelo de Arquitectura de Tres
Capas para que se me entienda.
Arquitectura de Tres Capas
Según wikipedia1: Es una especialización de la arquitectura Cliente – Servidor donde la
carga se divide en tres partes o capas con un reparto claro de funciones:
1. Capa de presentación: Es lo que ve el usuario, presenta el sistema al usuario, le comunica
la información y captura la información en un mínimo de proceso (realiza un filtrado
previo para comprobar que no hay errores de formato). Esta capa se comunica
únicamente con la capa de negocio. También es conocida como interfaz grafica y debe
tener la característica de ser "amigable" (entendible y fácil de usar) para el usuario.
2. Capa de negocio: Es donde residen los programas que se ejecutan, se reciben las
peticiones del usuario y se envían las respuestas tras el proceso. Se denomina capa de
negocio (e incluso de lógica del negocio) porque es aquí donde se establecen todas las
reglas que deben cumplirse. Esta capa se comunica con la capa de presentación, para
recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al
gestor de base de datos para almacenar o recuperar datos de él. También se consideran
aquí los programas de aplicación.
3. Capa de datos: Es donde residen los datos y es la encargada de acceder a los mismos. Está
formada por uno o más gestores de bases de datos que realizan todo el almacenamiento
de datos, reciben solicitudes de almacenamiento o recuperación de información desde la
capa de negocio. Por lo general implementada como una base de datos dentro de un
Sistema de Administración de Bases de Datos Relacionales. Contiene, además de los datos
en sí, código escrito en procedimientos almacenados, disparadores (triggers), reglas y
funciones.
Las principales ventajas de este modelo son las siguientes:
1 http://es.wikipedia.org/wiki/Arquitectura_de_tres_niveles
1. Separación de funciones: todo lo relacionado con la interfaz del usuario va en una capa,
las reglas de negocio en otra y el manejo de datos en una tercera capa. No se mezcla en
una capa código correspondiente a otra.
2. Reutilización: el código correspondiente a una capa puede ser reutilizado desde varias
partes de la capa inmediatamente superior.
3. Escalabilidad: sabiendo dónde está el código correspondiente a cada capa, pueden
realizarse modificaciones dentro de una capa para mejorar o aumentar el tamaño del
sistema de software, con un mínimo impacto en las capas restantes.
4. Facilidad de mantenimiento: mediante esta división, es mucho más sencillo localizar
errores en el código o efectuar mejoras.
Para los sistemas web existen frameworks ya creados, mucho más para php y java, que permiten
implementar el modelo de tres capas con mucha facilidad. Los frameworks más utilizados en PHP
son: Smarty2 para la capa de presentación y ADODB3 para la capa de datos.
El uso de Smarty yo lo considero indispensable en los sistemas web que he revisado y también
para el sistema de GSM Manía. El uso de ADODB se hace útil si el sistema a desarrollar es
susceptible de tener cambios en el motor de base de datos, si se tiene la seguridad que nunca
cambiará el uso de MySQL se puede restringir su utilización, aunque tampoco está demás ni le da
complejidad al desarrollo, por el contrario es muy aconsejable su uso (uno nunca sabe qué puede
deparar el futuro y es mejor estar preparado ante él y los cambios que pueden exigir).
Smarty es un framework motor de templates, que permite separar la capa lógica de la
presentación, dado que en la capa de presentación se le declaran variables que son reemplazadas
en los templates y así el mismo template puede entregarse a cualquier diagramador o diseñador
para que lo modifique a su gusto sin impacto en la capa lógica.
ADODB es un framework que permite la abstracción del motor de base de datos, proporciona una
API única para el trabajo con las conexiones y consultas, de tal forma que un cambio futuro de
DBMS no requiere más que el cambio de una sola línea de código en un sistema realizado con este
paquete.
La capa de la lógica del negocio es la capa a ser diseñada ad‐hoc para cada sistema. Si se tuviese el
tiempo suficiente se podría pensar en crear un framework propio para la generación de sistemas
de e‐commerce lo que facilitaría su reutilización en otros sistemas futuros de la misma rama (algo
que me parece es muy recurrente en el giro del negocio de “Meiler Interactive Creations”), por lo
que es altamente recomendable.
2 Smarty: http://www.smarty.net 3 ADODB: http://adodb.sourceforge.net
Así la primera aproximación del sistema para GSM Manía podría ser la siguiente:
Capa de Lógica del N
egocio
Lógica de GS
M M
ania
AD
OD
BA
CL
Capa de Base de Datos
Servidor MyS
QL
DD
LTriggersV
iewsFunctions
Capa P
resentación
PresentaciónH
TML
CSS
JavascriptX
mlHttpR
equestFlash
Sm
arty
Capa de Lógica del Negocio
Según requerimientos expresados a mi por Danny Herrán, la interfaz del sitio de GSM Manía debe
generarse “de cero” dado que hay que hacer el diseño completamente usando CSS para que así
pueda ajustarse a cualquier plataforma móvil. Yo veo aquí una oportunidad estupenda para poder
realizar un cambio en las directrices del trabajo y realizar uno bien planteado, correctamente
definido y documentado, un trabajo realmente de calidad.
He hecho el trabajo de hacker con el sistema de Max Center y le logrado deducir el siguiente
diagrama de clases (capa de lógica del negocio):
Pedido
- pedi_id : Integer- cliente : Cliente- direccion : Direccion
Cliente
- clie_id : Integer- clie_nom
bre_razon : String- clie_rif_ci : Integer- direccion : Direccion
Pago
- pago_id : Integer- pedido : Pedido- banco : Banco- form
a_pago : Integer- status : Integer
CategoriaProducto
- cat_orden : Integer- cat_nom
bre : String- cat_id : Integer- cat_nivel : Integer- cat_padre_id : Integer
Direccion
- entidad_id : Integer- tipo_entidad_id : Integer- dire_id : Integer- dire_pais : Integer- dire_estado : Integer- dire_ciudad : String- dire_avenida : String- dire_urbanizacion : String- dire_casa_apt : String- dire_codigo_postal : String
Proveedor
- prov_id : Integer
interfaceIEntidad
+GetCodigoEntidad
+GetTipoEntidad
PedidoDetalle
- pedd_id : Integer- pedi_id : Integer- producto : Producto- pedd_cantidad : Integer- pedd_precio : float- pedd_iva : Integer- pedd_subtotal : float
Opi
- opin_public- opin_rankin- cliente : Clie- producto : P- opin_id : Int- opin_fecha - opin_texto
Banco
- banc_beneficiario : String- banc_nom
bre : String- banc_id : Integer- banc_num
erocuenta : String- banc_rif : String
No me queda claro que
relación tiene con Costo, Zona o qué son estos conceptos
Variables
Tienda
- tien_imagen : String
- tien_nombre : S
tring- tien_id : Integer
Marca
- marc_nom
bre : String
- marc_id : Integer
- marc_publica : Integer
- marc_logo : S
tring
Variable
- var_id : Integer- nom
bre : String
- valor : Integer- fecha_registro : D
ate- ultim
a_modificacion : Date
- modificable : Integer
Producto
- prod_imagen : S
tring- prod_publica : Integer- prod_nom
bre : String- prod_ranking : float- prod_id : Integer- m
arca : Marca
- categoria : CategoriaProducto
interfaceIPublicable
+EsPublica
pinion
ca : Integerng : floatienteP
roductontegera : D
ate: S
tring
interfaceIVisualizable
+GetIm
agen
Banner
- bann_publica : Integer- bann_im
agen : String
- bann_id : Integer
interfaceINombrable
+GetNom
bre
En el diagrama de clases presentado anteriormente se han omitido unas clases que tienen su
correspondiente a cada clase presentada en el diagrama y que tienen como función realizar la
conexión y consultas con la base de datos sobre la lógica de la clase que representa, así por
ejemplo: para la clase Producto debe existir una clase BdProducto que se conecta a la base de
datos y debe encargarse de la persistencia de los datos de Producto así como de su lectura del
motor de base de datos. Estas clases de conexión con la base de datos deberían utilizar el
framework ADODB antes mencionado.
Lógicamente es un modelo que debería afinarse dado que yo no he tenido acceso a ninguna
documentación del sistema, y sospecho que no existe tal documentación.
Capa de Presentación
Para la capa de presentación propongo el siguiente diagrama de clases:
La clase página se encarga de manejar los flujos Http y comunicarse con la capa de lógica del
negocio. Utiliza el motor de templates Smarty para la generación de las interfaces gráficas.
Capa de Datos
Para la capa de datos podríamos reutilizar el 80% del DDL ya existente para Max Center, allí yo
tengo consultas acerca de, por ejemplo, el porqué no se normalizó la dirección entre entidades
tales como cliente, pedido y proveedor. Además tampoco está normalizado el tipo de pago,
teniendo una tabla extra que no da ganancia en el sistema. Tampoco está normalizada la forma de
pago, ni los estados ni las ciudades. Falta hacer una normalización de varios datos los cuales están
hard‐coding y eso es una práctica que hace que el sistema no sea escalable o lo dificulta.
Conclusiones
El presente informe ha presentado el resultado de un análisis de la calidad del software de tres
sistemas a los que he tenido acceso, no es un análisis hecho a la profundidad que merece y tan
solo presento un resumen de lo encontrado.
smarty
Pagina
Los sistemas evaluados son sistemas que carecen de una arquitectura definida o de un diseño de
software que permita que ellos sean flexibles, coherentes y de fácil mantenimiento en el tiempo.
Son sistemas monolíticos con código desordenado y mezclado entre interfaz, conexiones y lógica.
Se hace ver la necesidad de corregir esta forma de trabajo mediante la utilización de una
arquitectura de tres capas, que por lo demás es la arquitectura más utilizada para los sistemas
web. Al utilizar esta arquitectura se asegura un buen código, un sistema flexible, escalable que
permite la reutilización y hace entrega de un trabajo de calidad al cliente.
Se han planteado los diagramas de clases base producto de un hackeo del sistema de Max Center
para guiar en la migración de paradigma de trabajo, los diagramas requieren un afinamiento con
las personas que conocen a la perfección la lógica del sistema dado que se han generado después
de deducir el sistema debido a la nula documentación del mismo.
El espíritu de este informe es intentar mejorar la forma de trabajo de la empresa, se han
expresado duras críticas pero ninguna se ha realizado sin sustento en la realidad. Creo que está
demás aclarar que este informe no tiene carácter personal ni busca menoscabar a nadie en
especial, yo soy nuevo en la empresa y simplemente he intentado dar mi punto de vista
profesional que es para lo que, eventualmente y si no hay ningún cambio, se me paga. En última
instancia he emitido este informe en la búsqueda de salvaguardar la reputación y profesionalismo
de mi trabajo que ha adquirido con el tiempo buenas prácticas y he intentado siempre de subir mi
nivel, y no pretendo disminuirlo.
Tiempos Contestando a la pregunta que en final de cuentas importa (aparentemente lo único que importa)
es mi deber plantear dos plazos:
‐ Si se toma en cuenta el modelo propuesto podría dar la siguiente aproximación:
o Capa Presentación: 1 semana.
o Capa Lógica: 1 semana y 3 días.
‐ Si se obvia lo propuesto y se continúa con un sistema monolítico podría dar la siguiente
aproximación:
o 2 semanas y algunos días
Los tiempos están definidos pensando en un trabajo a tiempo completo, con toda la información
clara y oportunamente definida (cosa que no existe en el primer caso).
Grover Campos Ancajima
Ingeniero de Sistemas