Javascript: Expresiones regulares

Una expresión regular es un patrón usado para buscar coincidencias de combinaciones de caracteres dentro de otras cadenas de caracteres (strings). En JavaScript, estos patrones son objetos. 

Estos patrones se pueden usar como métodos del objeto tipo RegExp con los métodos exec() y test() y también con objetos String con los métodos match(), matchAll(), replace(), replaceAll(), search() y split(). 

Creación de expresiones regulares

Para crear expresiones regulares existen 2 maneras: 

• Usando un literal que consiste en un patrón encerrado entre //. 

de esta forma la compilación del patrón se realiza cuando el script se carga. En los casos en los que la expresión regular permanece constante, esta manera mejora el rendimiento.

• Usando el constructor de RegExp

usando la función constructor la compilación se hace en tiempo de ejecución. Se debe usar esta forma cuando la expresión regular cambia durante la ejecución o no se conoce el patrón de antemano y se obtiene durante la ejecución del script.

Utilizando patrones 

Una expresión regular está compuesta simplemente de caracteres tal como /abc/ o una combinación de caracteres simples y otros especiales tal como /ab*c/. 

En el caso de /abc/ este patrón busca la coincidencia con la cadena abc dentro de la cadena analizada. Por ejemplo: 

 En el caso de /ab*c/, el caracter * es un caracter especial que indica en el patrón que el caracter b en este caso se puede presentar 1 o varias veces. Por ejemplo: 

 

Qué patrones se pueden construir

Entonces un patrón está compuesto por una cadena de caracteres entre barras oblicuas (slashes). Los caracteres pueden representarse a ellos mismos (caracteres simples) o pueden tener un significado especial (carateres especiales). Según la clasificación que hacen en MDN Web Docs de los tipos de caracteres especiales son:

• Aserciones.- indican el comienzo y el final de líneas y palabras, y otros patrones. Ejemplos de aserciones
  
• Clases de caracteres.- Distingue diferentes tipos de caracteres. Por ejemplo, distinguir entre letras y dígitos.
• Grupos y rangos.- indican grupos y rangos de caracteres. Ejemplos de grupos y rangos
• Cuantificadores.-  indica el número de repeticiones.
• Caracteres de escape de propiedades Unicode.- indica por ejemplo, letras mayúsculas y minúsculas, símbolos matemáticos y de puntuación.
  

Conclusiones

Merece la pena que todo programador le dedique algunas hora a aprender como se manejan las expresiones regulares. Esto ayuda a que en el momento de tener que usarlas se manejen con soltura y no sean una piedra en el camino para poder entender o construir el código. Y no se aprenden en 5 minutos.

 

Cómo conseguir una buena arquitectura y un buen diseño del software

Robert C. Martin en su libro “Clean Architecture: A Craftsman's Guide to Software Structure and Design” muestra una perspectiva muy acertada de lo que es la arquitectura y el diseño del software. En el capítulo 1 dice:

“La palabra arquitectura se usa a menudo en el contexto de algo de alto nivel que es contrapuesto a algo de bajo de nivel, mientras que diseño parece que implica decisiones de bajo nivel. Esta separación entre arquitectura y diseño no tiene sentido si se mira a lo que hace un arquitecto de software en su día a día.

Considere el arquitecto que diseño mi nueva casa. ¿Tiene la casa una arquitectura? Por supuesto que la tiene. ¿Y en qué consiste esa arquitectura? Pues contiene la forma de la casa, el aspecto exterior, la elevación del terreno y el diseño de los espacios y habitaciones. A medida que analizo los diagramas que el arquitecto me ha preparado, veo una inmensa cantidad de detalles. Veo donde se colocará cada interruptor, cada enchufe y cada punto de luz. Veo que interruptores manejan que luces. Veo dónde está colocado el horno y el tamaño y la ubicación del calentador de agua y la bomba de desagüe. Veo descripciones detalladas de cómo se construirán las paredes, los techos y los cimientos.

En resumen, veo todos los pequeños detalles que dan soporte a las decisiones de alto nivel. En definitiva los detalles y las decisiones de alto nivel son parte de un todo que es la casa que se construirá.

Lo mismo pasa con el diseño de software. Los detalles de bajo nivel y las estructuras de alto nivel son parte de un todo. Forman un tejido continuo que define la forma del sistema. No se puede tener uno sin el otro, por lo tanto no hay una clara línea que los divida. Son realmente un continuo de toma de decisiones desde el nivel de detalle más alto al más bajo.

El objetivo de la arquitectura del software no es más ni menos que minimizar los recursos humanos necesarios para construir y mantener el sistema.

La medida de la calidad de la arquitectura y el diseño del software puede ser simplemente la medida del esfuerzo requerido para cumplir con los requisitos del cliente. Si el esfuerzo es pequeño, y permanece bajo a lo largo de la vida del sistema el diseño es bueno. Si el esfuerzo crece con cada nueva versión, el diseño es malo. Es tan simple como esto.”

La forma de conseguir una buena arquitectura para un sistema software es más compleja a medida que el sistema a construir es más complejo. La complejidad no es la misma si estamos construyendo una web para la venta online de una pequeña librería que si el sistema es una app para acceder a un banco en la cual podemos hacer todo tipo de operaciones, desde transferencias de dinero, abrir una cuenta, invertir en fondos, etc . Cuanto más complejo es el sistema, más importante es que la arquitectura y el diseño sean de calidad.

Cuando se trata de sistemas complejos es difícil plantear una arquitectura idónea al comienzo de la construcción. Esto se debe a que al inicio todo son hipótesis, no hay nada construido sobre lo que probar la efectividad de las estructuras y abstracciones ideadas. Es por esto que actualmente existe una corriente dentro de los “Métodos Ágiles” que invita a crear la arquitectura poco a poco, sin empezar por establecer estructuras rígidas desde el comienzo del desarrollo. Lo importante es encontrar un equilibrio y no implantar estructuras más complejas, ni más simples de lo necesario.

Un inicio de lo que supone construir una arquitectura flexible y ajustada a las necesidades del sistema que se va a construir la aportó Peter De Grace con la Arquitectura Sashimi en 1990 en el libro “Wicked Problems, Righteous Solutions: A Catalog of Modern Software Engineering Paradigms” que se puede leer de forma gratuita registrándose en la web Internet Archive.

Para sistemas construidos con lenguajes basados en el paradigma de Orientación a Objetos, que son los que actualmente están más en boga, existen arquitecturas de referencia acuñadas por reconocidos expertos. Estas arquitecturas recomiendan estructuras genéricas altamente cohesionadas y poco acopladas que hacen uso de las herramientas suministradas por el paradigma OO, concretamente uno de los elementos más extensivamente usado son los interfaces.

Estás son:

• Arquitectura Onion de Jeffrey Palermo. Se puede consultar en Arquitectura onion
• Arquitectura Hexagonal de Alistar Cockburn. Se puede consultar en Arquitectura hexagonal
• Clean Arquitecture de Robert C. Martin que está ampliamente explicada en su libro “Clean Architecture: A Craftsman's Guide to Software Structure and Design: A Craftsman's Guide to Software Structure and Design” que se puede comprar en: