Todo empezó con un reciente post del blog VivaPHP, en el cual copian el anuncio de la nueva versión de este proyecto de framework latinoamericano llamado "Kumbia".
Luego de analizarlo, quedo un poco perplejo por tanta cantidad de márketing, y dado que alguna que otra vez hemos intercambiado comentarios con otros colegas en Foros de Web sobre errores conceptuales importantes a la hora de programar Orientado a Objetos, es que me tomo el atrevimiento de hacer la siguiente revisión rápida de esta última versión y encuentro que desde el código se puede ver que:
- Existen muchas clases con atributos públicos: por ejemplo acl/role/exception.php, kumbia.php, etc. Esta práctica es desaconsejable desde los inicios de la POO, por lo cual no hay excusa que valga (y hace un par de años fue un punto muy criticado cuando se nos pidió opinión a GatorV y a mi).
- Existen clases en PHP4 y funciones estructuradas: muchas ubicadas en "library", por lo cual rompe el diseño del framework.
- Existen métodos muy extensos: por nombrar algunos, "main" de kumbia.php, "generate" de report.php, lo que significa que los métodos implementan más de una funcionalidad, lo cual deberían partirse en más métodos o clases.
- Existen clases con html mezcladas con logica de negocio por lo que no beneficia en absoluto la separación de capas.
- No utiliza para los objetos la nomenclatura estándar "camelcase", algo muy usado en casi cualquier lenguaje POO (Java, PHP5 + Zend Framework, .Net, etc): por ejemplo kumbia::javascript_base() en vez de kumbia::javascriptBase()
- Existe una clase Object vacía que no aporta absolutamente nada, por lo cual se podría considerar la alternativa de usar stdClass de PHP.
- Se usa constantemente <?= cuando se sugiere por manual no usarlo por un tema de portabilidad y compatibilidad, por lo cual debería hacer uso de <?php echo $algo; ?>
- Usa charset iso-8859-1 y debería hacer uso de utf-8, estándar definido hace mucho tiempo.
- Nombre de archivos de clases inician en minúsculas y no en mayúsculas: directorio "library", por ejemplo acl.php -> Acl.php
En sí, a pesar que muchos detalles no son graves (aunque hay otros que sí y mucho) me da una sensación bastante encontrada al ver tan "buen márketing externo" por un lado y no condecirse con el interior del código fuente.
Tal vez sería mejor bajar un poco el perfil de los anuncios, hasta por lo menos haber corregido estos puntos.
Espero que esta crítica sea tomada en modo constructivo, principalmente por el autor, ya que una vez me preguntó cuando "le regalaba una crítica sobre su framework".
Aquí está.
5 comentarios:
Tu critica me parece excelente.
Yo tengo un proyecto desarrollado en Flash y PHP usando como base AMFPHP.
Si bien aún no esta terminado me gustaria que alguien aporte una critica constructiva sobre él. ¿Tienes tiempo para hacerme ese favor?
Estimado Daniel:
Voy a empezar a ofrecer este servicio en dos modalidades, uno gratuito y otro pago, y luego informo los resultados de la auditoría, opcionalmente de forma pública o privada ;-)
Envíame la forma de acceso a los fuentes y veo de hacer algún comentario... no prometo nada, ya que vas a usar la versión "no paga" ;-)
Hola enrique bueno hay cosas que tomo para mejorar el framework y otras que desde mi modesto punto de vista(mas no malcriades) no vienen al caso o simplemente no pueden ser criticas.
Criticas que Acepto.
1->Clases con Atributos públicos iremos corrigiendo esto paulatinamente.
2->Métodos Extensos...
Critas que NO Acepto
1->Nomenclatura CamelCase solo lo utilizamos para las class, nadie dice q eso se debe utilizar tal y como comentas. Al momento de crearse el framework se decidio tomar para nombres de metodos la notacion small-case
2-> Chasert a pesar que el utf-8 es el mas utilizado no quiere decir que todos se van a regir por ese nuestro framework esta pensado para una comunidad hispana esto quiere decir que existen caracteres especiales por ende el mas idonio para para eso es ISO-8859-1 de paso el framework no te obliga a utilizarlo si el usuario que decide utilizar el framework le gusta mas utf-8 u otro charset lo puede cambiar sin problema...
Pero sin duda que tus criticas caen bien claro con las aclaraciones pertinentes...
Estimado Deivinson Tejeda:
Gracias por tus comentarios, te respondo por puntos:
> Hola enrique bueno hay cosas que
> tomo para mejorar el framework y
> otras que desde mi modesto punto
> de vista(mas no malcriades) no
> vienen al caso o simplemente no
> pueden ser criticas.
Bien, está aclarado en mi post que "me tomo el atrevimiento de hacer la siguiente revisión rápida", pero de todas formas no comparto tu opinión (ahora te lo aclaro).
> Critas que NO Acepto
> 1->Nomenclatura CamelCase solo
> lo utilizamos para las class,
> nadie dice q eso se debe
> utilizar tal y como comentas.
Es un estandar en la mayoría (por no decir todos) los lenguajes POO, muchos desarrolladores siguen usando el estándar viejo porque así inició PHP con la práctica estructurada y todas sus funciones usan esa nomenclatura, pero no se debe seguir cuando se habla de objetos.
Por ejemplo, se sabe que Sun define todos los estándares de Java y a nadie se le ocurre no seguirlos, en nuestro caso están empezando a existir fuertes "sugerencias" de parte de Zend ("nuestra Sun") para seguir el criterio "camelcase", porque justamente, lo usan la mayoría de los lenguajes POO (nuevamente, por no decir todos).
Por consiguiente es de sentido común hacerlo así.
Aquí te dejo un enlace de Zend hacia los estándares de codificación: presentación.
De la misma forma, está en la documentación de Zend, pero esto no tiene nada que ver por el framework, es en sí porque la programación que hacen dentro y fuera es siguiendo prácticas generalizadas de POO.
Lo que ustedes están haciendo es seguir las "malas prácticas" de toda la vida que se han realizado en PHP (y lamentablemente es muy común verlo en nuestro rubro).
> 2-> Chasert a pesar que el utf-8
> es el mas utilizado no quiere
> decir que todos se van a regir
> por ese nuestro framework esta
No es correcto, UTF-8 sustituye a ISO como una evolución hacia un sistema que resuelve los problemas del sistema anterior (justamente, los caracteres especiales).
Leer UTF-8
"Por supuesto, la ventaja más notable de cualquier Formato de Transformación Unicode sobre codificaciones heredadas es que este puede codificar cualquier carácter."
UTF-8 sustituye a ISO. Si usan todo UTF-8, pueden escribir cualquier carácter directamente y funcionará sin tener que hacer nada especial.
La única contra es que PHP5 aún no es compatible con UTF-8 a nivel de funciones, es decir, hay muchas funcines que devolverán ISO, pero para la mayoría de los casos es transparente (o a lo sumo usas funciones de encode y decode).
El 90% del desarrollo de PHP6 es migrar todas las funciones para que sean 100% compatibles con UTF-8.
En resumen a "grueso modo" se puede decir que "ISO casi desaparece a partir de PHP6".
Otro artículo de este blog sobre el tema
> pensado para una comunidad
> hispana esto quiere decir que
> existen caracteres especiales
> por ende el mas idonio para para
> eso es ISO-8859-1 de paso el
Falso, existe UTF-8 para cada uno de los idiomas existentes. Si te fijas, cuando creas una base de datos también te preguntará y le puedes decir "utf8_spanish"
> framework no te obliga a
> utilizarlo si el usuario que
> decide utilizar el framework le
> gusta mas utf-8 u otro charset
> lo puede cambiar sin problema...
La idea es que cuando se use un determinado tipo de charset, se use en todas las capas de forma uniforme, de lo contrario puedes tener problemas de "roturas" de caracteres.
Se debe grabar en utf-8, colocar en el cabezal html utf-8, y crear la base de datos en utf-8 (no así las tablas ni los campos, así queda todo estándar según la base).
> Pero sin duda que tus criticas
> caen bien claro con las
> aclaraciones pertinentes...
Las aclaraciones son erróneas, espero que se comprenda.
Adjunto anexo a la discusión, que me parece aporta y complementa:
Post: "¿La empresa cuenta con framework propio?"
Algunos puntos interesantes que comenta el autor:
- "A 2008, el mundo del software no necesita otro framework casero realizado por mentes privilegiadas"
- "El tener un framework propio es indicador, en el 99% de los casos, de estar reinventando la rueda."
- "En serio, cualquier cosa que no implique corregir los errores del creador de un framework casero, será más que suficiente"
Con esto no quiero decir que esté de acuerdo o no con el desarrollo de un framework (como en este caso es Kumbia), sino todos los puntos que hay que tener en cuenta, tanto "en contra" como "a favor" a la hora de hacer un proyecto como este, que de por sí es una carrera que se hace "de atrás" y "perdiendo".
Publicar un comentario