Non sviluppare la visione del tunnel di sviluppo

Nei post precedenti, ho parlato dell’idea di concentrarsi su un’area e andare in profondità piuttosto che in largo. Questa è una preferenza personale, ovviamente, ma è comunque mia.

Nell’ultimo anno, tuttavia, uno dei sottoprodotti che ho riscontrato è che più a lungo rimani in un determinato settore, più comuni diventano alcuni problemi. (Questo non dovrebbe sorprendere in quanto questo è esattamente il motivo per cui abbiamo modelli di progettazione .)

Ma il punto nel fare questo è che sviluppi una sorta di visione a tunnel per i modi per risolvere i problemi.

Crediti

Caso in questione: di recente, mi è stato assegnato il compito di sviluppare alcune funzionalità che analizzassero il markup e lo convertissero in un formato leggermente diverso.

Sviluppo Tunnel Vision

L’ho fatto più e più volte e ho spesso scoperto [DOMDocument](https://www.php.net/manual/en/class.domdocument.php)di essere una delle utilità più utili per farlo. Ma c’è un problema: mi ero così abituato a usarlo che stavo trascurando soluzioni alternative che non erano integrate in WordPress, ma in PHP.

Invece di dover caricare l’intero documento in un’istanza di [DOMDocument](https://www.php.net/manual/en/class.domdocument.php), ho potuto eseguire le sostituzioni di stringhe usando – no, non espressioni regolari (anche se era allettante) – ma [strip_tags](https://www.php.net/manual/en/function.strip-tags.php)e [str_replace](http://php.net/manual/en/function.str-replace.php).

Facendo un ulteriore passo avanti, questo è qualcosa che è stato sottolineato da un rispettato collega durante una revisione del codice.

Sulle recensioni del codice, ancora

Ho anche passato i post precedenti parlando di revisioni del codice, perché penso che siano importanti, come gestirle e come evitare di rimanere attaccati ad esse.

Ma è stato un bel promemoria per scoprire che anche quando pensi di essere abituato a risolvere un problema comune in una determinata situazione, potrebbe esserci comunque un modo diverso, più pulito e/o migliore per farlo.

Il mio punto è che non importa da quale parte della revisione del codice ti trovi e non importa da quanto tempo fai qualunque cosa tu stia facendo, non respingere una critica perché è diversa.

Semmai, ti impedisce di sviluppare la visione del tunnel di sviluppo; mantiene la tua mente cablata per pensare in modo più ampio a un problema, non importa quante volte lo hai risolto.