WIP: Translate to ES_es

manuscript-es/01-preface.md

@@ -0,0 +1,77 @@
+# Prefacio
+
+La idea para este libro apareció después de mi charla “Refactoring Like a Superhero,”[^talk] que realicé en Enero del 2022. Para esta charla había recopilado técnicas y metodologías de refactorización. Quería compartirlas.
+
+En algún punto, se hizo evidente que no podía meter todo lo que quería explicar en 40 minutos.
+
+Sin embargo, el material recortado no era inútil. Contenía detalles y explicaciones sobre el uso y aplicación de las técnicas. Decidí que, tendría más sentido no eliminar todo lo que no cabía sino cambiar el formato y publicarlo como un libro online. Así es como empezó este proyecto.
+
+## Quién podría querer leer este libro
+
+Este libro puede ser de gran ayuda para desarrolladores de servicios web y aplicaciones de usuarios, que escriben código en un lenguaje de alto nivel y tienen algunos años de experiencia.
+
+Los desarrolladores de librerías también pueden encontrar ideas, pero me he centrado en las aplicaiones de usuario, ya que tengo más experiencia en esa area.
+
+Este libro no considera las necesidades y limitaciones del desarrollo de bajo nivel. Algunas metodologías en él pueden contradecir las buenas prácticas del código de bajo nivel. Si tu desarrollas "cerca del hardware", por favor, se cuidadoso y hazlo bajo tu propio riesgo. 😃
+
+## Que no es este libro
+
+No pretendo mostrarte el "único camino correcto" de refactorizar y escribir código en este libro. Si tienes mucha experiencia, probablemente ya sepas la mayoría de técnicas descritas y tienes tu propia opinión.
+
+Además, no se trata de un manual paso a paso de aplicación universal a todos los proyectos.
+
+El propósito de este libro es el de describir un conjunto de prácticas y metodologías que me ayudaron, a mí y a las personas con las que he trabajado, a escribir un código mejor.
+
+No todas las prácticas son aplicables en todos los casos. El uso de una idea depende en gran medida del proyecto, el contexto, los recursos disponibles, y el propósito de la refactorización. Trata de elegir aquellas técnicas que te proporcionan un mayor beneficio y un menor costo.
+
+Si algo del libro te parece útil, discútelo con tus colegas y otros desarrolladores. Asegúrate de que tú y tu equipo tenéis la misma opinión sobre los beneficios y los costes de la idea elegida. No apliques algo que resulte controvertido a tu equipo.
+
+## Limitaciones y aplicación
+
+Todas las técnicas descritas son una recopilación de libros que he leído y de mi experiencia en desarrollo. He pasado la mayoría de mi tiempo desarrollando medianas, y a veces grandes, aplicaciones de usuario.
+
+Mi experiencia influye en mi forma de ver el buen código. Básicamente, todo el libro es una muestra de mi percepción del desarrollo en 2022. Mi opinión puede haber cambiado si estás leyendo esto en el futuro.
+
+| Por cierto 🐝                                                                                             |
+|:----------------------------------------------------------------------------------------------------------|
+| Actualizaré los textos si mi opinión cambia, pero no puedo garantizar de que lo haga rápido y sin demora. |
+
+Al leer el libro, ten en cuenta los sesgos cognitivos del autor. Sopesa las técnicas antes de utilizarlas y considera su aplicabilidad a tu proyecto.
+
+## Es bueno saberlo antes de leerlo
+
+En el texto, asumo que ya conoces el concepto de refactorización[^term] y que tienes algunos años de experiencia programando. Espero que ya hayas encontrado problemas con la descomposición de tareas, "débiles" abstracciones, separación de conceptos entre módulos, etc.
+
+Espero que hayas escuchado algunas de "las palabras de moda en la programación" de esta lista:
+
+- Separación de conceptos
+- Acoplamiento y cohesión
+- Estilo declarativo
+- Capas de abstracción
+- Separación entre comandos y consultas
+- Transparencia referencial
+- Canalización funcional
+- Núcleo funcional en un caparazón imperativo
+- Arquitectura en capas, "Puertos y adaptadores"
+- Dirección de las dependencias
+- Inmutabilidad y ausencia de estado
+- Aplicaciones de 12 factores
+
+No tienes por qué conocerlos. Exploraremos estos términos y técnicas a medida que vayamos progresando. Pero, es bueno si tienes una ligera idea sobre su significado.
+
+## Por qué otro libro
+
+Hay muchos libros escritos sobre refactorización, ¿Por qué necesitamos otro?
+
+En general, no lo hacemos. Todos los principios y técnicas se describen en otros libros, muy probablemente de forma mucho más detallada, lógica y correcta.
+
+Necesito este texto, en primer lugar, para mí:
+
+- Para sistematizar lo que hoy sé;
+- Para referirme a un tema concreto cuando discuta un problema;
+- Para marcar el nivel de mis conocimientos, de modo que entienda dónde debo mejorar y qué debo aprender.
+
+Sin embargo, pensé que tal vez este texto podría ser útil para alguien más, así que aquí está. Espero que este libro le resulte útil.
+
+[^talk]: “Refactor Like a Superhero” Charla, https://bespoyasov.me/talks/refactor-like-a-superhero/
+[^term]: Refactorización del código, Wikipedia, https://en.wikipedia.org/wiki/Code_refactoring

