![\"\"](\"https:\/\/lh4.googleusercontent.com\/Gges0e6U2iZ5XXC1oIyQeRm6OkHY5r7d-bRFgSliPBTf3yLYnEak3mJIF_M62q_SiltsT7bjdPJqShEvLYgGRepNB6_ANqX1TqpXW_gQaFdYYAUSHh-3NVrilVQxfWZYsb0o_E_C4ApYyDNTzQhBaQ\")
<\/figure>\n\nTanto si escribe una aplicaci\u00f3n a peque\u00f1a escala como si colabora en un gran proyecto de software, el control del c\u00f3digo fuente es esencial para desarrollar un c\u00f3digo limpio. Utilizar el control de c\u00f3digo fuente le ayuda a rastrear y gestionar todos los cambios realizados en el c\u00f3digo. Sistemas como Source Control Management ofrecen un historial del proceso de desarrollo y ayudan a solucionar problemas cuando se integran contribuciones de varias fuentes. La utilizaci\u00f3n del control de c\u00f3digo fuente garantiza que pueda colaborar en el c\u00f3digo con sus compa\u00f1eros de equipo y solucionar r\u00e1pidamente los errores identificando qui\u00e9n realiz\u00f3 los cambios y qu\u00e9 cambios fueron. Sin el control de c\u00f3digo fuente, no puede saber en qu\u00e9 han trabajado sus compa\u00f1eros de equipo y la colaboraci\u00f3n es limitada. El control de fuentes le ayuda a agilizar el proceso de desarrollo y le ofrece una fuente consolidada para su c\u00f3digo. Con el control de fuentes, su equipo puede fusionar el c\u00f3digo sin conflictos y editar el c\u00f3digo compartido sin sobrescribir inconscientemente el trabajo de los dem\u00e1s. Algunos de los mejores sistemas de control de c\u00f3digo fuente son Git, Mercurial, Darcs, adem\u00e1s de Azure DevOps. <\/p>\n\n
Consejo de acci\u00f3n: Cree una cuenta en un sistema de control de fuentes en el que cargue todo su c\u00f3digo. Puede ser Git, Darcs o Azure DevOps, dependiendo de lo que se adapte a sus necesidades. Este sistema actuar\u00e1 como fuente primaria y \u00fanica de su c\u00f3digo, y podr\u00e1 acceder a \u00e9l cualquier desarrollador que est\u00e9 en el mismo proyecto que usted. <\/strong><\/p>\n\n Cuando encuentra un fallo en su c\u00f3digo la primera vez que intenta ejecutarlo, debe repararlo lo antes posible porque el c\u00f3digo suele estar a\u00fan fresco en su cerebro. La pronta reparaci\u00f3n de fallos establece una actitud para el equipo de desarrollo sobre lo comprometido que est\u00e1 usted a entregar un c\u00f3digo de calidad: cuantos m\u00e1s fallos, m\u00e1s compleja ser\u00e1 la reparaci\u00f3n. Los fallos gravitan hacia la multiplicaci\u00f3n, lo que significa que se acumulan si no se reparan a medida que van apareciendo. Y, cuando su c\u00f3digo tiene numerosos fallos, es dif\u00edcil rastrear la ra\u00edz del problema y consume mucho tiempo y dinero. Adem\u00e1s, un c\u00f3digo propenso a los fallos pone en peligro su reputaci\u00f3n. Presentar su c\u00f3digo a los clientes sin verificar si tiene fallos pone en juego su carrera. La mayor\u00eda de sus clientes pueden optar por otros desarrolladores que ofrezcan un c\u00f3digo mejor. Arreglar los fallos a medida que aparecen le ayuda a escribir un c\u00f3digo mejor y m\u00e1s limpio, porque los \u00fanicos fallos que tendr\u00e1 que arreglar son los que usted vea. <\/p>\n\n Consejo de acci\u00f3n: Capturar los fallos, buscar en los registros y acabar con ellos consume tiempo. Por lo tanto, es indispensable desplegar un software que pueda rastrear los fallos y ayudarle a repararlos antes de que sea demasiado tarde. <\/strong><\/p>\n\n Un software como Airbrake puede ser de gran ayuda, ya que es capaz de supervisar las trazas de toda la pila, realizar un seguimiento del despliegue y registrar los errores. Adem\u00e1s, Airbrake ofrece un panel de control para realizar un seguimiento de sus expectativas, lo que implica que los errores se solucionan en cuesti\u00f3n de segundos. <\/strong><\/p>\n\n Supongamos que su equipo a\u00fan no cuenta con probadores comprometidos por cada dos o tres desarrolladores. En ese caso, lo m\u00e1s probable es que est\u00e9 malgastando recursos (dinero y tiempo) o enviando c\u00f3digo con errores a sus clientes. Para tener un c\u00f3digo mejor y emplear a probadores, muchos empresarios piensan que los probadores son muy caros. Se equivocan; los probadores suelen ser m\u00e1s baratos que los programadores porque realizan una peque\u00f1a cantidad de pruebas al d\u00eda y no pueden ejecutar sus tareas sin los desarrolladores. Al fin y al cabo, los desarrolladores construyen el c\u00f3digo que los probadores eval\u00faan. El objetivo de los probadores es minimizar los riesgos asociados al comportamiento del c\u00f3digo en un entorno espec\u00edfico. Adem\u00e1s, los probadores suprimen y previenen el mayor n\u00famero posible de fallos y errores dif\u00edciles mediante una inspecci\u00f3n minuciosa. Probar el c\u00f3digo es crucial ya que descubre fallos antes de que el c\u00f3digo se entregue al cliente, algo que garantiza la calidad del software. Adem\u00e1s, los probadores le ense\u00f1ar\u00e1n a desarrollar un c\u00f3digo mejor porque le guiar\u00e1n a trav\u00e9s de los fallos que introduzca en el c\u00f3digo y le mostrar\u00e1n varias formas de resolver los problemas. <\/p>\n\n Consejo de actuaci\u00f3n: contrate a un probador que pueda planificar los procesos de prueba y garant\u00eda de calidad, emplee software orientado a las pruebas e implemente pruebas automatizadas siempre que sea posible.<\/strong><\/p>\n\n Las pruebas unitarias son un enfoque mediante el cual se prueban unidades individuales de datos de control, procedimientos de uso y procedimientos operativos asociados al c\u00f3digo fuente para determinar su idoneidad para la utilizaci\u00f3n. Las pruebas unitarias suelen ser pruebas automatizadas escritas y realizadas por usted y su equipo. Garantizan que una parte del software, conocida habitualmente como unidad, cumple su dise\u00f1o y se comporta como se espera. Las pruebas unitarias le ayudan a escribir un c\u00f3digo mejor porque su objetivo es separar cada parte del software y determinar si las piezas individuales son correctas. Adem\u00e1s, las pruebas unitarias identifican los fallos en una fase temprana del proceso de desarrollo. Esto implica fallos en su implementaci\u00f3n y fallos en la descripci\u00f3n de la unidad. Escribir pruebas unitarias es esencial en el proceso de desarrollo, ya que hace que su c\u00f3digo sea m\u00e1s limpio, flexible y f\u00e1cil de mantener. El despliegue de los cambios en el c\u00f3digo y la minimizaci\u00f3n de los fallos resultan mucho m\u00e1s accesibles. Cuando el c\u00f3digo se dise\u00f1a utilizando un enfoque basado en pruebas, los requisitos se convierten en casos de prueba espec\u00edficos. El software se mejora para superar nuevas pruebas. La utilizaci\u00f3n de pruebas unitarias aumentar\u00e1 la calidad de su trabajo hasta el punto de que sus compa\u00f1eros de equipo le consultar\u00e1n. <\/p>\n\n Consejo de acci\u00f3n: Inicialice un peque\u00f1o fragmento de c\u00f3digo que desee probar (normalmente conocido como sistema bajo prueba), aplique a continuaci\u00f3n un est\u00edmulo al sistema bajo prueba generalmente llamando a un m\u00e9todo del mismo y observe finalmente el comportamiento resultante.<\/strong><\/p>\n\n Al codificar, escribir\u00e1 muchos nombres para funciones, clases, variables, m\u00f3dulos y directorios, pero aseg\u00farese de que estos nombres tengan sentido para el cliente y los dem\u00e1s desarrolladores. Utilizar nombres sofisticados o poco claros para funciones y clases complica significativamente la l\u00f3gica de la aplicaci\u00f3n para cualquier programador que intente comprender su c\u00f3digo. Los nombres poco legibles para las clases tambi\u00e9n le afectan a usted. Con el tiempo, no ser\u00e1 capaz de recordar qu\u00e9 significaban los nombres poco claros en primer lugar. Convierta en una rutina escribir nombres claros y comprensibles en su c\u00f3digo. Independientemente del nombre que introduzca en su c\u00f3digo, aseg\u00farese de que cumple estos tres prop\u00f3sitos… qu\u00e9 hace, por qu\u00e9 existe y c\u00f3mo se utiliza.<\/em> Cuando utilice nombres claros y significativos, sus compa\u00f1eros desarrolladores y clientes no tendr\u00e1n que repasar todo el c\u00f3digo para averiguar qu\u00e9 hace una funci\u00f3n o qu\u00e9 representa una clase y por qu\u00e9 existe esa variable. Los nombres significativos hacen que su c\u00f3digo sea m\u00e1s claro y f\u00e1cil de leer por los clientes. Adem\u00e1s, minimiza el tiempo invertido al revisar el c\u00f3digo. Escribir nombres descriptivos lleva tiempo, pero cuando se empieza a escribirlos, se vuelve intuitivo y ahorra tiempo en t\u00e9rminos de mantenimiento, legibilidad y colaboraci\u00f3n, lo que se traduce en un c\u00f3digo limpio. <\/p>\n\n Consejo de acci\u00f3n: Cuando declare variables, clases o funciones, intente en la medida de lo posible nombrarlas de un modo que exponga claramente sus prop\u00f3sitos. Es decir, indique claramente qu\u00e9 hace el nombre, por qu\u00e9 existe y c\u00f3mo se utiliza. Elija un nombre que especifique lo que se est\u00e1 midiendo y la unidad de esa medida. <\/strong><\/p>\n\n Enviar\u00e1 c\u00f3digo de baja calidad cuando escriba c\u00f3digo, incluso en un equipo de una persona, sin un sistema organizado de seguimiento de datos o errores que resuma todos los errores conocidos. No se encuentre en el grupo de programadores que creen que pueden retener y recordar la lista de fallos en su cabeza. Apenas recordar\u00e1 un fallo al d\u00eda siguiente, y porque no podr\u00e1 recordar ning\u00fan fallo. Adquiera una base de datos de fallos para asegurarse de que todas las compras en c\u00f3digo se identifican y se arreglan. La base de datos puede realizar un seguimiento de los problemas y examina los esfuerzos realizados por usted y su equipo para resolver un fallo. Los sistemas de seguimiento de fallos ofrecen una mejor comunicaci\u00f3n a trav\u00e9s de interfaces de chat y notificaciones por correo electr\u00f3nico. Esto minimiza la brecha de comunicaci\u00f3n entre el grupo y avisa a la persona adecuada para que pruebe y solucione los fallos a tiempo. Las bases de datos de fallos pueden ser confusas y sencillas, dependiendo del entorno. <\/p>\n\n Un sistema funcional de seguimiento de fallos debe incluir los siguientes datos para cada fallo; <\/p>\n\n Utilizando un sistema de seguimiento de errores, escribir\u00e1 un c\u00f3digo mejor y m\u00e1s limpio sin esfuerzo. Una base de datos de errores es un componente obligatorio de una infraestructura profesional de desarrollo de software. El uso coherente de una base de datos de errores se considera uno de los distintivos de un buen equipo de software. <\/p>\n\n Consejo de acci\u00f3n: Cree una aplicaci\u00f3n de seguimiento de fallos que le permita registrar un nuevo fallo desde el frontend. La aplicaci\u00f3n debe utilizar un m\u00f3dulo personalizado que crear\u00e1 con el constructor de m\u00f3dulos. A continuaci\u00f3n, cree una estructura jer\u00e1rquica para que los elementos de contenido representen proyectos y fallos. <\/strong><\/p>\n\n La refactorizaci\u00f3n consiste en reestructurar el c\u00f3digo sin cambiar ni a\u00f1adir nada a su comportamiento y funcionalidad externos. Los cambios en el c\u00f3digo fuente existente preservan el comportamiento y la funcionalidad del software porque los cambios son muy peque\u00f1os, por lo que es poco probable que introduzcan nuevos errores. La refactorizaci\u00f3n forma parte del proceso de codificaci\u00f3n. Evitar la refactorizaci\u00f3n es la forma m\u00e1s f\u00e1cil de acabar con un c\u00f3digo desordenado e imposible de mantener. La refactorizaci\u00f3n elimina la deuda t\u00e9cnica, mejora el dise\u00f1o del c\u00f3digo y hace que su c\u00f3digo sea m\u00e1s limpio y f\u00e1cil de comprender. Mediante la refactorizaci\u00f3n se deshace de variables irrelevantes, c\u00f3digo redundante, m\u00e9todos largos y bucles. A medida que refactoriza el c\u00f3digo, resulta m\u00e1s f\u00e1cil identificar los errores, ya que comprende toda la estructura del c\u00f3digo, lo que hace que su c\u00f3digo sea m\u00e1s limpio. Cuando el c\u00f3digo est\u00e1 m\u00e1s limpio y es m\u00e1s comprensible, a\u00f1adir funciones y depurar el c\u00f3digo es m\u00e1s accesible. El momento m\u00e1s conveniente para refactorizar su c\u00f3digo es antes de adjuntar actualizaciones y nuevas caracter\u00edsticas al c\u00f3digo existente. Retroceder y limpiar el c\u00f3digo antes de adjuntar nuevas actualizaciones mejora la calidad del c\u00f3digo y facilita a otros desarrolladores la mejora del c\u00f3digo original. <\/p>\n\n Consejo de actuaci\u00f3n: uno de los enfoques m\u00e1s utilizados para refactorizar c\u00f3digo es la refactorizaci\u00f3n por abstracci\u00f3n. Este enfoque se utiliza principalmente cuando hay una gran cantidad de refactorizaci\u00f3n. La abstracci\u00f3n requiere jerarqu\u00eda, herencia de clases y extracci\u00f3n. El principal objetivo de la abstracci\u00f3n es minimizar las repeticiones innecesarias en el c\u00f3digo. <\/strong><\/p>\n\n Cuando se le presentan los comentarios, se le anima a que los comente con la mayor frecuencia posible. Los comentarios describen por qu\u00e9 existe un fragmento de c\u00f3digo en lugar de lo que el c\u00f3digo hace. Cuando el c\u00f3digo est\u00e1 correctamente escrito, deber\u00eda ser evidente lo que hace; se supone que los comentarios arrojan luz sobre la intenci\u00f3n de quien lo escribi\u00f3. Los buenos comentarios son buenos para las advertencias, es decir, \u00abEliminar esto romper\u00e1 A, B y C\u00bb, pero en su mayor parte, los comentarios deber\u00edan descubrir cosas que no se pueden extraer instant\u00e1neamente del c\u00f3digo. Los buenos comentarios mejoran la legibilidad, ofrecen contexto sobre lo que el c\u00f3digo intenta hacer y le ayudan a recordar la parte del c\u00f3digo que debe refactorizarse. <\/p>\n\n Por mucho que escribir comentarios sea crucial para escribir un c\u00f3digo limpio, evite escribir comentarios malos o innecesarios. Si la situaci\u00f3n no requiere comentarios, entonces no los escriba porque los comentarios consumen tiempo y no repercuten en el comportamiento en tiempo de ejecuci\u00f3n. No escriba comentarios para tener m\u00e1s l\u00edneas de c\u00f3digo o para documentar su c\u00f3digo. Escriba comentarios cuando tenga sentido escribirlos, es decir, para impedir que otro desarrollador escriba el mismo error. En general, los comentarios ayudan a escribir un c\u00f3digo limpio y le permiten comprender su c\u00f3digo en el futuro. <\/p>\n\n Consejo de acci\u00f3n: utilice anotaciones o etiquetas en el c\u00f3digo. Varios lenguajes de programaci\u00f3n definen especificaciones para los comentarios. JavaScript utiliza el JSDoc as\u00ed como Java utiliza Javadoc. Muchas herramientas de generaci\u00f3n de documentaci\u00f3n son compatibles con estos sistemas de comentario de c\u00f3digo. <\/strong><\/p>\n\n Muchos desarrolladores, especialmente los principiantes, cometen el error de codificar o escribir todo en una sola l\u00ednea y rara vez prueban los espacios en blanco adecuados, los saltos de l\u00ednea o la sangr\u00eda en su c\u00f3digo. Su c\u00f3digo se volver\u00e1 desordenado y dif\u00edcil de mantener si comete el mismo error. Lo m\u00e1s probable es que otros desarrolladores entren en contacto con su c\u00f3digo y tengan que trabajar con \u00e9l. Les har\u00e1 perder el tiempo porque tendr\u00e1n que intentar leer y comprender el desordenado c\u00f3digo. Por lo tanto, preste atenci\u00f3n al estilo de formato de su c\u00f3digo. El estilo de codificaci\u00f3n y formateo suele afectar a la mantenibilidad de su c\u00f3digo. Pero, con un estilo de formateo adecuado, ahorrar\u00e1 tiempo y energ\u00eda a la hora de realizar cambios en el c\u00f3digo. Aseg\u00farese de que su c\u00f3digo tiene una sangr\u00eda, saltos de l\u00ednea y espacio aut\u00e9nticos para que sea legible y limpio para sus clientes y compa\u00f1eros desarrolladores. <\/p>\n\n Consejo de acci\u00f3n: Aseg\u00farese de aplicar sangr\u00edas coherentes a su c\u00f3digo mientras escribe. Utilice la agrupaci\u00f3n de c\u00f3digo porque algunas tareas requieren unas pocas l\u00edneas de c\u00f3digo, y es mejor mantener estas tareas dentro de bloques separados de c\u00f3digo con algunos espacios entre ellos. <\/strong><\/p>\n\n El principio de responsabilidad \u00fanica establece que cada m\u00f3dulo, clase o funci\u00f3n debe tener una responsabilidad y un \u00fanico prop\u00f3sito. Por lo tanto, cuando se produzca un cambio en esa tarea, s\u00f3lo deber\u00e1 cambiar esa clase. Las funciones, clases y m\u00e9todos son una forma excelente de ensamblar c\u00f3digo en cualquier lenguaje de programaci\u00f3n. Por lo tanto, cuando escriba c\u00f3digo, procure escribir una funci\u00f3n que comunique su prop\u00f3sito. Muchos principiantes cometen el error de escribir una funci\u00f3n que se encarga de casi todo y realiza muchas tareas. Esto hace que su c\u00f3digo sea m\u00e1s confuso para otros desarrolladores y genera problemas a la hora de corregir errores. Tenga en cuenta que la escritura de una funci\u00f3n debe ser peque\u00f1a, realizar una sola tarea y hacerla bien. Cuando el c\u00f3digo tiene varias clases, cada una de ellas sigue este principio, lo que significa que el c\u00f3digo ser\u00e1 m\u00e1s f\u00e1cil de mantener y de entender. Adem\u00e1s, con el principio de responsabilidad \u00fanica en vigor, es f\u00e1cil para los nuevos desarrolladores a\u00f1adir actualizaciones, y probar y escribir casos es m\u00e1s sencillo. <\/p>\n\n Consejo de acci\u00f3n: como su nombre indica, cada m\u00f3dulo o funci\u00f3n debe tener un \u00fanico prop\u00f3sito y responsabilidad. Por lo tanto, escriba clases, funciones o m\u00e9todos con un solo trabajo y una sola raz\u00f3n para cambiar. No querr\u00e1 objetos que tengan muchas responsabilidades y comportamientos no asociados. <\/strong><\/p>\n\n Sin dise\u00f1o ni requisitos, la programaci\u00f3n es el arte de a\u00f1adir errores a un archivo de texto vac\u00edo. Existen varios modelos y arquitecturas que puede utilizar para crear sus proyectos. Aseg\u00farese de seleccionar la correcta y no la mejor. Elegir la arquitectura adecuada crea una base s\u00f3lida para el proyecto y aumenta el rendimiento del software. Una arquitectura adecuada permite un mejor mantenimiento del c\u00f3digo, ya que la estructura del c\u00f3digo es conocida y visible, lo que facilita la localizaci\u00f3n de errores y anomal\u00edas. Adem\u00e1s, una arquitectura adecuada le proporciona un enfoque para organizar el c\u00f3digo con el fin de encapsular la l\u00f3gica empresarial. A\u00fan as\u00ed, la mantiene separada del mecanismo de entrega. <\/p>\n\n Consejo de acci\u00f3n: Utilice el modelo-vista-controlador (MVC) porque le ayuda a mantener el c\u00f3digo organizado y dise\u00f1ado para minimizar los esfuerzos de mantenimiento<\/strong>.<\/p>\n\n Este es un h\u00e1bito con el que la mayor\u00eda de los programadores luchan de vez en cuando. Lo que suele ocurrir es que desea optimizar un trozo de c\u00f3digo, as\u00ed que lo comenta y hace una reescritura justo debajo. Aunque funciona, mantiene el c\u00f3digo antiguo ah\u00ed por si acaso. Poco a poco, acumula un mont\u00f3n de bloques de c\u00f3digo comentados que son irrelevantes pero que desordenan sus archivos fuente. El c\u00f3digo in\u00fatil ralentiza la adici\u00f3n de nuevas caracter\u00edsticas al c\u00f3digo y puede afectarle directamente. Aseg\u00farese de pensarlo bien antes de eliminar este c\u00f3digo no deseado. Cuando trabaje en un nuevo proyecto, aseg\u00farese de que puede diferenciar entre el c\u00f3digo que funciona y el c\u00f3digo innecesario, porque el c\u00f3digo no utilizado crea m\u00e1s confusi\u00f3n en el c\u00f3digo. Adem\u00e1s, el mantenimiento se convierte en una carga; al conservar el c\u00f3digo redundante, fusionar los cambios en la rama principal se vuelve m\u00e1s dif\u00edcil porque hay m\u00e1s c\u00f3digo en el que trabajar. <\/p>\n\n Consejo de acci\u00f3n: La forma m\u00e1s r\u00e1pida de encontrar c\u00f3digo no deseado es utilizar un buen IDE. Elimine el c\u00f3digo no utilizado y los archivos innecesarios. En el caso de una clase innecesaria, se puede aplicar una clase inline o colapsar la jerarqu\u00eda si se utiliza una subclase o superclase. <\/strong><\/p>\n\n Conclusi\u00f3n<\/strong><\/p>\n\n Un buen c\u00f3digo es f\u00e1cil de mantener, permite a\u00f1adir funciones con rapidez y corregir errores en \u00e9l, ya que un c\u00f3digo p\u00e9simo es un castigo para un desarrollador. Cuando escriba c\u00f3digo limpio, h\u00e1gase estas preguntas: \u00bfser\u00e1 esto f\u00e1cil de borrar cuando no lo necesite o podr\u00e1n otros desarrolladores leer este c\u00f3digo? La gente no entender\u00e1 su c\u00f3digo si est\u00e1 profundamente anidado, depende de varios niveles de estado y l\u00edneas de c\u00f3digo a lo largo del c\u00f3digo. Ya sea principiante o profesional, su deber como desarrollador es escribir y construir un c\u00f3digo limpio. Pasos como utilizar el principio de responsabilidad \u00fanica, tener una base de datos de errores, utilizar nombres con significado o la refactorizaci\u00f3n pueden ayudarle a estructurar y escribir un c\u00f3digo limpio. <\/p>\n","protected":false},"excerpt":{"rendered":" El desarrollo de software no consiste \u00fanicamente en aprender un lenguaje de programaci\u00f3n y dise\u00f1ar alg\u00fan tipo de software. Como desarrollador de software, debe escribir software bueno y limpio. El c\u00f3digo limpio no s\u00f3lo funciona, sino que tambi\u00e9n es comprobable, modular, mantenible, f\u00e1cil de comprender y no dif\u00edcil de cambiar. Es algo frecuente en el […]<\/p>\n","protected":false},"author":1,"featured_media":16667,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_themeisle_gutenberg_block_has_review":false,"_jet_sm_ready_style":"","_jet_sm_style":"","_jet_sm_controls_values":"","_jet_sm_fonts_collection":"","_jet_sm_fonts_links":"","footnotes":""},"categories":[86],"tags":[],"writer":[],"class_list":["post-19704","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sin-categorizar"],"_links":{"self":[{"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/posts\/19704","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/comments?post=19704"}],"version-history":[{"count":1,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/posts\/19704\/revisions"}],"predecessor-version":[{"id":19706,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/posts\/19704\/revisions\/19706"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/media\/16667"}],"wp:attachment":[{"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/media?parent=19704"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/categories?post=19704"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/tags?post=19704"},{"taxonomy":"writer","embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/writer?post=19704"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
![\"\"](\"https:\/\/lh3.googleusercontent.com\/q7hhB5MYM8Q2tXahUby-nKpjvU6bhCLNkZRlWrVDuSkHVGUVdNbMTgZx6JG6FAarvuqz0VDL57IlJsoc7QJ1-_4bewupZUOT9N2yWU5OqwTE0DcfD-0dBMH9rVoBv8hUPPbuh5OjBbMCoyKImTEe2w\")
\n
![\"\"](\"https:\/\/lh6.googleusercontent.com\/yP0KqKhbubuoqfkLSc5hHOLExOWFvnnF5xWT_vqILkuSqrAxlivbFvaUv-u0ga-BoQACfy-aru4w_RCIgzSlFUTiLKDprj6L4OUFpXMdksTqsg-JkHTvgk7YUeKL39HeCFMW986-p5ZmURY4B5s65A\")
\n
![\"\"](\"https:\/\/lh6.googleusercontent.com\/C3N1OIpuZw8sJG13O9JwcyM0mIy_KY-NBGHZpTN8eZ5J5mYrJugCxwW3BoAC3TjsAErQUAKHByE3Ybo2DW01h7v1nfDPBL0F-2SON1bd4Fgo3UFNh5SUo3J2m-byiUJZMYtbEla3PmPsvxVG8aIH6A\")
\n
![\"\"](\"https:\/\/lh5.googleusercontent.com\/Td-UcnlvYHL-niP5OvDzGZ-EYjh7t3FOxeQ0WJdcHVKtI__F3TuFcn1ukgR3blEUE15NMatHay5SauUNLcEOpVE68eNZTfir_36_b-YFw-c8FdJcLlj69p499b2J9noLMjHhBfjqcc64k8CFrA6dGA\")
\n
![\"\"](\"https:\/\/lh4.googleusercontent.com\/Zht9gYzrqhGhq3nR5w3sp5iqJ4qC4HI8dw5MciDtTEIg-5FccBfsZSaawugtCIyIa0s2iA36_uxzNbSptBePkKsVhYcHLvgHPbXJRoxDeO3fwxASqUD2GK1jdCTvY1vEh8xp9TGms2l0QzyQMGXw0g\")
\n
\n
![\"\"](\"https:\/\/lh3.googleusercontent.com\/ng952CYJt8cV0rG2qLJnU-RjoSahihzZJvGJL783jfGm1S-c2WEsoYI08qvOsmqgJo4yVIhmjID-y4DHZ5tMuf3PmeFOhqo5dZfCaUqCy7-r-LseZUO3kCXLv8geHjaJ9Gel7S0vQ5J3NQGvHr1rRg\")
\n
![\"\"](\"https:\/\/lh5.googleusercontent.com\/vid7J0VSXmIX6Ckiy73F06o57Hb-L2FdP_G5eMaqUY0J1RDgoiE8EJIRITC-Q1XDuE_QAw9Xc3r0u-oyAJ4pcvm16WXfMOLUxWCO80Xtc3XLQPxKnhUm7OeUz6-NXLw0kbsY2VxMY84pywf93_yg4w\")
\n
![\"\"](\"https:\/\/lh6.googleusercontent.com\/rBHqwQ3LEAispMHtr3L4zIfGk7-yGd7Ph2Ul6c5RtqjdELW9DyUq2cC8PYtX97-UzkSi8IV1V3LJBM9NkRnkygkqaF5Yk_usQDAoP56q_L9tJnK3jNh7wPFNXYK368ucAUxTeyQgnsiEE6wyswA5zQ\")
\n
![\"\"](\"https:\/\/lh5.googleusercontent.com\/Gd-5T8ugAd1uHtlT1NBcGUuUhQEu3pOB9LhD8sNJd-EoEZG7gJ26J9c2Phx22XAW4B3tvNVMwyJ4ExCyx_6h18hDWkPFIKAiuOzUmAdws03GqzeZfT5DGwGLcUIYKH_OqfqJztIK0CgjholI4np7cA\")
\n
![\"\"](\"https:\/\/lh5.googleusercontent.com\/NUKQJjhIsLPi2WQvhBLDwfQ-s8hgNSUKmduiaxlcvStimo6zwh5ww-Snr2Z5T4gO9WC891BJF90UkjgClGQVKQZMqtUdZ7Ll9m0eFpI7-FgvchkFogHeU7NjWYsINEMja8kYYysDkHovol9DjGMq4w\")
\n
![\"\"](\"https:\/\/lh3.googleusercontent.com\/cX-HeQv_V95io-fSgQUQk92AGI7gfQeD4Ks6ZTCgAA8kekeDR0uXCETkJdkgV8lCInp2z5jjRZKf_1465foQUyiNSjmjZm8sJQ7caQicpWig799XbSgAaJdesB9zAvxmuRnd6fuB-PwmvUUT3Sq5Zw\")