Écrire un meilleur code pour les projets basés sur WordPress

Je ne me souviens pas exactement quand je suis tombé sur le blog de Joel Spolsky, Joel on Software, mais c’était à un moment donné à la fin du lycée.

Je n’en savais pas assez sur l’ensemble du processus de développement logiciel pour comprendre vraiment ce dont il parlait, mais j’ai apprécié son style d’écriture et j’ai apprécié ce qu’il avait à dire.

En fait, j’étais tellement fan que lorsque j’ai obtenu mon diplôme, j’ai continué à acheter ses livres (qui étaient des recueils d’articles sur son site) et à les lire d’un bout à l’autre. J’en gardais des copies sur mon bureau au travail et j’ai utilisé l’un de ses livres – Smart and Gets Things Done – lorsque j’étais chef d’équipe.

Les articles qui m’ont le plus marqué, cependant, étaient ceux qui parlaient d’écrire un meilleur code. Voici la chose, cependant: ces articles n’incluaient rien sur l’écriture de code.

Écrire un meilleur code

Au lieu de cela, tout était question de processus autour d’un meilleur code. Et je suis tombé sur un article – vieux de 16 ans, quand même – et je le trouve toujours aussi pertinent aujourd’hui que lorsque je l’ai trouvé pour la première fois.

Sauf que maintenant, je me demande comment cela s’applique à mon travail de développement actuel.

Le test Joël

Premièrement, l’article en question est celui que je me surprends à lire au moins une fois par mois – sinon au moins une fois par semaine – et je tourne tout autour de ce qu’il appelle The Joel Test. Ce sont douze questions que vous posez à votre équipe de développement actuelle.

1. Utilisez-vous le contrôle de code source ?
2. Pouvez-vous faire une construction en une seule étape?
3. Faites-vous des builds quotidiens ?
4. Avez-vous une base de données de bugs ?
5. Corrigez-vous les bogues avant d’écrire un nouveau code ?
6. Avez-vous un planning à jour ?
7. Avez-vous un cahier des charges ?
8. Les programmeurs ont-ils des conditions de travail calmes ?
9. Utilisez-vous les meilleurs outils que l’argent peut acheter ?
10. Avez-vous des testeurs ?
11. Les nouveaux candidats écrivent-ils du code lors de leur entretien ?
12. Faites-vous des tests d’utilisabilité dans les couloirs ?

Étant donné que ces questions ont été écrites il y a 16 ans et sont largement basées sur du code compilé, une partie de la terminologie pourrait devoir être ajustée.

La chose intéressante à propos du test Joel est qu’il est facile d’obtenir un oui ou un non rapide à chaque question. Vous n’avez pas à calculer le nombre de lignes de code par jour ou le nombre moyen de bogues par point d’inflexion. Donnez à votre équipe 1 point pour chaque réponse "oui".

Par exemple, plutôt que de demander si vous pouvez faire une construction en une seule étape, peut-être devrions-nous demander si nous pouvons faire un déploiement en une seule étape. Vous savez ce que je veux dire – faire des ajustements à des choses comme ça.

Deuxièmement, certaines questions doivent être adaptées aux équipes distantes car nous ne sommes plus tous dans le même bureau. Autrement dit, plutôt que de faire des tests d’utilisabilité dans les couloirs, vous devrez peut-être saisir quelqu’un que vous connaissez en ligne, l’envoyer dans votre environnement de test et lui poser des questions sur le projet.

Le test Joel pour WordPress

Peut-être que, pour ceux d’entre nous qui utilisent WordPress comme base de développement, notre ensemble de questions ressemblerait à ceci :

1. Utilisez-vous le contrôle de code source ?
2. Pouvez-vous faire un déploiement en une seule étape ?
3. Faites-vous des déploiements quotidiens ?
4. Avez-vous une base de données de bugs ?
5. Corrigez-vous les bogues avant d’écrire un nouveau code ?
6. Avez-vous un planning à jour ?
7. Avez-vous des exigences et des maquettes ?
8. Les programmeurs ont-ils des conditions de travail calmes ? Ou, s’ils sont à distance, les programmeurs sont-ils autorisés à passer en mode « Ne pas déranger » ?
9. Utilisez-vous les meilleurs outils du marché, soit quelque chose de gratuit et open source, soit quelque chose de premium ?
10. Avez-vous des testeurs? (Et je pourrais demander si le budget du projet permet également d’écrire des tests unitaires pour les tests automatisés) ?
11. Les candidats ont-ils des exemples de code disponibles sur GitHub, un blog ou un emplacement accessible au public qui peuvent être examinés ?
12. Avez-vous un groupe de personnes à partir duquel vous pouvez puiser pour tester votre travail en cours ?

Encore une fois, cela repose en grande partie sur l’idée d’une petite équipe distante plutôt que sur une grande société ou agence de produits au niveau de l’entreprise. Mais c’est quelque chose sur lequel je reviens encore de temps en temps et je me demande comment les autres magasins se comparent les uns aux autres.

Oh, et toute cette histoire de score ?

Un score de 12 est parfait, 11 est tolérable, mais 10 ou moins et vous avez de sérieux problèmes. La vérité est que la plupart des organisations de logiciels fonctionnent avec un score de 2 ou 3, et elles ont besoin d’une aide sérieuse…

Nous avons tous quelque chose à viser, n’est-ce pas ?

Pour la prochaine décennie ?

Ce n’est pas tant que je pense que c’est un concours, mais je sais que j’aimerais pouvoir répondre oui à la plupart de ces questions pour moi et pour ceux avec qui je travaille.

Mais au moment de cet article, je peux dire que je ne peux pas dire oui à tout cela, et encore moins peut-être à la moitié d’entre eux. Peut-être que d’ici la fin de l’année, je peux, cependant.

Et peut-être que le reste d’entre nous travaillant dans l’industrie peut évaluer nos équipes par rapport à ces questions. Bien qu’Internet et les technologies connexes évoluent rapidement, ces questions ont bien résisté pendant plus d’une décennie.