El programador pragmático: consejos para convertirse en un mejor desarrollador de WordPress

Ok, confieso: como me suscribí a Netflix, leí mucho menos que antes. No porque ya no me guste, ¿solo depende de los maravillosos programas de Netflix? Supongo que es más fácil despejar tu mente de esta manera … pero no me malinterpreten, todavía me gusta leer y siempre trato de encontrar unos minutos gratis para leer algunas páginas. A veces leo para divertirme, a veces leo para aprender cosas nuevas. Recientemente leí un libro de Andrew Hunt y David Thomas llamado “Programador Pragmático: de ternero a maestro”. Estaba buscando un libro para enseñarme algunos consejos y trucos y buenas prácticas para mejorar mis habilidades de programación, así que cuando lo vi y leí las reseñas en Amazon, pensé que sería bueno tenerlo en el estante. (Junto con el código limpio, que revisaré en el futuro … después de leerlo, por supuesto?). Me gustó mucho el libro, así que decidí compartir sus temas, como está organizado, algunos ejemplos de consejos que más me gustó y cómo un libro así puede ayudarlo a mejorar WordPress. habilidades.
Presentación general del libro Con solo 260 páginas, el programador pragmático se puede leer fácilmente. Pero no se deje engañar por su conciso: el libro explica conceptos complejos en un inglés simple, pero si desea que estos conceptos realmente lo incluyan, tendrá que leerlo cuidadosamente y digerirlo. No los lea todos a la vez: navegue y vuelva a ello cuando tenga una cierta pregunta. Piénselo como un “libro de referencia”: no tiene que memorizarlo, debe recordar los temas que cubre y leer lo que necesita cuando lo necesita. Este libro es una maravillosa colección de “ejemplos” en el que Los autores describen problemas comunes que podríamos enfrentar y mostrarle cómo superarlos (o prevenirlos). Por ejemplo, en el Capítulo 2 (un enfoque pragmático), se discuten los males de la duplicación. Estoy bastante seguro de que ya sabes que “no deberías duplicar el código”, ¿verdad? No hay nada nuevo aquí. Pero el libro da un paso más y explica por qué aparece la duplicación, qué tipos de duplicación existe, qué puede hacer para identificar y evitar … es decir, ofrece una visión detallada de las cosas que ya puede saber, pero que eso No eras plenamente consciente.
Todos los consejos, trucos y comentarios se organizan en los siguientes capítulos:
Una filosofía pragmática. Capítulo introductorio en el que los autores describen las características que debe tener un programador pragmático.
Un enfoque pragmático. Consejo de consejos y trucos que lo ayudarán a mejorar sus habilidades. Este capítulo cubre temas como la duplicación del código, prototipos, estimaciones, etc.
El instrumento básico. Aquí encontrará una lista inagotable de las herramientas que necesita en su caja de herramientas, junto con los argumentos detrás de ellas. Los codificadores de texto simples, CVS o herramientas de generación de código son varios ejemplos de tales herramientas. Paraloia pragmática. En mi opinión, este es uno de los capítulos más interesantes del libro. Cubra una verdad dura: su código será imperfecto y debe aprender a vivir con él. Aquí encontrará ejemplos sobre cómo reducir (pero no eliminar) esas imperfecciones.
Doblar o romper. El código cambiará independientemente de si le gusta o no. Por lo tanto, es esencial escribir código que se pueda mantener. Esto es lo que los autores discuten en el Capítulo 5.
Mientras codifica. Algunos consejos a tener en cuenta durante la codificación. Creo que también es un gran capítulo, porque combina la teoría (cómo estimar el costo de un algoritmo) con la práctica (cómo restaurar el código).
Antes del proyecto. Si eres uno de esos programadores a los que les gusta codificar, pero odio hablar con los clientes … bueno, este es tu capítulo. Aquí aprenderá cómo obtener los requisitos del proyecto, los problemas que pueden surgir durante este proceso y, nuevamente, cómo superarlos.
Proyectos pragmáticos. El último capítulo del libro es esencialmente resumiendo todo lo que ha leído. El equipo, la automatización, las pruebas … las piezas más importantes que crean un gran programador/equipo se vuelven a visitar en este capítulo final.
Finalmente, observe que el libro también incluye algunos ejercicios (alrededor de 40) con sus respuestas. No tiene que hacer ninguno de ellos para aprender, pero creo que es bueno tenerlos de todos modos: lo ayudarán a verificar si ha entendido correctamente todos los temas y le darán la oportunidad de pensar en su nuevo … . habilidades adquiridas. ¡Además, las explicaciones están tan bien escritas que vale la pena leerlas también! Los mejores 3 consejos son muchos consejos y trucos en el libro que ayudarán a sus proyectos a tener éxito. Todos son excelentes, pero creo que una revisión sincera necesita una lista de los tres primeros, así que … ¡aquí tienes los 3 mejores consejos en el libro! (después de mí, por supuesto)? Bronce. “La maldad del doblaje”. Ya mencioné esto algunas líneas anteriores, por lo que puedes adivinar que este es uno de mis consejos favoritos. El libro explica en detalle los problemas que implica la duplicación. Sin embargo, lo que más me gustó de este tema es la explicación de por qué aparece la duplicación.
Según Hunt y Thomas, la mayor parte de la duplicación que vemos cae en una de las siguientes categorías:
Dubble impuesto. Los desarrolladores sienten que no tienen otra opción: el entorno parece requerir duplicación. Por ejemplo, tenemos que comentar sobre el código, ¿verdad? Lo que significa que tenemos el mismo conocimiento en código y comentarios. O necesitamos una clase que se asigne a una entrada de base de datos, lo que significa que los campos asociados con una determinada clase se duplican en el esquema de la base de datos y en la clase misma.
Duplicación accidental. Los desarrolladores no se dan cuenta de que es información duplicada. El ejemplo dado por los autores es excelente: tiene una clase llamada línea con los siguientes atributos: Inicio, End y Legth. Genial, ¿verdad? Bueno, Legth es una duplicación, porque se puede calcular utilizando las otras dos propiedades: comenzar y terminar. Los desarrolladores se vuelven perezosos y dobles porque parece más fácil. “¿Necesita una nueva versión de esta función con un ligero cambio? ¡Bueno, duplíquelo y aplique el pequeño cambio!

