Algunas de estas técnicas han sido guardadas celosamente por los grandes gurús de Javascript (y en general de cualquier lenguaje un poco moderno) pero hoy por fin verán la luz para que todo el mundo pueda convertirse en uno de ellos:

Arrays

Lo mejor para saber el número de elementos que tiene tu array no es usar la propiedad length ya implementada de serie. No. Lo mejor es tener una variable numeroElementos que vamos actualizado cada vez que hagamos una operación. De esta manera conseguimos varia ventajas:

• Para eliminar el último elemento añadido en un array no merece la pena usar el método pop(). Es "más mejor" hacer numeroElementos--;
• Seguro que alguna vez habéis tenido que hacer operaciones con los elementos de un array del tipo "el primero y el segundo, segundo y tercero, tercero y cuarto..." y siempre había un problema con el último (nos salíamos del array y teníamos una excepción, o teníamos que crear un caso especial o...). Pues gracias al consejo anterior nos olvidamos de esos problemas ya que ¡el elemento seguirá estando a pesar de hacer numeroElementos--!
• La mejor manera de vaciar por completo un array en JS no es hacer Array.clear(myArray); o myArray = []; o myArray = new Array();  Lo mejor es hacer myArray.length = 0;  El porqué no es mejor hacer numeroElementos = 0; es todavía un misterio para mí.

Condicionales

Como los compiladores a veces son un poquito tontitos, siempre está bien verificar dos veces (o más) que algo es cierto. if(variableBooleana == true)

Y vosotros, ¿qué secretos informáticos habéis descubierto en vuestros proyectos y podéis compartir?

Seguro que alguna vez os ha tocado algún proyecto en el que al ver el diseño o el código habéis dicho: "pufff, esto tiene un tufillo a mierda fresca que no veas". Pues ese es el olor de vuestro software. Y es que es cierto aquello de que la mejor métrica para media la calidad del código es la siguiente:

El proyecto en el que estoy trabajando ahora huele tanto que ninguno de la empresa se quiere acercar al grupo de desarrollo. Por supuesto, el código tiene infinitos años y a cada nueva versión se le han ido añadiendo nuevas funcionalidades que más bien eran parches sobre un diseño pobre y mal pensado. Pero... ¿cómo identificar esos olores? Brian Foote y Joseph Yoder han realizado hace ya tiempo un artículo que se llama Big Ball of Mud que probablemente os suene a todos (y sino ya lo estáis leyendo, no tiene desperdicio).

While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed. This paper examines this most frequently deployed of software architectures: the BIG BALL OF MUD. A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture.

En el paper se identifican las principales causas y los patrones que llevan a que una arquitectura sea considerada una "Gran Bola de Mierda". Durante los próximos posts los iré comentando además de poner algún ejemplo relacionado con el glorioso proyecto en el que tengo el honor de trabajar. Hasta entonces, happy coding!