No desarrolle una visión de túnel de desarrollo
En publicaciones anteriores, hablé sobre la idea de enfocarse en un área y profundizar en lugar de ampliar. Esta es una preferencia personal, por supuesto, pero es mía, no obstante.
Sin embargo, durante el último año, uno de los subproductos que he encontrado es que cuanto más tiempo permaneces en una industria determinada, más comunes se vuelven ciertos problemas. (Esto no debería ser una sorpresa, ya que es precisamente por eso que tenemos patrones de diseño ).
Pero lo importante de hacer esto es que desarrollas una especie de visión de túnel para encontrar formas de resolver problemas.
Caso en cuestión: Recientemente, se me encomendó la necesidad de desarrollar alguna funcionalidad que analizara el marcado y lo convirtiera a un formato ligeramente diferente.
Visión de túnel de desarrollo
He hecho esto una y otra vez y, a menudo, he descubierto [DOMDocument](https://www.php.net/manual/en/class.domdocument.php)que es una de las utilidades más útiles para hacerlo. Pero hay un problema: me había acostumbrado tanto a usar esto que estaba descuidando soluciones alternativas que no estaban integradas en WordPress, sino en PHP.
En lugar de tener que cargar todo el documento en una instancia de [DOMDocument](https://www.php.net/manual/en/class.domdocument.php), podría colocar reemplazos de cadena usando, no, no expresiones regulares (aunque eso era tentador), pero [strip_tags](https://www.php.net/manual/en/function.strip-tags.php)y [str_replace](http://php.net/manual/en/function.str-replace.php).
Yendo un paso más allá, esto es algo que señaló un colega muy respetado durante una revisión del código.
Sobre revisiones de código, otra vez
También pasé publicaciones anteriores hablando sobre revisiones de código, por qué creo que son importantes, cómo manejarlas y cómo evitar apegarse a ellas.
Pero fue un buen recordatorio descubrir que incluso cuando crees que estás acostumbrado a resolver un problema común en una situación dada, todavía puede haber una manera diferente, más limpia y/o mejor de hacerlo.
Mi punto es que no importa de qué lado de la revisión del código estés y no importa cuánto tiempo hayas estado haciendo lo que sea que estés haciendo, no descartes una crítica porque es diferente.
En todo caso, le impide desarrollar una visión de túnel del desarrollo; mantiene su mente conectada para pensar más ampliamente sobre un problema sin importar la frecuencia con la que lo haya resuelto.