Duplicación entre desarrolladores. Más personas de un equipo (o equipos diferentes) duplican información. Debe alentar el intercambio de recursos entre todos los miembros del equipo y sus equipos, de lo contrario, puede terminar duplicando las cosas.
? Plata. “Es solo una vista”. Desde el principio, nos enseñaron a no escribir un programa como un solo gran fuck, sino que debemos “dividir y conquistarlo” y separarlo en “módulos”, cada uno con sus propias responsabilidades. Una vez que tenemos todos los módulos, todo es para que hablen entre sí y orquesten toda la configuración. Más fácil de decir que hacer …
En el Capítulo 5 encontrará una sección que cubra este tema. En particular, los autores hablan sobre el concepto de “eventos” e introducen el modelo de controlador de visión modelo. Estos paradigmas se usan ampliamente hoy, especialmente después de la aparición de cuadros como la columna vertebral, reaccionamiento o angular. Por eso pensé que este tema valía mi medalla de plata. Una arquitectura basada en el evento utiliza los conceptos de publicación y suscripción. Esencialmente, esto permite que un componente se suscriba a otro y detecte cuándo cambia, porque este último publicará un evento cuando aparezca algo relevante. Esta arquitectura hace que los componentes sean muy fáciles: el editor es completamente agnóstico sobre sus oyentes. Estos principios básicos facilitan la creación de una aplicación de controlador de visión modelo, en la que una visualización escucha los cambios de un modelo y reacciona nuevamente al hacer la nueva condición en la pantalla. Oro. “Código que es fácil de probar” y “prueba despiadada”. ¿Y el Trofeo Dorado va a …? ¡Prueba! Sé que no siempre es fácil probar su código, pero ya he hablado de ello y sabes que es muy importante. Mientras los autores escriben en el Capítulo 6, las pruebas juegan un papel muy importante en el desarrollo del software. En primer lugar, debe asegurarse de que su código se pueda probar. Para hacer esto, debe escribir pequeñas unidades de código que tengan responsabilidades claras y un conjunto bien definido de entradas y salidas. Luego podrá escribir pruebas simples que verifiquen que, dada una determinada entrada, obtendrá el resultado correcto.
También debe promover una cultura de prueba. Todos los programas que escriba eventualmente serán probados, si no es su equipo y su equipo, luego por los usuarios. Así que asegúrese de que todos en su equipo estén a bordo e invíquelos a probar su código lo antes posible. El Capítulo 8 resume esto bastante bien: la mayoría de los desarrolladores odian las pruebas. (…) Los programadores pragmáticos son diferentes. Estamos motivados para encontrar nuestros errores ahora, por lo que no debemos soportar la vergüenza de que otros encuentren nuestros errores más tarde. ¿Aún no estás convencido? El consejo 62 del libro dice todo: prueba temprano. Prueba a menudo. Prueba automáticamente. WordPress pragmático El programador pragmático no es un libro orientado al libro en sí, pero su contenido se puede aplicar fácilmente a nuestros desarrollos. Tome solo tres consejos favoritos como ejemplo: definitivamente lo ayudarán a escribir complementos y/o mejores temas. Un programador de “jinete” podría ser el mejor al escribir el código. Un programador “maestro” comprende profundamente los proyectos para los que trabaja, evita duplicar, comprender y ayudar a los usuarios finales, previene problemas, escribe documentación maravillosa, prueba su código …
Mi último consejo: agregue este libro a su estante. Si alguna vez tiene una “pregunta filosófica”, ¿podría tener la respuesta que necesita? Imagen presentada desde la portada “Programador pragmático: de ternero a maestro”.