La refactorizacion, o refactoring, es simplemente un proceso que tiene como objetivo mejorar el codigo de un proyecto sin alterar su comportamiento para que sea mas entendible y tolerante a cambios. Para comenzar a refactorizar es imprescindible que en nuestro proyecto existan test automaticos, ya scan unitarios o de integracién, que nos permitan saber, en cualquier momento, si el cédigo que hemos cambiado sigue cumpliendo los requisitos. Sin Enel caso de que el proyecto contenga test, el siguiente paso es saber detectar cuando debemos refactorizar. Por norma general, debemos refactorizar cuando detectamos que nuestro eédigo no tiene la suficiente calidad 0 cuando detectamos algtin code smell, veremos nos cuantos de estos a lo largo del libro. A nivel personal me gusta Por otro lado, puede darse el caso en el que refactorizar no sea suficiente y necesitemos cambiar la arquitecura o redisefiar algunos componentes. Por ejemplo, imaginemos una solucién en NodeJS que debfa ser muy escalable y aceptar un numero elevado de peticiones concurrentes. Probablemente hubiera sido interesante haber disefiado un sistema de colas para ello, Pero el equipo, de forma prudente y deliberada, puede decidir lanzar las primeras versiones con una arquitectura més simple para validar el producto en el mercado, atin sabiendo que a corto o medio plazo habra que cambiar la arquitectura. Un buen punto de partida para prevenir la deuda técnica es intentar valorar si estamos cumpliendo las cuatro reglas del disefio simple planteadas por Kent Beck: « El cédigo pasa correctamente los test + Revela la intencién del disefio + Respeta el principio DRY « Tiene el menor mimero posible de elementos. “Cédigo Limpio es aquel que se ha escrito con la intencién de que otra persona (0 ti mismo en el futuro) lo entienda.” - Carlos BIZVariables, nombres y ambito “Nuestro cédigo tiene que ser simple y directo, deberia leerse con la misma facilidad que un texto bien escrito”. — Grady Booch” La diferencia entre let y const radica en que a esta Ultima no se le puede reasignat su valor, aunque si modificarlo. Es decir, se puede modificar (mutar) en el caso de un| objeto, pero no sise trata de un tipo primitivo. Por este motivo, usar const en variables en las que no tengamos pensado cambiar su valor puede ayudarnos a mejorar lal intencionalidad de nuestro cédigo. El lenguaje ubicuo es un proceso en el cual se trata de establecer un lenguaje comin entre programadores y stakeholders (expertos de dominio), basado en las definiciones y terminologia que se emplean en el negocio. Una buena forma de comenzar con este el proceso podria ser crear un glosario de términos. Esto nos permitiré, por un lado, mejorar la comunicacién con los expertos del negocio, y por otro, ayudarnos a escoger nombres mas precisos para mantener una nomenclatura homogénea en toda la aplicacién. Por otro lado, debemos usar el mismo vocabulario para hacer referencia al mismo concepto, no debemos usar en algunos lados User, en otro Client y en otro Customer, a no ser que representen claramente conceptos diferentes. Léxico coherente //bad getUser Info); getClientData( ); getCustomerRecord(); //better getUser() Nombres segun el tipo de datoArrays V/bad const fruit = [ // regular const fruitlist = [ // good const fruits = [ // better const fruitNames = [ Booleanos Los booleanos solo pueden tener 2 valores: verdadero 0 falso. Dado esto, el uso de prefijos como is, has y can ayudara inferir el tipo de variable, mejorando asi la legibilidad de nuestro cédigo. Ndmeros Para los niimeros es interesante escoger palabras que describan niimeros, como min, max o otal: Funciones Los nombres de las funciones deben representar acciones, por lo que deben construir- se usando el verbo que representa la accién seguido de un sustantivo. Estos deben de ser descriptivos y, a su vez, concisos. Esto quiere decir que el nombre de la funcién debe expresar lo que hace, pero también debe de abstraerse de la implementacién de la funcién. Funciones de acceso, modificacién 0 predicado getUser() setUser(...) isValidUser()Clases Las clases y los objetos deben tener nombres formados por un sustantivo o frases de sustantivo como User; UserProfile, Account o AdressParser. Debemos evitar nombres genéricos como Manager, Processor, Data o Info. Funciones “Sabemos que estamos desarrollando cédigo limpio cuando cada funcién hace exactamente lo que su nombre indica”. - Ward Cunningham™ Parametros y argumentos Los argumentos son le que llamamosa las funciones, mientras que los parametros son las variables nombradas que reciben estos vi dentro de nuestra funcién: Si tus funciones, como norma general, suelen tener un tamatio demasiado grande o demasiados niveles de indentacién, es probable que hagan demasiadas cosas. Esto nos lleva a otra recomendacién, quizds la més importante: las funciones deben hacer una tnica cosa y hacerla bien. Otro punto fundamental para lograr que nuestras funciones sigan siendo simples es tratar de limitar los niveles de indentacién a 16 Para ello debemos evitar la anidacién de condicionales y bucles. Esto nc