Frontend Fundamentals

Le chapitre Frontend de Toss a publié un site présentant les critères qu’il considère comme ceux d’un bon code frontend.

• Explications basées sur TypeScript, principalement utilisé par les développeurs frontend
• Présente des best practices selon quatre points de vue : lisibilité, prévisibilité, cohésion et couplage
• Fournit des exemples utilisant des bibliothèques fréquemment employées en frontend réel

4 critères

1. Lisibilité
   La lisibilité (Readability) désigne le degré de facilité avec lequel le code peut être lu. Pour qu’un code soit facile à modifier, il faut d’abord pouvoir comprendre quel comportement il a.

2. Prévisibilité
   La prévisibilité (Predictability) désigne à quel point les collègues avec qui l’on collabore peuvent anticiper le comportement d’une fonction ou d’un composant. Un code hautement prévisible suit des règles cohérentes, et permet de comprendre son comportement rien qu’en regardant le nom des fonctions ou composants, leurs paramètres et leurs valeurs de retour.

3. Cohésion
   La cohésion (Cohesion) désigne le fait que le code à modifier doive toujours être modifié ensemble. Un code à forte cohésion n’entraîne pas d’erreurs involontaires dans d’autres parties lorsqu’on modifie une section du code. En effet, sa structure garantit que les éléments qui doivent être modifiés ensemble le soient effectivement.

4. Couplage
   Le couplage (Coupling) désigne l’étendue de l’impact lorsqu’on modifie le code. Un code facile à modifier est un code dont l’impact reste limité lorsqu’il change, ce qui permet d’anticiper le périmètre des modifications.

[savvykang]

Je me demande pourquoi le fichier est utilisé comme unité minimale de gestion pour les composants et les hooks. J’imagine que cela peut venir d’un support IDE insuffisant ou du manque de tree shaking, mais je n’en suis pas certain, donc je me permets de poser la question.

En lisant du code, quand je vois des fichiers qui ne contiennent qu’une seule fonction, ou des fichiers index.ts qui ne contiennent que des instructions import et export, j’ai l’impression que cela augmente le nombre de choses à retenir. Par rapport à une approche où hooks et composants sont mélangés dans un seul fichier, je trouve que cette organisation augmente inutilement la charge cognitive. Malgré cela, y a-t-il des avantages ou des raisons à adopter ce type d’organisation ?

[firea32]

En général, le grand postulat de ce qu’on appelle ici le « bon développement », c’est que beaucoup de développeurs travaillent dessus.
Ce que vous dites sur le fait qu’il y a plus de choses à retenir signifie que vous portez la responsabilité de l’ensemble du projet, mais
dans un environnement avec beaucoup de développeurs, chacun ne développe que la partie dont il est chargé.
Quand un problème survient, il suffit de regarder cette partie, sans avoir à examiner toutes les parties liées.
D’une certaine manière, j’y vois un choix de la productivité plutôt qu’une optimisation extrême.

[savvykang]

Comme vous l’avez dit, dans un environnement où il est possible de subdiviser finement la répartition des tâches, le contenu principal constitue le bon choix. Je pense que l’article serait plus abouti s’il expliquait les compromis et les critères de décision à prendre en compte lors de la séparation du code.

[beenzinozino]

Dans mon cas, lorsque je fais du développement frontend, les raisons pour lesquelles j’utilise un fichier comme unité minimale de gestion pour un composant ou un hook sont les suivantes.

1. Facilité des tests.

Autrement dit, il est plus facile d’associer un test unitaire à un module.

Je pense que le développement frontend repose en grande partie sur un paradigme fondé sur les fonctions pures, et s’il y a plusieurs fonctions dans un même fichier, il devient difficile d’établir une correspondance 1 pour 1 au moment d’écrire des tests unitaires.

Par exemple, si plusieurs fonctions utilitaires existent dans un seul fichier appelé remark-plugin.js, comment faut-il écrire les tests ? Est-ce un bon choix de créer un seul fichier remark-plugin.test.js et d’y écrire en bloc les tests de plusieurs fonctions utilitaires ?

Dans ce genre de situation, si l’on crée un répertoire appelé remark-plugins et qu’on y sépare les fonctions utilitaires une par une pour écrire les tests, je pense qu’il y a des avantages comme rendre le rôle de chaque fonction plus clair par la suite, ou encore obtenir un suivi des commits GitHub bien plus propre.

2. Structuration des répertoires

Dans le développement serveur, avec commonjs, ou côté client, avec des module bundlers comme webpack, il arrive souvent que le fichier index.js soit désigné comme point d’entrée d’un répertoire donné. C’est aussi une convention très utilisée depuis longtemps, donc il y a en partie une forme d’acceptation par habitude.

Mais à mon avis, la raison la plus importante est que, dans le paradigme des fonctions pures de la programmation fonctionnelle, il ne faut pas dépendre d’un état externe ; donc, si plusieurs fonctions sont regroupées dans un même fichier, je pense que la probabilité de faire l’erreur de référencer un état externe augmente. (Il peut être utile de réfléchir à la raison pour laquelle le module scope est apparu en ES6.)

3. Facilité du suivi des commits.

Personnellement, j’ai l’impression que lorsqu’une fonction est découpée dans son propre fichier, plutôt que plusieurs fonctions utilitaires mélangées dans un seul, il devient beaucoup plus simple de suivre l’historique des commits.

Quand une fonctionnalité est ajoutée ou qu’un bug est corrigé dans un module, il suffit de se concentrer sur ce seul module, sans avoir besoin de se référer aux autres.

---

En écrivant, le texte est devenu plus long que prévu, donc c’est peut-être un peu décousu. (Je préfère encore ne pas trop m’avancer sur le tree shaking, car ma compréhension du sujet reste limitée...) Bien sûr, ce que je dis n’est pas forcément la bonne réponse, donc j’aimerais que vous le preniez simplement comme élément de référence !

[thkimdev]

C’est bien, ça.

[illiil1lii]

C’était vraiment bien écrit et très agréable à lire. Je le recommande.

[tsboard]

Merci pour le partage ! Moi aussi, je vais devoir le lire attentivement.

[bbulbum]

Même si c’est écrit en se limitant au front-end, j’ai l’impression que ce sont des idées très utiles à appliquer à n’importe quel logiciel. Merci d’avoir partagé ces bonnes pistes de réflexion.