{"id":19677,"date":"2023-07-18T14:17:26","date_gmt":"2023-07-18T14:17:26","guid":{"rendered":"https:\/\/devologyx.io\/el-programador-pragmatico\/"},"modified":"2024-10-31T17:44:24","modified_gmt":"2024-10-31T17:44:24","slug":"el-programador-pragmatico","status":"publish","type":"post","link":"https:\/\/devologyx.io\/es\/el-programador-pragmatico\/","title":{"rendered":"EL PROGRAMADOR PRAGM\u00c1TICO"},"content":{"rendered":"\n
\"\"<\/figure>\n\n

El Programador Pragm\u00e1tico es una gu\u00eda h\u00e1bil y pr\u00e1ctica que proporciona una visi\u00f3n y los fundamentos para ser un buen programador, aumentando su especializaci\u00f3n y tecnicidad en el desarrollo de software moderno. El libro se public\u00f3 en octubre de 1999. Andrew Hunt abarca desde temas de responsabilidad personal y desarrollo profesional hasta t\u00e9cnicas de arquitectura para mantener su c\u00f3digo flexible y f\u00e1cil de adaptar y reutilizar. El libro le ense\u00f1ar\u00e1 a luchar contra la podredumbre del software, a evitar la trampa de la duplicaci\u00f3n de conocimientos y a hacer sus desarrollos m\u00e1s precisos con la automatizaci\u00f3n. <\/p>\n\n

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

Este libro nos ayud\u00f3 a entender c\u00f3mo los desarrolladores pueden convertirse en mejores programadores comprendiendo los fundamentos b\u00e1sicos necesarios para el \u00e9xito en el desarrollo de software. Demuestra que ser un buen programador no es s\u00f3lo cuesti\u00f3n de habilidades t\u00e9cnicas. Se centra en temas pr\u00e1cticos como el desacoplamiento, la edici\u00f3n de potencia, la depuraci\u00f3n y las pruebas, que nos ayudan a ayudar a los desarrolladores a crear mejor c\u00f3digo para nuestros clientes y a convertirnos en consultores y miembros de equipos de grandes proyectos. El libro nos ayud\u00f3 a comprender c\u00f3mo utilizar nuestra experiencia para tomar decisiones m\u00e1s informadas tanto en nuestra vida profesional como personal. <\/p>\n\n

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

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

El libro utiliza analog\u00edas y peque\u00f1as historias para presentar metodolog\u00edas de desarrollo y advertencias, por ejemplo, la teor\u00eda de las ventanas rotas, la historia de la sopa de piedra o la rana hirviendo. Tambi\u00e9n cuenta con peque\u00f1os ejercicios para practicar sus habilidades de programaci\u00f3n. <\/p>\n\n

El programador pragm\u00e1tico explica que los defectos del software se manifiestan de varias formas, desde requisitos mal entendidos hasta errores de codificaci\u00f3n. Por desgracia, los sistemas inform\u00e1ticos modernos siguen limit\u00e1ndose a hacer lo que se les dice y no lo que se quiere que hagan. <\/p>\n\n

Seg\u00fan el libro, nadie escribe software perfecto. As\u00ed que se da por hecho que la depuraci\u00f3n consumir\u00e1 una parte importante de su d\u00eda. La depuraci\u00f3n es un tema sensible y emocional para muchos desarrolladores. <\/p>\n\n

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

\u00abLas herramientas amplifican su talento. Cuanto mejores sean sus herramientas y mejor sepa utilizarlas, m\u00e1s productivo podr\u00e1 ser\u00bb.<\/em><\/p>\n\n

\u00abLa mayor de todas las debilidades es el miedo a parecer d\u00e9bil\u00bb.<\/em><\/p>\n\n

\u00abEl editor ser\u00e1 una extensi\u00f3n de su mano; las teclas cantar\u00e1n mientras cortan el texto y el pensamiento\u00bb.<\/em><\/p>\n\n

RESUMEN Y NOTAS DEL LIBRO<\/strong><\/p>\n\n

Cap\u00edtulo uno: Una filosof\u00eda pragm\u00e1tica<\/strong><\/p>\n\n

    \n
  1. El gato se comi\u00f3 mi c\u00f3digo fuente<\/strong><\/li>\n<\/ol>\n\n

    Asuma su responsabilidad: <\/strong>La responsabilidad es algo que usted acepta activamente; se dedica a garantizar que algo se ejecuta correctamente. Sin embargo, no tiene necesariamente el control directo sobre todos los aspectos. Tiene derecho a no asumir la responsabilidad de una situaci\u00f3n inimaginable o rodeada de grandes riesgos. Cuando acepte la responsabilidad de una situaci\u00f3n, tenga la humildad de rendir cuentas. Todo el mundo comete errores. Por lo tanto, cuando cometa uno, adm\u00edtalo honestamente y trate de encontrar opciones. <\/p>\n\n

      \n
    1. Entrop\u00eda del software<\/strong><\/li>\n<\/ol>\n\n

      Tener una ventana rota sin reparar en casa durante un periodo considerable infunde en los ocupantes de la casa una sensaci\u00f3n de abandono que acaba creando m\u00e1s da\u00f1os y ruina. Lo mismo se aplica al software; un trozo de c\u00f3digo p\u00e9simo puede provocar m\u00e1s da\u00f1os si no se repara lo suficientemente pronto. Por lo tanto, no conviva con un c\u00f3digo destructivo. Arr\u00e9glelo en cuanto descubra un fallo. Tome alguna medida y muestre iniciativa para evitar m\u00e1s da\u00f1os y demostrar que est\u00e1 al tanto de la situaci\u00f3n. <\/p>\n\n

        \n
      1. Software suficientemente bueno<\/strong><\/li>\n<\/ol>\n\n

        Suficientemente bueno no implica un c\u00f3digo descuidado o mal producido. Todos los sistemas deben cumplir los requisitos de sus usuarios para tener \u00e9xito. Puede someterse a escribir software lo suficientemente bueno para sus usuarios, futuros mantenedores y su tranquilidad. Escribir software suficientemente bueno le hace m\u00e1s productivo y a sus usuarios m\u00e1s felices. Construir c\u00f3digo suficientemente bueno simplemente aboga por que se permita a los usuarios participar en el proceso de decidir si lo que usted ha producido es suficientemente bueno. <\/p>\n\n

        Cuando construya un c\u00f3digo suficientemente bueno, sepa cu\u00e1ndo parar. No arruine un programa sobresaliente con un exceso de embellecimiento y refinamiento. Siga adelante y deje que su c\u00f3digo se mantenga por s\u00ed mismo durante un tiempo. Puede que no sea perfecto. No se preocupe: nunca podr\u00e1 ser perfecto. Un buen software ahora es mejor que un software ideal dentro de un a\u00f1o. <\/p>\n\n

        \n Cita favorita del cap\u00edtulo: \u00ab<\/em>\n<\/strong>\n Un gran software hoy es a menudo preferible a un software perfecto ma\u00f1ana\u00bb.<\/em>\n<\/strong><\/p>\n\n

        Cap\u00edtulo dos: Un enfoque pragm\u00e1tico<\/strong><\/p>\n\n

          \n
        1. Los males de la duplicaci\u00f3n<\/strong><\/li>\n<\/ol>\n\n

          Como programador, usted recopila, organiza, mantiene y aprovecha los conocimientos. Por desgracia, el aprendizaje no es constante ni fijo y cambia r\u00e1pidamente. Su comprensi\u00f3n de un requisito puede cambiar tras una reuni\u00f3n con el cliente. Esto significa que usted pasa la mayor parte de su tiempo intentando mantener el c\u00f3digo a diario. La mayor\u00eda de la gente piensa que el mantenimiento comienza cuando se lanza una aplicaci\u00f3n, que el mantenimiento significa corregir errores y mejorar caracter\u00edsticas. Esas personas se equivocan. El mantenimiento no es una actividad separada, sino una parte del proceso de desarrollo, porque los nuevos requisitos llegan a medida que usted dise\u00f1a el c\u00f3digo. <\/p>\n\n

          La \u00fanica manera de desarrollar software de forma fiable y de hacer que sus desarrollos sean m\u00e1s f\u00e1ciles de entender y mantener es seguir el principio DRY (Don’t Repeat Yourself<\/strong>): Cada pieza de conocimiento debe tener una representaci\u00f3n \u00fanica, inequ\u00edvoca y autorizada dentro de un sistema.<\/p>\n\n

          La mayor\u00eda de las duplicidades que observamos pertenecen a una de las siguientes categor\u00edas: <\/p>\n\n

            \n
          • Duplicaci\u00f3n impuesta. <\/strong>Siente que no tiene elecci\u00f3n: el entorno parece exigirle una r\u00e9plica.<\/li>\n\n\n\n
          • Duplicaci\u00f3n involuntaria.<\/strong> No se da cuenta de que est\u00e1 duplicando informaci\u00f3n.<\/li>\n\n\n\n
          • Duplicaci\u00f3n impaciente.<\/strong> Uno se vuelve perezoso y duplica porque parece m\u00e1s f\u00e1cil.<\/li>\n\n\n\n
          • Duplicaci\u00f3n entre desarrolladores.<\/strong> Varias personas de un equipo duplican una informaci\u00f3n y no se dan cuenta.<\/li>\n<\/ul>\n\n
              \n
            1. Reversibilidad.<\/strong><\/li>\n<\/ol>\n\n

              Los cambios no tienen por qu\u00e9 ser extremos ni tan inmediatos. Pero a medida que pasa el tiempo y su proyecto avanza, puede encontrarse atrapado en una posici\u00f3n insostenible. El equipo del proyecto se compromete con un objetivo m\u00e1s peque\u00f1o con decisiones cr\u00edticas, creando una versi\u00f3n de la realidad con menos opciones. El problema es que las decisiones cr\u00edticas no son f\u00e1cilmente reversibles. <\/p>\n\n

              Nada es para siempre, y si conf\u00eda firmemente en alg\u00fan hecho, casi puede garantizar que cambiar\u00e1. Planifique la reversibilidad porque ninguna decisi\u00f3n es definitiva. Aspire a un c\u00f3digo, una arquitectura y una integraci\u00f3n de proveedores flexibles. <\/p>\n\n

              Si se atiene a recomendaciones como el principio DRY, el desacoplamiento y el uso de metadatos, no tendr\u00e1 que tomar muchas decisiones cr\u00edticas e irreversibles.<\/p>\n\n

                \n
              1. Balas trazadoras<\/strong><\/li>\n<\/ol>\n\n

                Las balas trazadoras le ayudar\u00e1n a encontrar r\u00e1pidamente su objetivo en circunstancias reales y le proporcionar\u00e1n informaci\u00f3n a usted y a sus usuarios. Un c\u00f3digo trazador puede ser una \u00fanica caracter\u00edstica implementada de extremo a extremo en todas las capas. Un c\u00f3digo trazador llega r\u00e1pido al objetivo y proporciona una retroalimentaci\u00f3n inmediata. Y desde un punto de vista pr\u00e1ctico, son una soluci\u00f3n relativamente barata. Para conseguir el mismo efecto en el c\u00f3digo, buscamos algo que nos lleve de un requisito a alg\u00fan aspecto del sistema final de forma r\u00e1pida, visible y repetida. <\/p>\n\n

                Ventajas<\/strong><\/p>\n\n

                  \n
                • Dispone de una plataforma de integraci\u00f3n.<\/li>\n\n\n\n
                • Tendr\u00e1 una mejor sensaci\u00f3n del progreso.<\/li>\n\n\n\n
                • Los usuarios pueden ver algo que funciona desde el principio.<\/li>\n\n\n\n
                • Ayude a construir una estructura en la que trabajar.<\/li>\n<\/ul>\n\n

                  C\u00f3digo trazador frente a prototipos<\/strong><\/p>\n\n

                  Podr\u00eda pensar que el concepto de c\u00f3digo trazador no es m\u00e1s que la creaci\u00f3n de prototipos; hay una diferencia. Al crear prototipos, su objetivo es explorar aspectos concretos del sistema final. Con un prototipo real, desechar\u00e1 todo lo que haya trucado al probar el concepto y lo recodificar\u00e1 adecuadamente utilizando las lecciones aprendidas. El enfoque del c\u00f3digo trazador aborda un problema diferente. Necesita saber c\u00f3mo funciona la aplicaci\u00f3n en su conjunto. Quiere mostrar a sus usuarios c\u00f3mo funcionar\u00e1n las interacciones en la pr\u00e1ctica y dar a sus desarrolladores un esqueleto arquitect\u00f3nico en el que colgar el c\u00f3digo. <\/p>\n\n

                  Cita favorita del cap\u00edtulo: \u00abNada es m\u00e1s peligroso que una idea si es la \u00fanica que tienes\u00bb. <\/em><\/strong><\/p>\n\n

                  Cap\u00edtulo 3: Las herramientas b\u00e1sicas<\/strong><\/p>\n\n

                  \"\"<\/figure>\n\n
                    \n
                  1. El poder del texto sin formato<\/strong><\/li>\n<\/ol>\n\n

                    Como programador pragm\u00e1tico, su material de base es el conocimiento. Usted re\u00fane los requisitos como conocimiento y luego los expresa en sus dise\u00f1os, implementaciones, pruebas y documentos. El mejor formato para almacenar conocimientos es el texto sin formato. <\/p>\n\n

                    \u00bfQu\u00e9 es el texto sin formato?<\/p>\n\n

                    El texto sin formato comprende caracteres imprimibles para que la gente pueda leerlo y entenderlo directamente. Con el texto sin formato, usted se da la posibilidad de manipular el conocimiento tanto manual como program\u00e1ticamente utilizando pr\u00e1cticamente todas las herramientas a su disposici\u00f3n. <\/p>\n\n

                      \n
                    1. Juegos de conchas<\/strong><\/li>\n<\/ol>\n\n

                      Todo carpintero necesita un banco de trabajo adecuado, s\u00f3lido y fiable en alg\u00fan lugar para sujetar las piezas a una altura conveniente mientras trabaja en ellas. <\/p>\n\n

                      Como programador que manipula archivos de texto, su banco de trabajo es el int\u00e9rprete de comandos. A trav\u00e9s del prompt del shell, puede invocar todo su repertorio de herramientas. El prompt del shell le permitir\u00e1 lanzar aplicaciones, depuradores, navegadores, editores y utilidades. Podr\u00e1 buscar archivos, consultar el estado del sistema y filtrar la salida. Programando el int\u00e9rprete de comandos, podr\u00e1 construir macrocomandos multiplexados para actividades que realice con frecuencia. <\/p>\n\n

                      Utilidades Shell y sistemas Windows<\/strong><\/p>\n\n

                      Aunque los shells de comandos que proporcionan los sistemas Windows est\u00e1n mejorando gradualmente, las utilidades de l\u00ednea de comandos de Windows siguen siendo inferiores a sus hom\u00f3logas de Linux\/Unix. Sin embargo, no todo est\u00e1 perdido. <\/p>\n\n

                      Cygnus Solutions dispone de un paquete llamado Cygwin. Adem\u00e1s de proporcionar una capa de compatibilidad Linux\/Unix para Windows, Cygwin viene con una colecci\u00f3n de m\u00e1s de 120 utilidades Unix, incluyendo las favoritas como 1s, grep y find. Las utilidades y bibliotecas pueden descargarse y utilizarse gratuitamente, pero lea su licencia. La distribuci\u00f3n Cygwin viene con el shell Bash. <\/p>\n\n

                        \n
                      1. Edici\u00f3n de potencia<\/strong><\/li>\n<\/ol>\n\n

                        Las herramientas son una extensi\u00f3n de su mano. Esto se aplica a los editores m\u00e1s que a cualquier otra herramienta de software. Elija un editor que le permita manipular el texto con el menor esfuerzo posible, porque el texto es la materia prima principal de la programaci\u00f3n. <\/p>\n\n

                        Un editor<\/strong><\/p>\n\n

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

                        Es mejor conocer muy bien un editor y utilizarlo para todas las tareas de edici\u00f3n: c\u00f3digo, documentaci\u00f3n, notas, administraci\u00f3n del sistema, etc. Con m\u00faltiples editores, se enfrenta a un posible caos de confusi\u00f3n moderno. Puede que tenga que utilizar el editor integrado en el IDE de cada idioma para codificar, un producto ofim\u00e1tico todo en uno para la documentaci\u00f3n y tal vez un editor integrado diferente para enviar correos electr\u00f3nicos. Incluso las pulsaciones de teclas que utiliza para editar l\u00edneas de comandos en el shell pueden diferir. Es dif\u00edcil ser competente en cualquiera de estos entornos si tiene un conjunto diferente de convenciones y comandos de edici\u00f3n en cada uno de ellos. <\/p>\n\n

                        Por lo tanto, elija un \u00fanico editor, con\u00f3zcalo en profundidad y util\u00edcelo para todas las tareas de edici\u00f3n. Utilice un \u00fanico editor o conjunto de combinaciones de teclas para todas las actividades de edici\u00f3n de texto. No tendr\u00e1 que pararse a pensar para manipular el texto: las pulsaciones de teclas necesarias ser\u00e1n un reflejo. El editor ser\u00e1 una extensi\u00f3n de su mano, las teclas cantar\u00e1n mientras se abren paso a trav\u00e9s del texto y el pensamiento. Aseg\u00farese de que el editor que elija est\u00e9 disponible en todas las plataformas que utilice. Emacs, vi, CRiSP, Brief y otros est\u00e1n disponibles en varias plataformas, a menudo en versiones GUI y no GUI (pantalla de texto). <\/p>\n\n

                        Caracter\u00edsticas del editor:<\/p>\n\n

                          \n
                        • Configurable<\/li>\n\n\n\n
                        • Extensible<\/li>\n\n\n\n
                        • Programable<\/li>\n<\/ul>\n\n

                          Cita favorita del cap\u00edtulo: \u00abLas herramientas amplifican su talento. Cuanto mejores sean sus herramientas y mejor sepa utilizarlas, m\u00e1s productivo podr\u00e1 ser\u00bb.<\/em><\/strong><\/p>\n\n

                          Cap\u00edtulo 4 La paranoia pragm\u00e1tica<\/strong><\/p>\n\n

                            \n
                          1. Dise\u00f1o por contrato<\/strong><\/li>\n<\/ol>\n\n

                            El concepto de dise\u00f1o por contrato es una t\u00e9cnica sencilla pero poderosa que se centra en documentar y acordar los derechos y responsabilidades de los m\u00f3dulos de software para garantizar la correcci\u00f3n del programa. Un programa correcto no hace ni m\u00e1s ni menos de lo que afirma hacer. Documentar y verificar esa afirmaci\u00f3n es el coraz\u00f3n del dise\u00f1o por contrato. Cada funci\u00f3n y m\u00e9todo de un sistema de software hace algo. Antes de comenzar, la rutina puede tener algunas expectativas sobre el estado del mundo. Las expectativas y afirmaciones incluyen; <\/p>\n\n

                              \n
                            • Precondiciones: \u00bfQu\u00e9 debe ser v\u00e1lido para que se llame a la rutina?<\/li>\n\n\n\n
                            • Invariantes de clase: Una clase garantiza que esta condici\u00f3n sea siempre real desde la perspectiva de quien llama.<\/li>\n\n\n\n
                            • Postcondiciones: El hecho de que la rutina tenga una postcondici\u00f3n implica que concluir\u00e1: los bucles infinitos no est\u00e1n permitidos.<\/li>\n<\/ul>\n\n

                              Aplicaci\u00f3n del dise\u00f1o por contrato<\/strong><\/p>\n\n

                              La principal ventaja de utilizar DBC es que obliga a poner en primer plano la cuesti\u00f3n de los requisitos y las garant\u00edas. Enumerar simplemente en el momento del dise\u00f1o cu\u00e1l es el rango del dominio de entrada, las condiciones de contorno y lo que la rutina promete entregar o lo que no promete entregar es un paso de gigante para escribir un software mejor. Cuando no se enuncian estas cosas, entonces se est\u00e1 programando por casualidad y aqu\u00ed es donde empiezan, acaban y fracasan muchos proyectos. En los lenguajes que no admiten DBC en el c\u00f3digo, esto es lo m\u00e1s lejos que se puede llegar, lo que no est\u00e1 tan mal. Al fin y al cabo, DBC es una t\u00e9cnica de dise\u00f1o. <\/p>\n\n

                                \n
                              1. Los programas muertos no mienten<\/strong><\/li>\n<\/ol>\n\n

                                Es f\u00e1cil caer en la mentalidad de \u00abeso no puede ocurrir\u00bb. La mayor\u00eda de ustedes ha escrito c\u00f3digo que no comprobaba que un archivo se cerraba con \u00e9xito o que una sentencia trace se escrib\u00eda como usted esperaba. En igualdad de condiciones, es probable que no lo necesitara, el c\u00f3digo en cuesti\u00f3n no fallar\u00eda en condiciones normales. Pero usted est\u00e1 codificando a la defensiva. Est\u00e1 buscando punteros deshonestos en otras partes de su programa y destrozando la pila. Est\u00e1 comprobando que las versiones cargadas de las bibliotecas compartidas son correctas. <\/p>\n\n

                                Todos los errores le proporcionan informaci\u00f3n. Podr\u00eda convencerse de que el error no puede producirse y optar por ignorarlo. En cambio, un programador pragm\u00e1tico se dice a s\u00ed mismo que algo muy, muy malo ha ocurrido si hay un error. <\/p>\n\n

                                Chocar, no tirar<\/strong><\/p>\n\n

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

                                Una de las ventajas de detectar los problemas lo antes posible es que puede chocar antes.<\/p>\n\n

                                Y muchas veces, estrellar su programa es lo mejor que puede hacer. La alternativa puede ser seguir escribiendo datos corruptos en alguna robusta base de datos o mandar a la lavadora a su vig\u00e9simo centrifugado consecutivo. <\/p>\n\n

                                  \n
                                1. Programaci\u00f3n asertiva<\/strong><\/li>\n<\/ol>\n\n

                                  El recuento no puede ser negativo, la impresi\u00f3n no puede fallar, el registro no puede fallar o esto no puede ocurrir nunca. No practique este tipo de enga\u00f1os, especialmente cuando codifique. Si no puede ocurrir, aplique aserciones para asegurarse de que no ocurrir\u00e1. <\/p>\n\n

                                  Siempre que piense que \u00abeso nunca podr\u00eda ocurrir\u00bb, a\u00f1ada c\u00f3digo para comprobarlo. La forma m\u00e1s sencilla de hacerlo es mediante el uso de aserciones. En la mayor\u00eda de las implementaciones de C y C++, encontrar\u00e1 alg\u00fan tipo de macro assert o assert que comprueba una condici\u00f3n booleana. Estas macros pueden tener un valor incalculable. Las aserciones tambi\u00e9n ayudan a comprobar el funcionamiento de un algoritmo. Digamos que ha escrito un algoritmo inteligente; las aserciones comprobar\u00e1n que funciona. <\/p>\n\n

                                  No aplique aserciones en lugar de la gesti\u00f3n de errores real. Las aserciones comprueban cosas que nunca deber\u00edan ocurrir y aseg\u00farese de que el m\u00e9todo de aserci\u00f3n que utiliza no realiza ning\u00fan efecto secundario que pueda crear nuevos errores. <\/p>\n\n

                                  Deje las afirmaciones en<\/strong><\/p>\n\n

                                  La gente que escribe compiladores y entornos de lenguaje tiene una interpretaci\u00f3n err\u00f3nea de las aserciones muy extendida. Dice as\u00ed: \u00abLas aserciones a\u00f1aden cierta sobrecarga al c\u00f3digo. Como comprueban cosas que nunca deber\u00edan ocurrir, s\u00f3lo se activar\u00e1n por un error en el c\u00f3digo. Una vez que el c\u00f3digo haya sido probado y enviado, desactive las aserciones para que el c\u00f3digo se ejecute m\u00e1s r\u00e1pido\u00bb. <\/p>\n\n

                                  Cita favorita del cap\u00edtulo: \u00abLas aserciones a\u00f1aden cierta sobrecarga al c\u00f3digo. Dado que comprueban cosas que nunca deber\u00edan ocurrir, s\u00f3lo se activar\u00e1n por un error en el c\u00f3digo. Una vez que el c\u00f3digo ha sido probado y enviado, ya no son necesarias y deber\u00edan desactivarse para que el c\u00f3digo se ejecute m\u00e1s r\u00e1pido.\u00bb<\/em><\/strong><\/p>\n\n

                                  Cap\u00edtulo 5: Doblar o romper<\/strong><\/p>\n\n

                                    \n
                                  1. La disociaci\u00f3n y la ley de Dem\u00e9ter<\/strong><\/li>\n<\/ol>\n\n

                                    Organice su c\u00f3digo en m\u00f3dulos y controle la interacci\u00f3n entre ellos. Si un m\u00f3dulo se ve comprometido y tiene que ser sustituido, los dem\u00e1s m\u00f3dulos deben seguir adelante. <\/p>\n\n

                                    Minimizar el acoplamiento<\/p>\n\n

                                    No hay nada malo en tener m\u00f3dulos que se conozcan entre s\u00ed. Sin embargo, debe tener cuidado con cu\u00e1ntos otros m\u00f3dulos interact\u00faa y, lo que es m\u00e1s importante, c\u00f3mo lleg\u00f3 a interactuar con ellos. Cuando pide a un objeto un servicio espec\u00edfico, quiere que el servicio se ejecute en su nombre. No quiere que el objeto le proporcione una entidad tercera con la que tenga que tratar para obtener el servicio requerido. <\/p>\n\n

                                    La ley de Dem\u00e9ter<\/strong><\/p>\n\n

                                    La ley de Dem\u00e9ter para las funciones establece que cualquier m\u00e9todo de un objeto s\u00f3lo debe llamar a procesos que pertenezcan a \u00e9l mismo, a cualquier par\u00e1metro pasado al m\u00e9todo, a cualquier objeto que haya creado y a cualquier objeto compuesto que tenga directamente. La ley de Dem\u00e9ter tiene como objetivo minimizar el acoplamiento entre m\u00f3dulos en un programa determinado; evita que se llegue a un objeto para acceder a los m\u00e9todos de un tercer objeto. Escribir c\u00f3digo \u00abt\u00edmido\u00bb hace honor a la Ley de Dem\u00e9ter y logra su objetivo de minimizar el acoplamiento entre m\u00f3dulos. <\/p>\n\n

                                      \n
                                    1. Metaprogramaci\u00f3n<\/strong><\/li>\n<\/ol>\n\n

                                      Los detalles estropean significativamente su c\u00f3digo perfecto si cambian con frecuencia. Cada vez que tenga que entrar y cambiar el c\u00f3digo para adaptarlo a alg\u00fan cambio en la l\u00f3gica empresarial, en la legislaci\u00f3n o en los gustos del momento de la direcci\u00f3n, corre el riesgo de romper el sistema introduciendo un nuevo fallo. <\/p>\n\n

                                      \u00a1Basta ya de detalles! S\u00e1quelos del c\u00f3digo. De paso, haga que su c\u00f3digo sea altamente configurable y \u00absuave\u00bb. Es decir, f\u00e1cilmente adaptable a los cambios.<\/p>\n\n

                                      Configuraci\u00f3n din\u00e1mica<\/strong><\/p>\n\n

                                      Configure, no integre. Debe hacer que sus sistemas sean altamente configurables. No s\u00f3lo los colores de la pantalla o el texto de los avisos, sino elementos profundamente arraigados como la elecci\u00f3n de algoritmos, productos de bases de datos, tecnolog\u00eda de middleware y estilo de la interfaz de usuario deben aplicarse como opciones de configuraci\u00f3n y no mediante integraci\u00f3n o ingenier\u00eda. <\/p>\n\n

                                      Cu\u00e1ndo configurar<\/strong><\/p>\n\n

                                      Represente sus metadatos de configuraci\u00f3n en texto sin formato; le facilitar\u00e1 mucho la vida. Pero, \u00bfcu\u00e1ndo debe un programa leer esta configuraci\u00f3n? Muchos programas analizan este tipo de cosas s\u00f3lo al iniciarse, lo cual es desafortunado porque se ver\u00e1 obligado a reiniciar la aplicaci\u00f3n cuando necesite cambiar la configuraci\u00f3n. Un enfoque m\u00e1s flexible es escribir programas que recarguen su configuraci\u00f3n mientras se ejecutan. Aunque esta flexibilidad tiene un coste, es m\u00e1s compleja de implementar. <\/p>\n\n

                                      As\u00ed que considere c\u00f3mo utilizar\u00e1n los usuarios su aplicaci\u00f3n: si se trata de un proceso de servidor de larga duraci\u00f3n, querr\u00e1 proporcionar alguna forma de releer y aplicar metadatos mientras el programa se ejecuta. Para una peque\u00f1a aplicaci\u00f3n GUI cliente que se reinicia r\u00e1pidamente, puede que no lo necesite. <\/p>\n\n

                                        \n
                                      1. Acoplamiento temporal<\/strong><\/li>\n<\/ol>\n\n

                                        Aqu\u00ed, el escritor habla del tiempo como un elemento de dise\u00f1o del propio software. Hay dos aspectos del tiempo que son importantes para usted: la concurrencia (cosas que suceden simult\u00e1neamente) y el ordenamiento (las posiciones relativas de las cosas en el tiempo). En el acoplamiento temporal, la concurrencia se llama siempre antes que la ordenaci\u00f3n; s\u00f3lo se puede ejecutar un informe a la vez; despu\u00e9s, hay que esperar a que se redibuje la pantalla antes de recibir el clic del bot\u00f3n. <\/p>\n\n

                                        Cita favorita del cap\u00edtulo: \u00abNing\u00fan genio puede superar la preocupaci\u00f3n por el detalle\u00bb.<\/em><\/strong><\/p>\n\n

                                        Cap\u00edtulo 6: Mientras codifica<\/strong><\/p>\n\n

                                          \n
                                        1. Programar por casualidad<\/strong><\/li>\n<\/ol>\n\n

                                          Hay cientos de trampas esperando para atraparle cada d\u00eda como desarrollador. Recuerde que debe tener cuidado con sacar conclusiones falsas. Evite programar por casualidad, confiando en la suerte y en los \u00e9xitos accidentales, en favor de programar deliberadamente. Cuando programe por casualidad y su c\u00f3digo falle, no sabr\u00e1 por qu\u00e9 fall\u00f3 porque no sab\u00eda por qu\u00e9 funcionaba en primer lugar con las escasas pruebas que realiz\u00f3. <\/p>\n\n

                                          Accidentes de aplicaci\u00f3n<\/strong><\/p>\n\n

                                          Los accidentes de implementaci\u00f3n son cosas que ocurren simplemente porque as\u00ed est\u00e1 escrito el c\u00f3digo. Usted acaba confiando en errores no documentados o en condiciones l\u00edmite. La condici\u00f3n l\u00edmite en la que conf\u00eda puede ser simplemente un accidente. En otras circunstancias (una resoluci\u00f3n de pantalla diferente, quiz\u00e1s), podr\u00eda comportarse de forma diferente. <\/p>\n\n

                                          El comportamiento no documentado puede cambiar con la pr\u00f3xima versi\u00f3n de la biblioteca.<\/p>\n\n

                                          C\u00f3mo programar deliberadamente<\/strong><\/p>\n\n

                                            \n
                                          • No codifique con los ojos vendados.<\/li>\n\n\n\n
                                          • Conf\u00ede s\u00f3lo en cosas fiables. No dependa de accidentes o suposiciones. <\/li>\n\n\n\n
                                          • Documente sus suposiciones.<\/li>\n<\/ul>\n\n
                                              \n
                                            1. Velocidad del algoritmo<\/strong><\/li>\n<\/ol>\n\n

                                              Como programador pragm\u00e1tico, usted calcula los recursos de los algoritmos, como el tiempo, el procesador y la memoria. La mayor\u00eda de los algoritmos no triviales manejan alg\u00fan tipo de entrada variable; el tama\u00f1o de esta entrada repercutir\u00e1 en el algoritmo. Cuanto mayor sea la informaci\u00f3n, mayor ser\u00e1 el tiempo de ejecuci\u00f3n o m\u00e1s memoria se utilizar\u00e1. <\/p>\n\n

                                              Descubrir\u00e1 que inconscientemente comprueba el tiempo de ejecuci\u00f3n y los requisitos de memoria cada vez que escriba algo que contenga bucles o llamadas recursivas. Este proceso es una confirmaci\u00f3n r\u00e1pida de que sus acciones son sensatas dadas las circunstancias. Por lo tanto, usted se encuentra ejecutando un an\u00e1lisis m\u00e1s detallado. Es entonces cuando la notaci\u00f3n O() resulta \u00fatil. La notaci\u00f3n O() es una forma matem\u00e1tica de tratar las aproximaciones. <\/p>\n\n

                                                \n
                                              1. Refactorizaci\u00f3n<\/strong><\/li>\n<\/ol>\n\n

                                                El c\u00f3digo necesita evolucionar, no es est\u00e1tico. A medida que un programa se desarrolla, se hace necesario replantearse decisiones anteriores y reelaborar partes del c\u00f3digo. Reescribir, reestructurar y redise\u00f1ar un cuerpo de c\u00f3digo existente, alterando su estructura interna sin cambiar su comportamiento externo se conoce como refactorizaci\u00f3n. <\/p>\n\n

                                                \u00bfCu\u00e1ndo debe refactorizar?<\/strong><\/p>\n\n

                                                Si se encuentra con un escollo porque el c\u00f3digo ya no encaja o nota dos cosas que deber\u00eda fusionar, no dude en cambiarlo. He aqu\u00ed varias cosas que pueden hacer que el c\u00f3digo cumpla los requisitos para ser refactorizado: <\/p>\n\n

                                                Duplicaci\u00f3n. Ha descubierto una violaci\u00f3n del principio DRY (Don’t Repeat Yourself). <\/p>\n\n

                                                Dise\u00f1o no ortogonal. Ha descubierto alg\u00fan c\u00f3digo o procedimiento que podr\u00eda hacerse m\u00e1s ortogonal (Ortogonalidad). <\/p>\n\n

                                                Conocimientos obsoletos. Las cosas cambian, los requisitos se desv\u00edan y su comprensi\u00f3n del problema aumenta. El c\u00f3digo tiene que seguir el ritmo. <\/p>\n\n

                                                Rendimiento. Es necesario trasladar funciones de un \u00e1rea del sistema a otra para mejorar el rendimiento. <\/p>\n\n

                                                  \n
                                                1. C\u00f3digo f\u00e1cil de probar<\/strong><\/li>\n<\/ol>\n\n

                                                  En los chips y sistemas m\u00e1s complejos, los desarrolladores de hardware incluyen caracter\u00edsticas como un completo autodiagn\u00f3stico incorporado (BIST) que ejecuta internamente diagn\u00f3sticos de nivel b\u00e1sico y un mecanismo de acceso a pruebas (TAM) que proporciona un arn\u00e9s de pruebas que permite al entorno externo proporcionar est\u00edmulos y recoger respuestas del chip. Puede hacer lo mismo en el software, incorporar la comprobabilidad en el software desde el principio y probar cada pieza en detalle antes de intentar conectarlas entre s\u00ed. <\/p>\n\n

                                                  Pruebas unitarias<\/strong><\/p>\n\n

                                                  Las pruebas a nivel de chip para el hardware son equivalentes a las pruebas unitarias en el software. Las pruebas se realizan en cada m\u00f3dulo de forma aislada para verificar su comportamiento. Podr\u00e1 comprender mejor c\u00f3mo reaccionar\u00e1 un m\u00f3dulo en el gran mundo una vez que lo haya probado a fondo en condiciones controladas. <\/p>\n\n

                                                  Una prueba unitaria de software es un c\u00f3digo que ejercita un m\u00f3dulo. Normalmente, la prueba unitaria crear\u00e1 un entorno artificial y luego evocar\u00e1 rutinas en el m\u00f3dulo que se est\u00e1 probando. A continuaci\u00f3n, la prueba unitaria comprueba los resultados devueltos, ya sea frente a valores conocidos o frente a los resultados de las ejecuciones anteriores de la misma prueba. <\/p>\n\n

                                                  M\u00e1s adelante, cuando re\u00fana sus \u00abcircuitos integrados de software\u00bb en un sistema completo, tendr\u00e1 la seguridad de que las piezas individuales funcionan como se espera. Entonces podr\u00e1 utilizar las mismas instalaciones de pruebas unitarias para probar el sistema en su conjunto. <\/p>\n\n

                                                  Cita favorita del cap\u00edtulo: \u00abTodo el software que escriba ser\u00e1 probado -si no por usted y su equipo, s\u00ed por los usuarios finales-, as\u00ed que m\u00e1s vale que planee probarlo a fondo\u00bb.<\/em><\/strong><\/p>\n\n

                                                  Cap\u00edtulo siete: Antes del proyecto<\/strong><\/p>\n\n

                                                  \"\"<\/figure>\n\n
                                                    \n
                                                  1. El pozo de los requisitos<\/strong><\/li>\n<\/ol>\n\n

                                                    La recopilaci\u00f3n de requisitos es una fase temprana del proyecto. La recopilaci\u00f3n implica que los requisitos ya est\u00e1n ah\u00ed, s\u00f3lo tiene que encontrarlos. P\u00f3ngalos en su cesta y siga su camino. Aunque no funciona as\u00ed, los requisitos rara vez salen a la superficie. Est\u00e1n enterrados profundamente bajo capas de suposiciones, ideas equivocadas y pol\u00edtica. <\/p>\n\n

                                                    En busca de necesidades<\/strong><\/p>\n\n

                                                    \u00bfC\u00f3mo identificar\u00e1 una aut\u00e9ntica necesidad cuando escarbe en la suciedad circundante? La respuesta es a la vez compleja y directa. La respuesta directa es una declaraci\u00f3n de algo que debe cumplirse. Por otro lado, muy pocos requisitos son claros, lo que hace que el an\u00e1lisis de requisitos sea complejo. <\/p>\n\n

                                                    En caso de que el requisito se enuncie como \u00abS\u00f3lo el personal puede ver un registro de empleado\u00bb, entonces acabar\u00e1 codificando una prueba directa cada vez que la aplicaci\u00f3n acceda a estos archivos. Sin embargo, si el enunciado es \u00abS\u00f3lo los usuarios autorizados pueden acceder a un expediente de empleado\u00bb, es probable que el desarrollador dise\u00f1e e implemente alg\u00fan tipo de sistema de control de acceso. Cuando cambie la pol\u00edtica, s\u00f3lo habr\u00e1 que actualizar los metadatos de ese sistema. Recopilar los requisitos de este modo le conducir\u00e1 a un sistema bien dise\u00f1ado para soportar metadatos. <\/p>\n\n

                                                      \n
                                                    1. Resuelva rompecabezas imposibles<\/strong><\/li>\n<\/ol>\n\n

                                                      Piense en los rompecabezas del mundo real que aparecen como regalos de Navidad o en ventas de garaje. Tiene que quitar la anilla o encajar las piezas en forma de T en la caja. Saca el anillo y descubre r\u00e1pidamente que las soluciones aparentes no resuelven el rompecabezas. La respuesta est\u00e1 en otra parte. El secreto para resolver el rompecabezas consiste en identificar las verdaderas limitaciones y encontrar en ellas una soluci\u00f3n. Algunas limitaciones son absolutas, otras son meras nociones preconcebidas. Las limitaciones fundamentales deben respetarse, por desagradables o est\u00fapidas que parezcan. Por otro lado, algunas limitaciones aparentes pueden no ser exactas. <\/p>\n\n

                                                      No piense fuera de la caja – Encuentre la caja<\/strong><\/p>\n\n

                                                      Cuando se enfrente a un problema insoluble, enumere todas las v\u00edas posibles que tiene ante usted.<\/p>\n\n

                                                      No descarte nada, por inutilizable o est\u00fapido que parezca. Repase la lista y explique por qu\u00e9 no puede tomar un camino concreto. \u00bfPuede demostrarlo? <\/p>\n\n

                                                        \n
                                                      1. No hasta que est\u00e9 preparado<\/strong><\/li>\n<\/ol>\n\n

                                                        Cuando sienta una duda persistente o desgana al enfrentarse a una tarea, pr\u00e9stele atenci\u00f3n. Puede que no sea capaz de averiguar qu\u00e9 es exactamente lo que falla. Dele tiempo y es probable que sus dudas cristalicen en algo m\u00e1s s\u00f3lido, algo que pueda abordar. El desarrollo de software a\u00fan no es una ciencia. Deje que sus instintos contribuyan a su rendimiento. <\/p>\n\n

                                                        \u00bfBuen juicio o dilaci\u00f3n?<\/strong><\/p>\n\n

                                                        <\/p>\n\n

                                                        Comenzar un nuevo proyecto o incluso un nuevo m\u00f3dulo en un proyecto existente puede ser una experiencia dolorosa. Muchos preferir\u00edan aplazar el compromiso inicial de empezar. Entonces, \u00bfc\u00f3mo puede saber cu\u00e1ndo est\u00e1 simplemente procrastinando en lugar de esperar responsablemente a que todas las piezas encajen en su sitio? <\/p>\n\n

                                                        En estas circunstancias, una t\u00e9cnica que le funcionar\u00e1 es la creaci\u00f3n de prototipos. Seleccione un \u00e1rea que le parezca dif\u00edcil y empiece a producir alguna prueba de concepto. Poco despu\u00e9s, pensar\u00e1 que est\u00e1 perdiendo el tiempo. Este aburrimiento es probablemente un buen indicio de que su reticencia inicial era s\u00f3lo un deseo de aplazar el compromiso de empezar. Abandone el prototipo y ded\u00edquese al desarrollo real. <\/p>\n\n

                                                        Cita favorita del cap\u00edtulo: \u00abLa perfecci\u00f3n se alcanza, no cuando no queda nada por a\u00f1adir, sino cuando no queda nada por quitar….\u00bb.<\/em><\/strong><\/p>\n\n

                                                        Cap\u00edtulo ocho<\/strong>: Proyectos pragm\u00e1ticos<\/p>\n\n

                                                          \n
                                                        1. Pruebas implacables<\/strong><\/li>\n<\/ol>\n\n

                                                          Pruebe pronto, pruebe a menudo y pruebe autom\u00e1ticamente. Debe empezar a realizar pruebas en cuanto tenga el c\u00f3digo. Desarrolle planes de pruebas elaborados para sus proyectos. Los equipos que utilizan pruebas automatizadas tienen muchas m\u00e1s posibilidades de \u00e9xito. Las pruebas que se ejecutan con cada compilaci\u00f3n son mucho m\u00e1s eficaces que los planes de pruebas en una estanter\u00eda. Recuerde que cuanto antes encuentre un fallo, m\u00e1s barato le resultar\u00e1 remediarlo. \u00abCodifique un poco, pruebe un poco\u00bb. <\/p>\n\n

                                                          Para que su proyecto sea satisfactorio, debe tener m\u00e1s c\u00f3digo de prueba que de producci\u00f3n. El tiempo que se pierde al producir este c\u00f3digo de prueba merece la pena y resulta m\u00e1s barato a largo plazo. Tambi\u00e9n tiene la posibilidad de crear un producto con casi cero defectos. <\/p>\n\n

                                                            \n
                                                          1. Grandes expectativas<\/strong><\/li>\n<\/ol>\n\n

                                                            El \u00e9xito del proyecto de su equipo se mide por c\u00f3mo cumple las expectativas de sus usuarios. Si su proyecto queda por debajo de sus expectativas, entonces se considera un fracaso, independientemente de lo bueno que sea el producto final en t\u00e9rminos absolutos. <\/p>\n\n

                                                            La milla extra<\/strong><\/p>\n\n

                                                            Supere suavemente las expectativas de sus usuarios. No asuste a sus usuarios; en su lugar, sorpr\u00e9ndalos. Deles un poco m\u00e1s de lo que esperaban. El esfuerzo adicional necesario para a\u00f1adir al sistema alguna caracter\u00edstica orientada al usuario se amortizar\u00e1 una y otra vez en buena voluntad. <\/p>\n\n

                                                              \n
                                                            1. Orgullo y prejuicio<\/strong><\/li>\n<\/ol>\n\n

                                                              Como programador pragm\u00e1tico, no debe huir de la responsabilidad. Al contrario, al\u00e9grese cuando se enfrente a retos y d\u00e9 a conocer su pericia laboral. Si es responsable de un dise\u00f1o o de un fragmento de c\u00f3digo, har\u00e1 un trabajo del que se sentir\u00e1 orgulloso. <\/p>\n\n

                                                              Firme su trabajo<\/strong><\/p>\n\n

                                                              Si\u00e9ntase orgulloso de su trabajo. \u00abUsted escribi\u00f3 esto y deber\u00eda respaldar su trabajo\u00bb. Su firma deber\u00eda llegar a ser reconocida como un indicador de calidad. La gente deber\u00eda ver su nombre en un trozo de c\u00f3digo y esperar que sea s\u00f3lido, est\u00e9 bien escrito, probado y documentado: un trabajo profesional realizado por un verdadero profesional. <\/p>\n\n

                                                              Cita favorita del cap\u00edtulo: \u00abLa civilizaci\u00f3n avanza ampliando el n\u00famero de operaciones importantes que podemos realizar sin pensar\u00bb.<\/em><\/strong><\/p>\n\n

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

                                                              \u00abEl programador pragm\u00e1tico\u00bb de Andrew Hunt y David Thomas es un libro cl\u00e1sico de desarrollo de software que ofrece consejos pr\u00e1cticos y t\u00e9cnicas para mejorar la forma de trabajar de los desarrolladores. Abarca temas como la depuraci\u00f3n, las pruebas, la automatizaci\u00f3n y la gesti\u00f3n de proyectos, as\u00ed como la importancia de la comunicaci\u00f3n y el aprendizaje continuo. Siguiendo las orientaciones del libro, los desarrolladores pueden mejorar sus habilidades de codificaci\u00f3n, aumentar la productividad, trabajar de forma m\u00e1s eficiente, convertirse en miembros m\u00e1s eficaces del equipo y ofrecer mejores productos de software. <\/p>\n","protected":false},"excerpt":{"rendered":"

                                                              El Programador Pragm\u00e1tico es una gu\u00eda h\u00e1bil y pr\u00e1ctica que proporciona una visi\u00f3n y los fundamentos para ser un buen programador, aumentando su especializaci\u00f3n y tecnicidad en el desarrollo de software moderno. El libro se public\u00f3 en octubre de 1999. Andrew Hunt abarca desde temas de responsabilidad personal y desarrollo profesional hasta t\u00e9cnicas de arquitectura […]<\/p>\n","protected":false},"author":1,"featured_media":17634,"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-19677","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\/19677","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=19677"}],"version-history":[{"count":1,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/posts\/19677\/revisions"}],"predecessor-version":[{"id":19682,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/posts\/19677\/revisions\/19682"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/media\/17634"}],"wp:attachment":[{"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/media?parent=19677"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/categories?post=19677"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/tags?post=19677"},{"taxonomy":"writer","embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/writer?post=19677"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}