«El Programador Pragmático» (The Pragmatic Programmer) de Dave Thomas y Andy Hunt, es un libro en el cual aprendes cómo ser un mejor programador, no desde una perspectiva técnica, si no de una basada en la experiencia. Dentro de él se pueden encontrar innumerables consejos, historias, y explicaciones acerca de los peores y mejores hábitos en el mundo de la programación, identificados a lo largo de muchos años de vivencias de los autores.
Capítulo 1. Filosofía Pragmática
La palabra pragmático proviene del latín pragmaticus – «hábil en el negocio» – también derivado del griego πραγματικός que significa «preciso para usar».
Los programadores pragmáticos son generalmente:
- Adoptadores tempranos / adaptadores veloces
- Inquisitivos
- Pensadores críticos
- Realistas
- Versátiles
La filosofía pragmática basa sus principios en siete hechos o conceptos simples:
| Hecho/Concepto | Descripción |
| ¡Es tu vida! | Si no te sientes satisfecho con lo que sea que estes haciendo ahora mismo, entonces ¡cámbialo!. Nadie más que tú tiene el poder de hacerlo. Debes sentirte cómodo con las actividades que realizas diariamente, con tu salario, tu ambiente de trabajo, la gente con la que trabajas, tus herramientas de hardware y software, con todo lo que esté relacionado a tu trabajo. La industria de las tecnologías te da una gran cantidad de oportunidades para crecer y poder tener un gran balance entre vida y trabajo. Sé proactivo, busca las oportunidades y tómalas. |
| El gato se comió mi código fuente | Hazte responsable por ti y tus acciones, en términos de crecimiento profesional, tu aprendizaje y tu educación, tus proyectos, y tu trabajo del día a día. Un programador pragmático no teme admitir ignorancia o error. Aún cuando se hagan pruebas exhaustivas, se tenga una buena documentación, y una sólida automatización, las cosas suelen salir mal: hay entregas tardías, problemas técnicos no previstos. Estas cosas siempre pasan, y cuando sucedan hay que tratar de lidiar con ellas con la mayor profesionalidad posible. Confía en tu equipo, y haz que tu equipo confíe en ti, no con palabras, sino con acciones. Cuando cometas un error (como todo mundo) o juzgues algo mal, admítelo honestamente y trata de ofrecer opciones para solucionarlo. No le eches la culpa a otros, ni pongas excusas tontas. Trata de tener siempre un plan de contingencia para las cosas que posiblemente puedan salir mal. Que no te de vergüenza preguntar, o admitir que necesitas ayuda. |
| Entropía del software | La entropía es un término de la Física que refiere a la cantidad de desorden en un sistema. Cuando el desorden aumenta en un software, suele llamarse como «podredumbre del software». No dejes «ventanas rotas» (malos diseños, malas decisiones, o código pobre) sin reparar. Arregla cada uno tan pronto sea descubierto. Si no hay suficiente tiempo para arreglarlo de forma apropiada, entonces párchalo. Puedes comentar el código malo, o mostrar un mensaje «No implementado», o sustituir con datos de prueba temporales. Toma acción para prevenir más daño y deja ver que tienes la situación bajo control. La negligencia acelera la podredumbre más rápido que cualquier otro factor. Si comienzas a trabajar en un proyecto donde el código está bien conservado — bien escrito, bien diseñado, y elegante — a ti te gustaría prestar especial atención para no arruinarlo. No provoques daño colateral solo porque se da alguna crisis, incluso si hay un «incendio» (fecha de entrega, fecha de liberación, fecha de demo, etc.). |
| Sopa de piedras y ranas hervidas | «Sopa de piedras» es una historia donde unos soldados hambrientos llegaron a un pueblo donde los habitantes se negaban a regalarles algo de alimento. Al ver esto, los soldados comenzaron a preparar una sopa de piedras, con lo cual fueron convenciendo a los habitantes que el agregarle simples ingredientes se podía mejorar, cada uno de los habitantes proporcionó un poco de vegetales y especias que tenían, y al final con la cooperación de todos se logró hacer una sopa abundante que alcanzó para todos, soldados y habitantes. La lección aquí es que si notas que las cosas no van bien en un proyecto, puedes ser un catalizador, tal como los soldados, e incentivar la pariticipación de todos los integrantes haciendo pequeñas aportaciones para mejorar el producto final. «Ranas hervidas» se refiere al hecho de que cuando se introduce una rana a una olla de agua caliente, inmediatamente esta saltará fuera del recipiente. Pero, en su lugar, si se introduce cuando el agua está a temperatura ambiente, y gradualmente se comienza a incrementar la temperatura del agua hasta llegar al punto de ebullición, la rana no notará estos cambios graduales de temperatura por lo cual nunca saldrá del recipiente y terminará hervida. La lección aquí es que a diferencia de la rana, uno debe estar atento a lo que pasa a su alrededor, inclusive si no se notan cambios evidentes siempre se debe estar revisando periódicamente el estado general de los proyectos, y determinar si existe alguna anomalía para repararla en cuanto sea posible, y no dejarlo hasta el final ya que sea demasiado tarde. |
| Software suficientemente bueno | Debes enfocarte en escribir software que es suficientemente bueno — suficientemente bueno para los usuarios, para los futuros desarrolladores, y para tu paz mental. «Suficientemente bueno» no implica hacer código descuidado o pobremente escrito, más bien, uno que sea suficientemente bueno para las necesidades de los usuarios o clientes. Muchos usuarios hoy en día prefieren comenzar a utilizar un software con algunos errores que esperar todo un año por un producto cien por ciento funcional. Si se les da a los usuarios algo con qué empezar a probar, se obtendrá retroalimentación temprana, lo cual ayudará a identificar las fallas o posibles mejoras anticipadamente, para dar eventualmente con una solución más acertada. Trabaja para entregar Productos Mínimamente Viables o MVPs (Minimal Viable Products) y mejóralos a través del tiempo. No te enfoques en entregar perfección, ya que aún cuando pongas todos tus esfuerzos en alcanzar el producto más completo posible, nunca será suficiente para llegar hasta ese punto. |
| Protafolio de conocimientos | Tu conocimiento y experiencia es tu activo más importante. Desafortunadamente, son activos que expiran muy rápido. Tu conocimiento se vuelve obsoleto tan pronto nuevas técnicas, lenguajes de programación, y ambientes son desarrollados. Por esto, tu activo estratégico más valioso debe ser tu habilidad para aprender cosas nuevas. Construye tu portafolio de conocimiento tal como los inversores construyen su dinero: – Invierte regularmente. Sé consistente y forma hábitos, estudia y aprende nuevas cosas usando solo una pequeña parte de tu tiempo cada día. – Diversifica. Aprende cosas de áreas diferentes, esto te hace más versátil en diferentes situaciones. Tambié recuerda fortalecer tus habilidades no técnicas. – Maneja el riesgo. No enfoques todos tus esfuerzos en tecnologías que probablemente se puedan volver obsoletas muy rápido o que puedan ser canceladas en el futuro próximo. – Compra barato, vende caro. Sé un adoptador temprano, encuentra tecnologías emergentes que se puedan volver populares con el pasar del tiempo. – Revisa y haz un balance. Si tu estrategia de aprendizaje no está funcionando como debería, haz un balance, replantea tu estrategia y continúa. Algunas sugerencias que puedes seguir para incrementar tu portafolio de conocimiento son: – Aprende un nuevo lenguaje de programación al menos cada año. – Lee un libro sobre temas técnicos cada mes. – Lee libros no técnicos también. – Toma clases. – Participa en grupos de usuarios locales y reuniones donde puedas aprender de expertos. – Experimenta con diferentes ambientes (Windows, Linux, MacOS). – Mantente al día consumiendo noticias de tecnología, blogs, y revistas. No permitas socavones en las tierras de tu conocimiento. Si no sabes algo, investiga y conoce acerca de ello. Sé un pensador crítico. Nunca te conformes con la primer cosa que encuentres sobre algo. Identifica debilidades en los argumentos, fallas en las explicaciones, cómo funcionan las cosas y por qué funcionan así. De esta manera conseguirás tener un conocimiento más profundo de las cosas. |
| ¡Comunícate! | Cuando quieras comunicar algo, primero identifica a tu audiencia, una vez hecho esto, adapta tus ideas y el estilo de comunicación para ajustarse de la mejor manera al público. Planea lo que vas a decir. Escribe un borrador, después pregúntate ¿Esto comunica lo que realmente quiero expresar a mi audiencia? Refina tu borrador hasta que la respuesta sea sí. Elige el mejor momento para hablar sobre algo. Nunca hables de situaciones dificiles cuando el ambiente sea complicado. Cuida la presentación. Debes hacer ver de manera profesional y organizada cualquier cosa que vayas a comunicar, esto hace más fácil entender el contenido y te da mayor credibilidad. Involucra a tu audiencia, hazlos parte de la conversacione y déjalos participar añadiendo mayor valor a tu contenido. Aprende a escuchar. Si escuchas a tu audiencia, ellos te escucharán a ti. Esto mejora muchísimo el flujo de comunicación. Siempre toma encuenta la opinió de las personas. Esto evita que se rompa el flujo de comunicación. Cuando escribas documentación en tu código, no expliques lo que el código hace por sí mismo, porque esto es caer en redundancia, en vez de esto, solo agrega contexto, por ejemplo, explica por qué algo se debe hacer así y no de otra forma. |
Capítulo 2. Enfoque Pragmático
| Principio | Descripción |
| La esencia del buen diseño | Un software está bien diseñado si se adapta fácilmente a los cambios, siguiendo el principio ETC (Easier To Change). Cada vez que implementes algo nuevo, piensa si será fácil de modificar en el futuro, si no es así, tienes dos opciones: integrar código que sea reemplazable, o dejar pistas acerca de cómo reemplazarlo si fuese necesario. Ten siempre en mente dejar código que sea desacoplado y cohesivo, esa es la esencia de un buen diseño. |
| DRY – las maldades de la duplicación | Cada pieza de conocimiento debe tener una representación única, no ambigua, y autoritativa dentro de un sistema, siguiendo el principio DRY (Don’t Repeat Yourself). DRY invita a evitar la duplicación de información dentro de un sistema, ya que las consecuencias que tener duplicaciones es que se pueden tener las mismas cosas en diferentes lugares, y para modificarlas se tienen que hacer cambios en múltiples lugares, y a veces las funcionalidades no concuerdan, o se olvida de hacer cambios en un lugar, lo que provoca un mal funcionamiento o errores inesperados. Se debe buscar hacer piezas de código reutilizable, evitar documentar innecesariamente código que se explique por sí mismo, y mantener una buena comunicación dentro del equipo de desarrolladores para evitar que dos personas creen una misma funcionalidad en dos diferentes lugares a la vez. |
| Ortogonalidad | Un sistema es ortogonal cuando al hacer cambios en uno de sus componentes no se afectan a los otros (o se afectan mínimamente). Los sistemas que no son ortogonales son complejos y difíciles de controlar cuando se modifican, ya que al hacer un pequeño cambio se afecta a gran parte del sistema, lo que requiere mayor esfuerzo, tiempo, y costo para arreglarse. Siempre que se diseñe un componente se debe hacer pensando que será auto contenido, independiente, y con una única responsabilidad. Tener sistemas ortogonales permite aumentar la productividad y reducir el riesgo de generación de errores, además, combinando la ortogonalidad con el principio DRY, se pueden obtener sistemas más flexibles, más entendibles, más fáciles de depurar, testear, y mantener. |
| Reversibilidad | Los sistemas de software deben crearse con la mayor abstracción posible, de manera que cuando se requiera revertir una decisión crítica, el costo de hacerlo sea lo más mínimo posible. Realizar un diseño pensado de manera general y que no se centre en una única solución permitirá de mejor manera un cambio radical, sea un cambio de base de datos, de lenguaje de programación, o de infraestructura. |
| Balas dirigidas | Las balas guiadas son un tipo de munición que deja un rastro del camino que toman hasta llegar al objetivo. Este rastro es útil para identificar qué tan certero se está siendo para impactar el objetivo, y poder así apuntar de nuevo para hacer otro intento que sea más preciso. En desarrollo de software, se usa el término código guiado cuando se implementan partes de las funcionalidades que conectan entre sí de manera que se pueda identificar cómo funcionan en conjunto, y con ello, ir haciendo nuevas adiciones o pequeñas adaptaciones que vayan dando como resultado un producto cada vez más cercano al planteado como objetivo final. El hacer esto permite ir liberando pequeñas partes del sistema que son utilizables por los clientes, permite obtener retroalimentación temprana, y también revertir cambios que impacten en menor medida cuando no se está cumpliendo los objetivos planteados. |
| Prototipos y notas post-it | Para dar una idea general de un producto gastando lo menos posible, se debe recurrir a los prototipos. Estos son diseños generales de un producto que dejan de lado la correctitud, completitud, robustez, y el estilo de un producto terminado. Para hacer un prototipo se puede hacer uso de herramientas tan simples como notas post-it, un pizarrón, o una hoja en blanco, aunque también herramientas digitales especializadas para ello. Los prototipos permiten fallar, modificar, aprender, y visualizar de la manera más económica posible. A diferencia del código guiado, donde se producen partes utilizables, los prototipos se basan únicamente en la idea de diseño y lo que será posible hacer en un futuro con el producto. Son ideales para presentaciones ante clientes, y para proponer diseños de acuerdo con especificaciones poco refinadas o con alto nivel de incertidumbre. |
| Lenguajes de dominio | Los lenguajes de programación influencian cómo se piensa acerca de un problema, y se generan diferentes soluciones con un estilo orientado al dominio del lenguaje. Sin embargo, lo que debe buscarse es programar pensando en el dominio del problema, ya que con esto, se pueden proponer soluciones que no estén apegadas totalmente a lo que puede ofrecer un único lenguaje de programación. Para este caso se pueden definir dos tipos de dominios de lenguajes: interno y externo. El dominio interno contempla el uso de herramientas escritas en un lenguaje de programación específico para proyectos hechos con ese lenguaje de programación, y el dominio externo se refiere a herramientas que usan sintaxis que no es parte del lenguaje de programación del proyecto. Cada uno tiene sus ventajas y desventajas, por ejemplo, en el dominio interno se pueden integrar de manera más fácil las herramientas al proyecto ya que usan el mismo lenguaje, sin embargo, se limitan a los que el mismo lenguaje puede ofrecer; en el caso del dominio externo, se tiene mayor flexibilidad a proponer soluciones fuera de la forma de pensar del lenguaje de programación, sin embargo, puede que se necesite un proceso extra para lograr la intercomunicación entre el lenguaje de programación del proyecto y la sintaxis propia de la herramienta de dominio externo. |
| Estimación | La estimación de proyectos de software es un proceso cuya precisión radica principalmente en la experiencia y el entendimiento del problema. Si no se tiene la experiencia suficiente, es recomendable preguntar a alguien que ya haya trabajado un proyecto similar cuánto tiempo le tomó, para así tener una idea general de la complejidad y el esfuerzo total necesario. Para realizar una estimación lo más precisa posible, puede recurrirse a un modelo de estimación, el cual incluya los tiempos de cada una de las fases del proceso de desarrollo que realiza la empresa, en conjunto con una imagen general de cómo el sistema puede implementarse. Una vez hecho esto, se puede descomponer el modelo en componentes más pequeños, cada uno con sus propios parámetros de complejidad, a los cuales se puede hacer una estimación más a detalle. Es buena idea llevar un registro de las estimaciones, y al final de cada proyecto, verificar qué tan precisas fueron, en caso de un fallo en la estimación, se puede averiguar qué parámetros fueron los que fueron mal estimados y se pueden corregir en las siguientes estimaciones. Además de esto, se puede hacer uso de la técnica PERT (Program Evaluation Review Technique), en la cual, se hacen estimaciones con los escenarios optimista, deseado, y pesimista, y obtener un promedio de los tres, con esto se abarcan todas las posibilidades en la cuales se puede presentar el proyecto, mejorando el intervalo de tiempo para su realización. |
Capítulo 3. Herramientas Básicas
Capítulo 4. Paranoia Pragmática
Capítulo 5. Doblar o Romper
Capítulo 6. Concurrencia
Capítulo 7. Mientras Programas
Capítulo 8. Antes del Proyecto
Capítulo 9. Proyectos Pragmáticos