Evaluar la calidad de un desarrollo Web por su código HTML y Javascript
Muchas veces nos vemos en la necesidad de tener que hacer una evaluación rápida y muy preliminar sobre la calidad de una aplicación/sitio web, sin tener acceso a su código fuente y solo viendo su HTML y javascript.
Estos son solo algunos tips que podemos tener en cuenta, a fin de saber si las personas que intervienen en el desarrollo son “Srs” o “Jrs”.
Evaluando HTML.
El HTML de un sitio Web suele ser engañoso, ya que muchas veces las empresas cuentan con buenos maquetadores, y pésimos programadores, lo que da un sitio de un HTML muy “bonito”, pero una programación muy caótica. Sin embargo, el HTML puede tener algunos indicios.
Meta descriptions, keywords y demás metas, que sean dinámicos, dan la idea de que se esta trabajando con una lógica de templates.
Titles adecuados, URLs amigables, son otros indicios de una cierta calidad de desarrollo. No cualquier programador sabe utilizar mod_rewrite.
Evaluando buscadores.
Si la aplicación/sitio cuenta con un buscador de contenido, es importante que intentemos identificar qué tan inteligente es. Podemos buscar un contenido puntual, y extraer criterios para formar diferentes patrones de búsqueda a fin de ver si hay o no resultados. Escribir palabras en formas incorrectas, medir la velocidad del proceso de búsqueda, que identifique contenido relacionado, son algunos de los indicios de un buen programador.
AJAX
Muchos sitios dicen usar “<abbr title="asynchronous JavaScript and XML"AJAX“, pero la verdad es que simplemente aprovechan el objeto request, y traen grandes porciones de HTML que terminaran en un inner. Esto simplemente es un sÃntoma de una falta de experiencia, conocimiento y criterio de desarrollo que no puede ser aceptado bajo ningún punto de vista.
Si trabajamos con AJAX ni siquiera tenemos que esperar recibir XML, la verdad es que un buen trabajo es con JSON de por medio.
Asà como no aceptarÃamos mejillones abiertos en la pescaderÃa, no aceptamos AJAX sin JSON.
Frameworks en JavaScript.
Muchos lo toman a un nivel personal, y es totalmente justificado, pero considerado que si un programador es serio, sabe lo que hace, y ama el arte de la programacion, estará mas que de acuerdo con que el framework de javascript a usar es Mootools.
Si bien respeto a jQuery, Prototype, etc. Mootools es el framework mas rapido, mejor resuelto y realmente pensado para ayudar al programador que he conocido. Hay que ser valiente para resolver todo con este framework, y no caer en la tentacion de un jQuery.
JavaScript made in casa.
Es importante buscar que el JS no dependa 100% del framework que se está usando en el proyecto. Tenemos que poder identificar si son una gran cantidad de funciones, si organización, o si son clases estáticas (de la forma que nos permite JS) pensadas y bien modeladas. La calidad de la técnica es totalmente reconocible en JavaScript, y es uno de los puntos principales.
Creo que esos datos nos ayudarán a reconocer, como bien dijimos en forma muy preliminar, que tipo de programadores estan detrás de un proyecto o aplicación
-
Totalmente de acuerdo con el artÃculo, salvo en un punto:
“Meta descriptions, keywords y demás metas, que sean dinámicos, dan la idea de que se esta trabajando con una lógica de templates.”Eso no es un indicio claro,de estar trabajando con un CMS; ya que programar la funcionalidad de metatags dinámicos en función del contenido es una labor interesante para el cliente final.
Adicionalmente al artÃculo, añadirÃa lo siguiente:
- Observar el código fuente “compilado” por el navegador (en firefox Ctrol+U).
- Se deben cumplir los estándares web del W3C.
- Se deben cumplir las pautas de accesibilidad web 1, 2 y 3.
- En caso de usar un CMS, ver si es un copy/paste o ha sido trabajado.Gracias por el aporte y un saludo.
2
Oct
Siempre me pareció raro el rango de Sr, Jr, Semi-Sr a la hora de evaluar puestos. No hay indicadores “tangibles” para ello y esto parece entrar en discusión constante en muchas de las búsquedas laborales. Para una empresa puedes ser junior, para otra senior, independientemente de los “años/experiencia” que demuestres.
Si evaluamos un desarrollo por su código únicamente estamos tomando en cuenta una sola variable…. hay que tener en cuenta el tiempo que se le dedicó a ello, también. Muchas veces desarrollos salen mal porque los tiempos se calcularon mal… además de que con presiones en el tiempo a desarrollar el código siempre va a estar “atado con alambres”. También es importante evaluar la cantidad de personas envueltas en el desarrollo.
No creo que usar jQuery te haga ‘menos’ programador que uno que usa Moo Tools, si creo que el hecho de usarlo puede ‘aliviar’ a muchos que no están familiarizados con código.
Creo que hay mucho para “discutir” sobre este tema.