The

pragmatic programmer pdf español descargar

No siempre es fácil encontrar el tiempo o las ganas para testear nuestro código, pero, como ya te he dicho otras veces, es importantísimo que lo hagas. Plata. Voy a empezar confesándote algo: desde que me suscribí hace unos meses a Netflix, mi ritmo de lectura ha bajado sustancialmente. «Código que sea fácil de probar» y «Testing
despiadado».Finalmente, llegamos al oro de mi selección de hoy: el testing.
Aunque no es necesario hacerlos, es una buena forma de poner a prueba si has entendido lo que te explican y de reflexionar un poco más sobre lo que has leído.
La vista siempre escucha al modelo para que, cuando se produzcan cambios en él, ésta pueda mostrarlos al usuario. «Los males de la duplicación».Este consejo ya lo he avanzado unos párrafos más arriba, así que no era difícil imaginar que sería uno de mis favoritos. Y los autores del libro coinciden con mi visión.En el capítulo 6 hablan sobre la
importancia de escribir código que se pueda testear. El siguiente consejo (Tip 62 del libro) pone la guinda:Realiza tests pronto. (…) Los programadores pragmáticos somos diferentes. En él se hace especial hincapié en el equipo, los automatismos, el testing…Finalmente, comentarte que el libro incluye unos 40 ejercicios con sus respuestas. En esencia,
un componente puede suscribirse a los eventos que otro componente publica. Por otro lado, la vista también escucha las interacciones del usuario para actualizar el modelo de forma pertinente.? ¿Necesitas una función parecida a otra que ya has escrito, pero con un pequeñísimo cambio? A los desarrolladores les entra la pereza y duplican cosas
«porque es más fácil».
Para mí, este tipo de libros son «de referencia»; me gusta saber de qué van y tenerlos a mano para que me ayuden a resolver cualquier duda puntual que me pueda surgir.El libro es una colección de «casos» o «ejemplos» en los que se explican situaciones típicas a la que nos podemos enfrentar y cómo podemos combatirlas. El código va a evolucionar
sí o sí, así que es mejor si aprendes algunas técnicas que permitan mantenerlo y modificarlo fácilmente.Mientras escribes código. Los desarrolladores sienten que no hay otra; el entorno les obliga. O necesitamos una clase que represente una entrada de la base de datos, con lo que sus atributos y las columnas de la base de datos son, de nuevo, una
duplicidad.Duplicidad inadvertida. En este capítulo se tratan temas como duplicidades, prototipos, estimaciones…Las herramientas básicas. El ejemplo que ponen lo explica muy bien: tienes una clase Línea con los atributos inicio, fin y longitud. Te explica cómo obtener los requisitos del proyecto y te advierte de los diferentes problemas que puedes (y
vas a) encontrarte.Proyectos pragmáticos.
Recomendaciones de herramientas que deberías saber usar en tu día a día y el por qué de su utilidad. ¡Así pues, vamos a por el podio de consejos! ?
Si cumplimos estas premisas, seremos capaces de escribir tests unitarios que nos permitirán verificar el correcto funcionamiento de nuestros componentes. Esto ya lo hemos tratado en este blog, pero básicamente consiste en escribir pequeñas unidades de código con una funcionalidad muy bien definida en forma de entradas y salidas. Supongo que
es más fácil desconectar así… Pero me sigue gustando muchísimo leer y, por ello, siempre intento buscar huecos en mi agenda para devorar algunas páginas.

Como el libro me ha parecido ameno e interesante, he decidido explicarte un poco de qué va y cómo está organizado, compartir algunos de los consejos que más me han gustado y comentar por qué creo que leerlo te ayudará a ser mejor desarrollador WordPress.Un vistazo al libroCon tan solo 260 páginas, El programador pragmático es un libro que
se deja leer fácilmente. También es importante crear una cultura del test, de tal forma que todos los miembros de tu equipo se sumen a ella y vean la utilidad del testing.En el capítulo 8 los autores vuelven a subrayar la importancia del testing. Esto permite que cada componente escuche aquello que le interesa (suscripción) mientras que lo mantiene
desconectado totalmente de aquellos componentes que se interesan por él (publicación).Una arquitectura montada con eventos permite la implementación del patrón modelo-vista-controlador. En definitiva, da una perspectiva muy detallada de cosas que quizás ya sabes, pero en las que no siempre reparas.Todos los casos están agrupados en los
siguientes capítulos:Una filosofía pragmática. Pues bien, el atributo longitud es una duplicidad, puesto que se puede calcular a partir de inicio y fin.Duplicidad impaciente. Aunque todos ellos son recomendables por un motivo u otro, siempre me gusta mojarme y compartir los tres puntos que, en mi opinión, son más útiles. «Sólo es una vista».Una de
las primeras cosas que seguramente has aprendido es no escribir un programa como un único bloque, sino que debes partirlo en pequeños componentes/módulos, cada uno con sus responsabilidades (lo que se llama «divide and conquer«). Se trata de un capítulo introductorio donde los autores explican qué rasgos debería tener un programador
pragmático.Cómo trabajar de forma pragmática. Aquí encontrarás ejemplos para reducir (que no eliminar) esas imperfecciones.Doblar o partir. Consejos a tener en cuenta mientas estás escribiendo el código. Escribir en texto plano, usar un sistema de control de versiones o integrar generadores de código en tu flujo de trabajo son algunos de los
ejemplos que tratan.Paranoia pragmática. A veces con el objetivo de entretenerme, otras para aprender.Recientemente he leído un libro llamado «El programador pragmático: de aficionado a maestro» (en inglés; no sé si existe versión en español), de Andrew Hunt y David Thomas.

