{"id":19692,"date":"2023-07-19T12:28:14","date_gmt":"2023-07-19T12:28:14","guid":{"rendered":"https:\/\/devologyx.io\/codigo-limpio-un-manual-de-artesania-agil\/"},"modified":"2024-10-31T17:46:28","modified_gmt":"2024-10-31T17:46:28","slug":"codigo-limpio-un-manual-de-artesania-agil","status":"publish","type":"post","link":"https:\/\/devologyx.io\/es\/codigo-limpio-un-manual-de-artesania-agil\/","title":{"rendered":"C\u00d3DIGO LIMPIO – UN MANUAL DE ARTESAN\u00cdA \u00c1GIL"},"content":{"rendered":"\n
\"\"<\/figure>\n\n

Un mal c\u00f3digo puede funcionar. Pero si el c\u00f3digo no es limpio, puede poner de rodillas a una empresa de desarrollo de software. En todo el mundo se pierden recursos extraordinarios por culpa de un c\u00f3digo mal dise\u00f1ado. Pero no tiene por qu\u00e9 ser as\u00ed. En agosto de 2008, el aclamado experto en software Robert C Martin present\u00f3 un exhaustivo libro titulado C\u00f3digo limpio. El libro le inculca los valores fundamentales de un artesano del software y enfoques para dise\u00f1ar un c\u00f3digo limpio y convertirle en un mejor programador. <\/p>\n\n

\u00bfC\u00d3MO NOS HA AYUDADO ESTE LIBRO?<\/strong><\/p>\n\n

Este libro nos ayud\u00f3 a comprender que convertirnos en mejores artesanos del software y escribir c\u00f3digo limpio es lo que debemos hacer para considerarnos profesionales. El c\u00f3digo limpio arroja luz sobre las pruebas unitarias, el formateo, la depuraci\u00f3n y la utilizaci\u00f3n de nombres descriptivos, que nos ayudan a escribir un c\u00f3digo m\u00e1s limpio y robusto para nuestros clientes. Escribir c\u00f3digo limpio es una cuesti\u00f3n de h\u00e1bito personal y mucho de habilidad. Con el tiempo, tendr\u00e1 que crecer a trav\u00e9s de la experiencia y el conocimiento para escribir c\u00f3digo limpio. <\/p>\n\n

EL LIBRO EXPLICADO EN MENOS DE 60 SEGUNDOS<\/strong><\/p>\n\n

El autor hace hincapi\u00e9 en que las funciones deben ser peque\u00f1as, realizar una \u00fanica tarea y tener nombres descriptivos. Sostiene que si una funci\u00f3n requiere muchos argumentos de configuraci\u00f3n, considere integrarlos en una \u00fanica variable de opciones de configuraci\u00f3n. <\/p>\n\n

El libro hace hincapi\u00e9 en que los desarrolladores se atengan al principio de responsabilidad \u00fanica, que establece que una clase o m\u00f3dulo debe tener una sola raz\u00f3n para cambiar. Este principio nos dio una definici\u00f3n de responsabilidad y directrices para el tama\u00f1o de las clases. Las clases deben tener una sola responsabilidad y una sola raz\u00f3n para cambiar. <\/p>\n\n

LAS TRES MEJORES CITAS<\/strong><\/p>\n\n

\u00abEl c\u00f3digo sin pruebas no es limpio. Por muy elegante que sea, por muy legible y accesible que sea, es impuro si no tiene pruebas\u00bb.<\/p>\n\n

\u00abTodo sistema se construye a partir de un lenguaje espec\u00edfico del dominio dise\u00f1ado por los programadores para describir ese sistema. Las funciones son los verbos de ese lenguaje y las clases son los sustantivos\u00bb.<\/p>\n\n

\u00abLa gesti\u00f3n de errores es importante, pero si oscurece la l\u00f3gica, est\u00e1 mal\u00bb.<\/p>\n\n

\"\"<\/figure>\n\n

RES\u00daMENES Y NOTAS DE LIBROS<\/strong><\/p>\n\n

Cap\u00edtulo uno: C\u00f3digo limpio<\/strong><\/p>\n\n

El c\u00f3digo limpio importa: un c\u00f3digo incorrecto acabar\u00e1 por hundir una empresa porque, a mayor desarrollo, la productividad se acerca progresivamente a cero.<\/p>\n\n

El coste total de poseer un c\u00f3digo desordenado aumenta con el tiempo. Cuanto m\u00e1s desordenado se vuelve el c\u00f3digo, menos posibilidades hay de limpiarlo. La productividad del equipo disminuye a medida que crece el desorden porque est\u00e1n bajo presi\u00f3n para cumplir un plazo o quieren aumentar la productividad. <\/p>\n\n

Reconstruir un sistema desde cero consume tiempo y recursos. La refactorizaci\u00f3n y las mejoras graduales suelen ser las mejores opciones a tomar. Mantener limpio su c\u00f3digo es rentable y una cuesti\u00f3n de supervivencia profesional. <\/p>\n\n

Pasar\u00eda meses intentando realizar una tarea que s\u00f3lo le habr\u00eda llevado horas en c\u00f3digo desordenado. El buen c\u00f3digo pudre r\u00e1pidamente el c\u00f3digo err\u00f3neo porque el cambio de requisitos en los planteamientos frustra el dise\u00f1o original. <\/p>\n\n

El c\u00f3digo limpio est\u00e1 bien probado y realiza una tarea con eficacia, ya que el c\u00f3digo p\u00e9simo suele hacer demasiadas cosas por negligencia.<\/p>\n\n

Los c\u00f3digos desordenados ralentizan a los desarrolladores, aunque todos se sienten presionados a hacer un desastre para cumplir los plazos. Por lo general, no cumplir\u00e1 el plazo haciendo un desastre. La \u00fanica forma de cumplir el plazo es mantener un c\u00f3digo limpio. <\/p>\n\n

Cita favorita del cap\u00edtulo: \u00abEscribir c\u00f3digo limpio es lo que debe hacer para llamarse profesional. No hay excusa razonable para hacer algo que no sea lo mejor posible\u00bb.<\/em><\/strong><\/p>\n\n

Cap\u00edtulo dos: Nombres significativos<\/strong><\/p>\n\n

No es exigente comentar que los nombres deben revelar su prop\u00f3sito. Seleccionar buenos nombres consume tiempo pero ahorra m\u00e1s de lo que cuesta. Cuide los nombres elegidos y c\u00e1mbielos cuando encuentre otros mejores. <\/p>\n\n

Elegir un buen nombre es complejo, y el nombre de una funci\u00f3n o variable debe explicar qu\u00e9 es, c\u00f3mo se utiliza y por qu\u00e9 existe. Si un nombre requiere un comentario, no revela su intenci\u00f3n. <\/p>\n\n

Debe evitar dejar pistas falsas que oculten el significado del c\u00f3digo. Evite las palabras cuyo significado establecido difiera del que usted pretende darle. <\/p>\n\n

Evite utilizar abreviaturas en los nombres de las funciones y en los nombres de las variables de un solo car\u00e1cter, excepto en el caso de nombres de uso com\u00fan como \u00abi\u00bb para la variable contador de un bucle.<\/p>\n\n

Las variables deben ser pronunciables para que pueda hablar de ellas y decirlas en voz alta. S\u00f3lo podr\u00e1 hablar de ellas con sus compa\u00f1eros de equipo si puede pronunciarlas. <\/p>\n\n

Los nombres de una sola letra y las constantes num\u00e9ricas tienen un problema espec\u00edfico. Cuesta trabajo localizarlos a trav\u00e9s de un cuerpo de texto. Los nombres de una sola letra s\u00f3lo pueden utilizarse como variables locales dentro de m\u00e9todos cortos. <\/p>\n\n

Cita favorita del cap\u00edtulo: \u00abUn nombre largo y descriptivo es mejor que un comentario largo y descriptivo\u00bb.<\/em><\/strong><\/p>\n\n

Cap\u00edtulo 3: Funciones<\/strong><\/p>\n\n

La primera regla de las funciones es que deben ser menores y la segunda es que deben ejecutar una sola tarea. Las funciones deben ser insignificantes hasta el punto de contener estructuras anidadas. Por lo tanto, el nivel de sangr\u00eda de una funci\u00f3n no debe ser superior a uno o dos. Esto facilita la lectura y la comprensi\u00f3n de las funciones. <\/p>\n\n

Las funciones deber\u00edan tener el menor n\u00famero posible de par\u00e1metros. Los par\u00e1metros suelen dificultar la comprensi\u00f3n de las funciones y se encuentran en un nivel inferior de abstracci\u00f3n. Evite el uso de par\u00e1metros lo mejor que pueda introduciendo clases ayudantes abstractas o convirtiendo los argumentos en variables miembro. <\/p>\n\n

Para asegurarse de que sus funciones realizan una tarea, debe asegurarse de que las sentencias dentro de sus funciones est\u00e1n todas al mismo nivel de abstracci\u00f3n.<\/p>\n\n

Utilice nombres significativos para etiquetar sus funciones. Los nombres descriptivos explican lo que hace una funci\u00f3n. Cuanto m\u00e1s peque\u00f1a y centrada sea una funci\u00f3n, m\u00e1s f\u00e1cil ser\u00e1 elegir un nombre descriptivo. <\/p>\n\n

Cita favorita del cap\u00edtulo: \u00abSabes que est\u00e1s trabajando en c\u00f3digo limpio cuando cada rutina resulta ser m\u00e1s o menos lo que esperabas\u00bb.<\/em><\/strong><\/p>\n\n

Cap\u00edtulo 4: Comentarios<\/strong><\/p>\n\n

\"\"<\/figure>\n\n

El uso real de los comentarios compensa su fracaso a la hora de expresarse en c\u00f3digo. Los comentarios son fallos sistem\u00e1ticos. Debe tenerlos porque s\u00f3lo a veces se le ocurre c\u00f3mo describirse sin ellos. <\/p>\n\n

Un c\u00f3digo limpio y expresivo con pocos comentarios es mucho mejor que un c\u00f3digo desordenado y complejo con muchos comentarios. Por lo tanto, dedique tiempo a limpiar el desorden de su c\u00f3digo en lugar de dedicarlo a escribir comentarios que expliquen su desorden. <\/p>\n\n

La mayor\u00eda de los comentarios son muletas y justificaciones de un c\u00f3digo deficiente. Los comentarios pueden evitarse utilizando variables claramente nombradas y extrayendo secciones de c\u00f3digo en funciones claramente nombradas. <\/p>\n\n

No utilice Javadocs por el mero hecho de utilizarlos. Los comentarios que explican qu\u00e9 hace un m\u00e9todo, qu\u00e9 argumentos toma y qu\u00e9 devuelve suelen ser redundantes en el mejor de los casos y enga\u00f1osos en el peor. <\/p>\n\n

Los comentarios deben incluir toda la informaci\u00f3n aplicable y el contexto que necesitar\u00e1 quien los lea. No sea perezoso al escribir los comentarios. <\/p>\n\n

Cita favorita del cap\u00edtulo: \u00abNo comente el c\u00f3digo malo, reescr\u00edbalo\u00bb.<\/em><\/strong><\/p>\n\n

Cap\u00edtulo 5: Formateo<\/strong><\/p>\n\n

Aseg\u00farese de que su c\u00f3digo tiene un formato atractivo. Seleccione un conjunto espec\u00edfico de reglas manejables que controlen el formato de su c\u00f3digo. A continuaci\u00f3n, aplique de forma coherente esas reglas a su c\u00f3digo. Es mejor si dispone de una herramienta para implementar esas reglas de formato. <\/p>\n\n

El formato del c\u00f3digo es esencial. Es demasiado crucial para ser ignorado. No cuente con que los humanos detecten y corrijan manualmente cada error de formato. En su lugar, utilice un formateador de c\u00f3digo y un alineador de c\u00f3digo automatizados. Esto es eficiente y productivo y ahorra tiempo durante las revisiones del c\u00f3digo. <\/p>\n\n

Los archivos fuente deben ser como un art\u00edculo de peri\u00f3dico. El nombre debe ser sencillo pero explicativo. El nombre debe ser suficiente para saber si se encuentra en un m\u00f3dulo adecuado. Las partes superiores de su archivo fuente deben ofrecer conceptos y algoritmos de alto nivel. Despu\u00e9s, los detalles deber\u00edan aumentar a medida que se desciende. <\/p>\n\n

Las variables deben declararse cerca de donde se utilizan. Para funciones peque\u00f1as, esto suele ser al principio de la funci\u00f3n. Incluso para funciones cortas, format\u00e9elas bien en lugar de escribirlas en una sola l\u00ednea. <\/p>\n\n

Cita favorita del cap\u00edtulo: \u00abEl formato del c\u00f3digo es importante. Es demasiado importante como para ignorarlo, y es demasiado importante como para tratarlo religiosamente. El formato del c\u00f3digo tiene que ver con la comunicaci\u00f3n, y la comunicaci\u00f3n es la primera orden del d\u00eda del desarrollador profesional.\u00bb<\/em><\/strong><\/p>\n\n

Cap\u00edtulo 6: Objetos y estructuras de datos<\/strong><\/p>\n\n

Usted mantiene sus variables privadas porque no quiere que nadie m\u00e1s dependa de ellas. Quiere conservar la libertad de cambiar su tipo o implementaci\u00f3n impulsivamente. Muchos desarrolladores a\u00f1aden autom\u00e1ticamente getters y setters a sus objetos, revelando sus variables privadas como si fueran p\u00fablicas. <\/p>\n\n

No a\u00f1ada getters y setters por defecto, sino que proporcione una interfaz abstracta a los datos para que pueda ajustar la implementaci\u00f3n sin pensar en los clientes.<\/p>\n\n

Los objetos ponen sus datos detr\u00e1s de abstracciones y revelan funciones que trabajan sobre esos datos fuera de la vista. Las estructuras de datos exponen sus datos y no tienen funciones significativas. <\/p>\n\n

La Ley de Dem\u00e9ter establece que un m\u00f3dulo no debe conocer las entra\u00f1as del objeto que manipula. Esto significa que un objeto no debe revelar su estructura interna a trav\u00e9s de accesores porque hacerlo es exponer, en lugar de ocultar, su estructura interna. Dado que los objetos ocultan datos y exponen comportamientos, a\u00f1adir nuevos objetos sin cambiar los comportamientos actuales no supone ning\u00fan esfuerzo. Las estructuras de datos revelan datos y no tienen comportamientos inusuales, lo que facilita la adici\u00f3n de nuevos comportamientos a las estructuras de datos existentes. <\/p>\n\n

Cita favorita del cap\u00edtulo: \u00abEn cualquier sistema, a veces querremos la flexibilidad para a\u00f1adir nuevos tipos de datos, por lo que preferimos los objetos para esa parte del sistema. Otras veces querremos la flexibilidad para a\u00f1adir nuevos comportamientos. As\u00ed que preferimos tipos de datos y procedimientos en esa parte del sistema\u00bb.<\/em><\/strong><\/p>\n\n

Cap\u00edtulo 7: Tratamiento de errores<\/strong><\/p>\n\n

La gesti\u00f3n de errores es esencial, y suele haber mucha durante la programaci\u00f3n. Aun as\u00ed, no debe ocultar la intenci\u00f3n principal del c\u00f3digo. Por lo tanto, utilice expectativas en lugar de c\u00f3digos de retorno. <\/p>\n\n

Las excepciones deben ser informativas y proporcionar detalles objetivos, contextuales y del tipo de error para que alguien que reciba el mensaje de error pueda solucionar el problema con eficacia.<\/p>\n\n

Las excepciones definen el \u00e1mbito de su programa. Cuando implementa c\u00f3digo en la parte try de una sentencia try-catch-finally, expresa que la ejecuci\u00f3n puede terminar en cualquier punto y reiniciarse en el catch. <\/p>\n\n

Cuando envuelve las API de terceros en una fina capa de abstracci\u00f3n, resulta m\u00e1s f\u00e1cil cambiar una biblioteca por otra en el futuro y burlarse de la biblioteca durante las pruebas.<\/p>\n\n

Cita favorita del cap\u00edtulo: \u00abEl c\u00f3digo limpio es legible, pero tambi\u00e9n debe ser robusto. No son objetivos contradictorios. Podemos escribir c\u00f3digo limpio robusto si consideramos que la gesti\u00f3n de errores es una preocupaci\u00f3n especial.\u00bb<\/em><\/strong><\/p>\n\n

Cap\u00edtulo 8: L\u00edmites<\/strong><\/p>\n\n

\"\"<\/figure>\n\n

El c\u00f3digo de terceros le ayudar\u00e1 a conseguir m\u00e1s funcionalidad en menos tiempo. No es su trabajo probar el c\u00f3digo de terceros, pero deber\u00eda interesarle escribir pruebas para el c\u00f3digo de terceros que utilice. <\/p>\n\n

Las pruebas de aprendizaje son experimentos precisos que le ayudan a aumentar su comprensi\u00f3n. Las pruebas de aprendizaje confirman que los paquetes de terceros que utiliza funcionan de la forma que usted prev\u00e9. No hay garant\u00edas de que el c\u00f3digo de terceros siga siendo compatible con sus necesidades cuando se combine. <\/p>\n\n

Un buen software se adapta a los cambios sin inversiones significativas y sin tener que volver a trabajar. Cuando utiliza un c\u00f3digo que escapa a su control, debe tener un cuidado excepcional para proteger su inversi\u00f3n y garantizar que los cambios futuros sean manejables. <\/p>\n\n

Los l\u00edmites de terceros se gestionan teniendo unos pocos lugares en el c\u00f3digo que hagan referencia a ellos.<\/p>\n\n

Evite que gran parte de su c\u00f3digo conozca las particularidades de terceros. Es mejor confiar en algo que puede controlar que en algo que no puede controlar. <\/p>\n\n

Cita favorita del cap\u00edtulo: \u00abDebemos evitar que gran parte de nuestro c\u00f3digo conozca detalles de terceros. Es mejor depender de algo que controlas que de algo que no controlas, no sea que te controle a ti\u00bb.<\/em><\/strong><\/p>\n\n

Cap\u00edtulo 9: Pruebas unitarias<\/strong><\/p>\n\n

El desarrollo dirigido por pruebas requiere que escriba pruebas unitarias antes de escribir c\u00f3digo de producci\u00f3n. No puede escribir c\u00f3digo de producci\u00f3n hasta que no haya escrito una prueba unitaria que falle. El c\u00f3digo de prueba debe ser tan limpio como el c\u00f3digo de producci\u00f3n, con limitadas excepciones, normalmente relacionadas con la memoria o la eficiencia. <\/p>\n\n

Aseg\u00farese de mantener sus pruebas limpias o menos; las perder\u00e1. Y en su ausencia, perder\u00e1 lo \u00fanico que mantiene su c\u00f3digo reutilizable, flexible y mantenible. No temer\u00e1 hacer cambios en el c\u00f3digo cuando las pruebas est\u00e9n presentes, pero cada cambio es un error factible sin ellas. <\/p>\n\n

La legibilidad es lo que hace que una prueba sea limpia. La legibilidad puede que sea incluso m\u00e1s esencial en las pruebas unitarias que en el c\u00f3digo de producci\u00f3n. La claridad, la sencillez y la densidad de expresi\u00f3n es lo que hace que las pruebas sean legibles. En una prueba, hay que decir mucho con el menor n\u00famero posible de expresiones. <\/p>\n\n

Normalmente, le gustar\u00eda probar un \u00fanico concepto en cada funci\u00f3n de prueba. No querr\u00e1 funciones de prueba extendidas que vayan probando una cosa diversificada tras otra. <\/p>\n\n

Al igual que el c\u00f3digo de producci\u00f3n, las pruebas tambi\u00e9n son cruciales para la solidez del proyecto. Las pruebas son necesarias porque mejoran y preservan la reutilizaci\u00f3n, el mantenimiento y la flexibilidad del c\u00f3digo. Mantenga las pruebas limpias y procure que sean significativas y breves. Desarrolle API que act\u00faen como un lenguaje espec\u00edfico del dominio que le ayude a escribir pruebas. <\/p>\n\n

Cita favorita del cap\u00edtulo: \u00abLas pruebas deben escribirse en el momento oportuno. Las pruebas unitarias deben escribirse justo antes del c\u00f3digo de producci\u00f3n que las hace pasar\u00bb.<\/em><\/strong><\/p>\n\n

Cap\u00edtulo diez: Clases<\/strong><\/p>\n\n

Las clases deben comenzar con una lista de variables. Las constantes est\u00e1ticas p\u00fablicas deben ir primero, luego las variables est\u00e1ticas privadas, seguidas de las variables de instancia privadas. Ponga las utilidades privadas llamadas por una funci\u00f3n p\u00fablica justo despu\u00e9s. <\/p>\n\n

La primera regla de las clases es que tienen que ser peque\u00f1as. Al igual que las funciones, ser peque\u00f1o es la regla principal para crear clases. Pero la verdadera pregunta es siempre \u00ab\u00bfc\u00f3mo de peque\u00f1as?\u00bb. Con las funciones, usted calcula el tama\u00f1o contando las l\u00edneas f\u00edsicas. Con las clases, se mide el tama\u00f1o contando responsabilidades. <\/p>\n\n

Las clases deben tener un n\u00famero reducido de variables de instancia. Cada m\u00e9todo de una clase debe controlar una o varias de esas variables. Cuantas m\u00e1s variables influya un m\u00e9todo, m\u00e1s cohesionado estar\u00e1 con su clase. <\/p>\n\n

Utilice muchas clases peque\u00f1as en lugar de unas pocas clases grandes en su aplicaci\u00f3n. Esto minimiza la cantidad de informaci\u00f3n que un compa\u00f1ero desarrollador necesitar\u00e1 comprender cuando trabaje en una tarea determinada. <\/p>\n\n

Cita favorita del cap\u00edtulo: \u00abUna clase o m\u00f3dulo debe tener una, y s\u00f3lo una, raz\u00f3n para cambiar\u00bb.<\/em><\/strong><\/p>\n\n

\u00bfC\u00d3MO PUEDE AYUDAR ESTE LIBRO A LOS DESARROLLADORES DE SOFTWARE?<\/strong><\/p>\n\n

\u00abC\u00f3digo limpio\u00bb, de Robert C. Martin, puede ayudar a los desarrolladores de software a mejorar la calidad de su c\u00f3digo. Proporciona consejos pr\u00e1cticos y directrices sobre c\u00f3mo escribir un c\u00f3digo legible, mantenible y eficiente. El libro abarca temas de nomenclatura, comentarios, formato y pruebas, y hace hincapi\u00e9 en la importancia de la sencillez, la claridad y la coherencia en las pr\u00e1cticas de codificaci\u00f3n. Siguiendo los principios descritos en el libro, los desarrolladores pueden reducir la deuda t\u00e9cnica, aumentar la productividad y crear un software m\u00e1s accesible de entender, modificar y ampliar. Proporciona a los programadores de software un enfoque integral de la codificaci\u00f3n que puede ayudarles a mejorar sus habilidades y reducir el coste del mantenimiento. Este libro ayuda a los programadores a escribir c\u00f3digo f\u00e1cil de modificar y refactorizar en el futuro. Es una lectura obligada para cualquier desarrollador de software que desee convertirse en un mejor programador. <\/p>\n","protected":false},"excerpt":{"rendered":"

Un mal c\u00f3digo puede funcionar. Pero si el c\u00f3digo no es limpio, puede poner de rodillas a una empresa de desarrollo de software. En todo el mundo se pierden recursos extraordinarios por culpa de un c\u00f3digo mal dise\u00f1ado. Pero no tiene por qu\u00e9 ser as\u00ed. En agosto de 2008, el aclamado experto en software Robert […]<\/p>\n","protected":false},"author":1,"featured_media":17642,"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":[101],"tags":[],"writer":[],"class_list":["post-19692","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-club-del-libro"],"_links":{"self":[{"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/posts\/19692","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=19692"}],"version-history":[{"count":1,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/posts\/19692\/revisions"}],"predecessor-version":[{"id":19695,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/posts\/19692\/revisions\/19695"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/media\/17642"}],"wp:attachment":[{"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/media?parent=19692"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/categories?post=19692"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/tags?post=19692"},{"taxonomy":"writer","embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/writer?post=19692"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}