Evaluar la calidad de un desarrollo Web por su código HTML y Javascript

cesar — Fri, 02 Oct 2009 15:57:43 +0000

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 ““, 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

Programadores: máquinas y operarios

cesar — Thu, 10 Sep 2009 12:14:34 +0000

Cuando nos ponemos a pensar en el proceso de producción de software, pocas veces deducimos que desarrollar software tiene etapas muy similares a desarrollar un automóvil, hamburguesas en gran escala, etc. Hablamos básicamente de maquinarias y operarios de las mismas.

He conocido decenas de personas que piensan que los programadores están sobrevalorados, que cobran mucho dinero, y que en realidad son el escalón más bajo de las corporaciones de software. Su indignación pasa al ver casos en los cuales programadores de nivel Sr. alcanzan sueldos que superan a los de un presidente de compañías chicas/medianas.

Si tuviéramos que fabricar hamburguesas en masa, necesitaría de una picadora de carne con su correspondiente operario, una mezcladora, una maquina que las empaque, y un transporte para poder distribuir. Al analizar la inversión inicial de nuestra fabrica de hamburguesas, y sus costos mensuales, veríamos que tenemos que comprar maquinaria, y pagar sueldos de operarios, además del mantenimiento que demandaran las maquinas.

El software (incluidas las aplicaciones web) también requiere de un proceso de producción, una inversión inicial, y tiene un costo mensual. Muchos creen que los ordenadores son la “maquinaria”, pero en realidad es simplemente la herramienta.

La maquinaria en el desarrollo de software se encuentra junto con el operario, es decir, el programador es la maquinaria y el operario, todo en uno.

Identificamos como maquinaria un par de factores importantes:

La experiencia del programador: es fundamental, y no tiene nada que ver con “saber programar”, ya que la experiencia lo que aporta al programador es la capacidad de resolver problemas valiéndose de sus vivencias, y no de su capacidad de razonamiento para poder buscar una solución a partir únicamente del problema.
Conocimientos adicionales a los académicos o demandados: muchas veces encontramos programadores que en su haber, tienen una batería de conocimientos que exceden a lo que suponemos necesitamos para desarrollar el proyecto, y esto puede ser de gran ayuda ante situaciones que no se tenían previstas.

Como todo proceso de producción, la calidad de nuestra maquinaria, materia prima y operarios, dará como resultado la calidad de nuestro producto final.

He visto muchas veces como para proyectos medianos/grandes se recurren a programadores que no cuentan ni con el conocimiento suficiente, ni con la experiencia necesaria. La base de una decisión de ese tipo, simplemente costos, el resultado, un mal producto. Mientras algunas empresas de software sigan tomando como base que le están pagando solamente al operario, y no a la maquinaria, nunca podrán obtener software de calidad, y creo que tenemos varios ejemplos a la vista.