Hazlos automáticamente.Aplicándolo a WordPressEl programador pragmático no es un libro que esté pensado para desarrolladores WordPress en particular… pero la mayoría de consejos que incluye se pueden aplicar más o menos de forma directa en el contexto WordPress. A través de los principios de «publicación» y «suscripción», los eventos te
permitirán reducir el acoplamiento entre componentes.

«Si tienes que repetir algo, ponlo en una función y úsala a ella en lugar de copiar y pegar líneas de código» es la típica frase del compañero de turno…?
Y es que buena parte del tiempo que antes dedicaba a leer una novela cualquiera ahora lo dedico a ver series ?. Pero que no te engañe su «brevedad»: aunque el contenido esté escrito de forma amena y comprensible, los conceptos que explica no son sencillos de asimilar, así que evita leerlo de una sentada. Uno de los capítulos más interesantes, trata
sobre las «imperfecciones» del código: tenemos que aceptar que el código no será nunca perfecto… pero eso no debería ser ni un impedimento ni un problema. Llevaba ya un tiempo buscando algún libro sobre buenas prácticas de programación y consejos varios, así que cuando lo encontré y vi que tenía buenas opiniones en internet, decidí comprarlo
(junto con otro llamado Clean Code, del que hablaré más adelante… cuando lo haya leído ?). Tal y como hemos estado viendo en la entrada de hoy, es aquel que no se repite, que se pone en la piel del usuario, que evita problemas, que escribe buena documentación, que prueba su código… Sinceramente, no creo que sea necesario justificar la utilidad
del libro en el contexto de WordPress, porque creo que los ejemplos que te he puesto hablan por sí solos. Pues bien, en este consejo del libro (en el capítulo 5) los autores te presentan el concepto de «eventos» y el patrón «Modelo-Vista-Controlador» para orquestar esa «sincronización».Al tratarse de dos paradigmas muy utilizados en el mundo web,
especialmente con la aparición de frameworks como Backbone, React o Angular, está claro que este consejo se merecía la plata de mi lista. Una de las cosas que más me ha sorprendido (y que le ha hecho merecedor de este bronce) es la explicación de porqué aparecen duplicidades.Según Hunt y Thomas, la mayoría de las duplicidades que vemos
corresponden a una de las siguientes categorías:Duplicidad impuesta. Pues bien, el libro profundiza mucho más sobre qué es la «duplicidad»: duplicar el conocimiento en código, comentarios y documentación, duplicar componentes por cuestiones de arquitectura tipo cliente/servidor, etc. Bronce. Los desarrolladores no se dan cuenta de que están
duplicando información. Luego, cuando el programa se pone en marcha, ya todo es cuestión de conseguir «sincronizar» esos módulos, que hablen entre ellos para solucionar tu problema. Además, las respuestas están también muy bien explicadas, con lo que no te será difícil afianzar conceptos.Los 3 mejores consejos del libroTal y como te acabo de
comentar, el libro esta lleno de consejos que te ayudarán a llevar tus proyectos a buen puerto. Oro.
Lo mejor que puedes hacer es empezar con una lectura en diagonal para familiarizarte con sus contenidos y luego ya, si eso, profundizas en los temas que más te interesan en ese momento. Conjunto de recomendaciones y trucos básicos para mejorar tus habilidades.

De nuevo, estaríamos duplicando conocimiento.? Por ejemplo, uno de los temas que se discuten en el capítulo 2 (cuya traducción libre podría ser «cómo trabajar de forma pragmática») son los males de la duplicación. De hecho, mis tres consejos favoritos describen problemas que aparecen sí o sí en WordPress.Un buen programador no es aquel que
escribe el mejor código, sino el que tiene una visión más global de todo el proyecto. Realízalos a menudo. Por ejemplo, «tenemos que comentar el código», con lo que el código y los comentarios acaban describiendo el mismo conocimiento (y, por lo tanto, lo estamos duplicando).
En mi opinión, se trata de otro gran capítulo del libro que combina conocimientos teóricos (por ejemplo, cómo estimar el coste de un algoritmo) con recomendaciones muy prácticas (por ejemplo, como refactorizar código).Antes del proyecto. Así que, sí: mi recomendación es que lo tengas en tu estantería, lo leas con cariño y lo consultes de vez en
cuando ?Imagen destacada de la portada del libro «The Pragmatic Programmer: from journeyman to master«. Todos sabemos que «no hay que repetir código», ¿verdad? Duplícala y aplica ese cambio.Duplicidad inter-desarrolladores. Aunque podría entretenerme en resumir lo que allí explican, creo que la siguiente frase lo dice casi todo:La mayoría
de los desarrolladores odia el testing. El libro habla con muchísimo detalle sobre los problemas que supone tener código y/o conocimiento duplicado. Cuando tienes a varios miembros trabajando en un mismo proyecto, es posible que varios acaben escribiendo «lo mismo» (aunque no «igual»).
Es el último capítulo del libro y, como tal, viene a resumir todos los puntos que se han tratado en los anteriores. Si eres de esos programadores a los que les encanta ponerse a programar en seguida, este capítulo es de obligada lectura. Queremos encontrar nuestros bugs ahora y así ahorrarnos la vergüenza de que sean otros quienes los encuentren
después.¿Aún no te ha quedado claro?