Taille du projet et « garder les choses simples »

Pour une raison quelconque, il existe une tension constante (du moins en ce qui me concerne) entre l’utilité de construire quelque chose pour quelqu’un et le temps qu’il faut pour construire ladite chose.

J’entends par là qu’en ce qui concerne WordPress, il est relativement facile de créer de petits plugins et utilitaires simples pour d’autres qui ne suivent pas nécessairement les meilleures pratiques modernes.

Et, en ce qui concerne cet article, je dirais que les meilleures pratiques modernes ressemblent à :

• un gestionnaire de paquets côté serveur,
• un gestionnaire de paquets côté client,
• tests unitaires appropriés,
• des cours bien conçus,
• code documenté,
• etc.

Et tout cela est formidable et sans doute nécessaire pour les projets plus importants (surtout parce que la maintenance et le développement cohérent vont jouer un rôle si important).

Rester simple

Mais qu’en est-il des petits projets où vous êtes plus ou moins le seul intendant de la base de code ? Je ne dis pas qu’il ne faut pas mettre en place de bonnes pratiques. Je pense que nous devrions:

• avoir une base de code bien documentée,
• une conception de fonction ou de classe qui répond aux développements futurs,
• et optimisation du code côté client et côté serveur

Mais cela signifie-t-il que ces projets doivent avoir de grands répertoires de fournisseurs ou de grands répertoires node_modules ?

Photo par Artur Pokusin sur Unsplash

Bref, je ne pense pas. Je pense que cela relève de la sur-ingénierie.

Rendez les choses aussi simples que possible, mais pas plus simples.

Cela ne signifie pas que nous renonçons au soin nécessaire pour écrire du code de qualité dans le cadre de notre IDE.

Lignes directrices potentielles

Mais c’est peut-être là que ça s’arrête. C’est-à-dire qu’une bonne règle de base est peut-être :

• Si le projet doit nécessiter une intégration continue, il doit disposer des garde-fous nécessaires pour faire respecter la qualité à la fois localement et dans les environnements de mise en scène et le processus d’intégration continue.
• Si le projet doit être construit puis publié (et fait de manière itérative), alors la majorité de la qualité doit être mesurée et appliquée via l’IDE.

Je ne sais pas si c’est la meilleure façon de l’aborder, mais c’est quelque chose auquel j’ai passé du temps à réfléchir et je continue d’arriver à l’ensemble ci-dessus des barrières proverbiales.

J’écris actuellement un livre électronique (avec une variété d’autres contenus premium). Si vous êtes intéressé, regardez ce que vous obtenez.