Ne développez pas la vision du tunnel de développement
Dans les articles précédents, j’ai parlé de l’idée de se concentrer sur une zone et d’aller en profondeur plutôt qu’en largeur. C’est une préférence personnelle, bien sûr, mais c’est quand même la mienne.
Au cours de la dernière année, cependant, l’un des sous-produits que j’ai découvert est que plus vous restez longtemps dans une industrie donnée, plus certains problèmes deviennent courants. (Cela ne devrait pas être une surprise car c’est précisément pourquoi nous avons des modèles de conception .)
Mais le problème avec cela, c’est que vous développez une sorte de vision étroite des moyens de résoudre les problèmes.
Exemple: Récemment, j’ai été chargé de développer une fonctionnalité qui allait analyser le balisage et le convertir dans un format légèrement différent.
Vision du tunnel de développement
Je l’ai fait maintes et maintes fois et j’ai souvent trouvé [DOMDocument](https://www.php.net/manual/en/class.domdocument.php)que c’était l’un des utilitaires les plus utiles pour ce faire. Mais il y a un problème: je m’étais tellement habitué à l’utiliser que je négligeais les solutions alternatives qui n’étaient pas intégrées à WordPress, mais à PHP.
Plutôt que d’avoir à charger le document entier dans une instance de [DOMDocument](https://www.php.net/manual/en/class.domdocument.php), je pouvais remplacer les chaînes en utilisant – non, pas des expressions régulières (bien que cela soit tentant) – mais [strip_tags](https://www.php.net/manual/en/function.strip-tags.php)et [str_replace](http://php.net/manual/en/function.str-replace.php).
Pour aller plus loin, c’est quelque chose qui a été souligné par un collègue très respecté lors d’une révision du code.
Sur les revues de code, encore une fois
J’ai également passé des articles précédents à parler des revues de code, pourquoi je pense qu’elles sont importantes, comment les gérer et comment éviter de rester attaché à elles.
Mais c’était un bon rappel à trouver pour découvrir que même lorsque vous pensez que vous êtes habitué à résoudre un problème commun dans une situation donnée, il peut toujours y avoir une manière différente, plus propre et/ou meilleure de le faire.
Ce que je veux dire, c’est que peu importe de quel côté de la révision du code vous vous trouvez et peu importe depuis combien de temps vous faites ce que vous faites, ne rejetez pas une critique parce qu’elle est différente.
Si quoi que ce soit, cela vous empêche de développer une vision tunnel de développement; cela permet à votre esprit de penser plus largement à un problème, quelle que soit la fréquence à laquelle vous l’avez résolu.