manuscript-es/02-introduction.md

@@ -0,0 +1,103 @@
+# Introducción
+
+Refactorizar requiere recursos. La cantidad de estos recursos depende del tamaño del proyecto y de la calidad de su código. Cuanto más grande sea el proyecto y peor la calidad de su código, más difícil es limpiarlo y más recursos requerirá.  
+
+Para justificar la inversión de recursos y buscar un balance entre costes y beneficios. necesitamos entender los beneficios y limitaciones de refactorizar.
+
+## Beneficios para desarrolladores
+
+La calidad del código es una inversión en los desarrolladores, más tiempo libre en el futuro. Cuanto más simple y limpio sea el código, menos tiempo invertiremos en arreglar bugs y desarrollar nuevas funcionalidades.
+
+Los desarrolladores pueden preocuparse por diferentes propiedades del código. Por ejemplo, podríamos querer:
+
+- Encontrar código relacionado con partes específicas de la aplicación más rápidamente.
+- Eliminar malentendidos sobre como el código trabaja y evitar mala comunicación y conflictos en el equipo.
+- Hacer más fáciles las revisiones de código y comprobar que se cumplen los requerimientos de negocio.
+- Añadir, cambiar y eliminar código sin problemas y sin regresiones.
+- Reduce the time to find and fix bugs and make debugging process more convenient.
+- Reducir el tiempo de buscar y arreglar bugs y hacer el proceso de depuración más fácil.
+- Simplificar la exploración del proyecto a los nuevos desarrolladores.
+
+Esta lista está incompleta. Otras cualidades pueden ser necesarias para un equipo en particular, variando de proyecto a proyecto.
+
+Refactorizar periodicamente ayuda a prestar atención a las propiedades del código antes de que los problemas aparezcan. hace que trabajemos de forma más eficiente, dando a los desarrolladores tiempo y recursos extras y previene "grandes refactorizaciones" en el futuro.
+
+## Beneficios para la empresa
+
+En un proceso de desarrollo perfectamente organizado, no es necesario "vender" la refactorización a la empresa. En este tipo de proyectos, la mejora periódica del código es el nucleo del desarrollo, y el mal código no se acumula: no es necesario "no es necesario explicar los beneficios a la empresa" en este caso.
+
+Sin embargo, hay proyectos en los que el desarrollo se organiza de forma diferente por diversas razones. En estos proyectos, por regla general, el código heredado tiende a acumularse.
+
+Podemos sentir la necesidad de mejorar el código, pero no podemos tener suficientes recursos para eso. Proponer "tomar una semana para refactorizar" puede causar un conflicto de intereses por que, para negocio, suena como "no haremos nada util durante una semana". Estos son los casos donde podemos necesitar "vender" las ideas de mejora de código.
+
+Los beneficios de la refactorización no son evidentes para el negocio porque no son inmediatos. Podemos verlos en el futuro, pero es difícil de predecir cuando.
+
+Normalmente, para vender la idea de refactorizar a negocio, deberíamos de hablar en su mismo idioma, y _vender el resultado, not el proceso_. Discutir exactamente sobre el resultado que obtendremos con el tiempo invertido:
+
+- Dedicaremos menos tiempo a corregir errores, por lo que el número de usuarios descontentos disminuirá.
+- Empezaremos a implementar nuevas funciones antes que nuestros competidores, por lo que generarán nuevos usuarios y beneficios.
+- Entenderemos mejor los requisitos y las limitaciones, por lo que reaccionaremos más rápidamente ante problemas imprevistos.
+- Facilitaremos la incorporación de nuevos desarrolladores para que realicen cambios significativos antes.
+- Disminuiremos la rotación de personal porque los desarrolladores no huyen del buen código, sino del malo.
+
+Podemos usar varios tipos de métricas para medir la calidad del código. Será mucho más fácil determinar la necesidad de la refactorización apoyándose en las cifras. Por ejemplo, las estadísticas de costes podrían ayudar a incorporar la refactorización regular en el proceso de desarrollo sin problemas. 
+
+## “Buen” Código, “Mal” Código
+
+No es fácil de nombrar una lista de características _universales_ del buen código. Hay algunas, pero también tienen limites de aplicabilidad.
+
+| Por ejemplo 💡                                                                                                                                                |
+|:--------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Creo que la complejidad ciclomática y el número de dependencias son más o menos características universales. Pero hablaremos sobre ello en futuros capítulos. |
+
+Muchos de los libros que he leído también describen el código de forma subjetiva.[^workingeffectively][^readablecode][^cleancode] Diferentes autores usan diferentes palabras, pero siempre enfatizan la "legibilidad".
+
+Algunos estudios han intentado determinar esta "legibilidad".[^evaluatingstudies][^readability][^howreadable] Sin embargo, sus ejemplos son pequeños o sesgados, por lo que es difícil concluir las reglas universales del "buen" código.
+
+En la práctica, podemos intentar buscar código "malo" en vez de "bueno". Es más fácil porque podemos utilizar la ayuda de la heurística y las "alarmas cognitivas" al buscarlo.
+
+Las alarmas cognitivas son las sensaciones que tenemos al leer un código malo. Creo que un código necesita ser refactorizado si uno de estos pensamientos surge al leerlo:
+
+#### Difícil de leer
+
+- Nos resulta difícil leer el código si está sin formato, entrelazado o con mucho ruido.
+- Si hay muchos detalles innecesarios en el código, no hay un punto de entrada claro.
+- Si es difícil seguir la ejecución del código, si tenemos que saltar entre pantallas, archivos o líneas constantemente.
+- Si el código es inconsistente, si no sigue las reglas del proyecto.
+
+#### Difícil de cambiar
+
+- El código es difícil de cambiar si tenemos que actualizar muchos archivos o volver a comprobar toda la aplicación al añadir una función.
+- Si no estamos seguros, podemos eliminar sin problemas un trozo de código concreto.
+- Si no hay un punto de entrada claro o no podemos relacionar una característica con un módulo específico.
+- Si hay demasiado código repetitivo o copy-paste.
+
+#### Difícil de testear
+
+- El código es difícil de probar si necesitamos una "infraestructura compleja" para las pruebas o tenemos que simular muchas funciones.
+- Si debemos emular toda la aplicación en ejecución para comprobar una sola función.
+- Si las pruebas de una tarea requieren datos irrelevantes para la misma.
+
+#### Difícil de “Meter en la cabeza”
+
+- El código no entra en nuestras cabezas si es difícil seguir la pista de lo que ocurre en él.
+- Si a la mitad del módulo es difícil recordar lo que ocurrió al principio.
+- Si el código es "demasiado complicado" y dibujar diagramas no ayuda a entenderlo.
+
+#### Code Smells
+
+Algunos de esos problemas ya se han plasmado en forma de code smells. _Code smells_ son anti-patrones que generan problemas.[^smells]
+
+Hay soluciones para la mayoría de code smells. A veces es suficiente con mirar el código, encontrar el code smell, y aplicar una solución específica.
+
+| Sobre smells 🦨                                                                                                                                                                                                                                              |
+|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| A menudo, la mayoría de ejemplos de code smells son mostrados en código escrito en POO. que pueden no ser tan valiosos en el mundo de JavaScript. No obstante, algunos de los code smells son universales y aplicables a la POO y al código multi-paradigma. |
+
+[^workingeffectively]: “Working Effectively with Legacy Code” by Michael C. Feathers, https://www.goodreads.com/book/show/44919.Working_Effectively_with_Legacy_Code
+[^readablecode]: “The Art of Readable Code” by Dustin Boswell, Trevor Foucher, https://www.goodreads.com/book/show/8677004-the-art-of-readable-code
+[^cleancode]: “Clean Code” by Robert C. Martin, https://www.goodreads.com/book/show/3735293-clean-code
+[^evaluatingstudies]: Evaluating Code Readability and Legibility: An Examination of Human-centric Studies, https://github.com/reydne/code-comprehension-review/blob/master/list-papers/AllPhasesMergedPapers-Part1.md
+[^readability]: Code Readability Testing, an Empirical Study, https://www.researchgate.net/publication/299412540_Code_Readability_Testing_an_Empirical_Study
+[^howreadable]: How Readable Code Is, a Readability Experiment https://howreadable.com
+[^smells]: Code Smells, Refactoring Guru, https://refactoring.guru/refactoring/smells