5 principes pour des applications JavaScript « bêtement géniales »

Les développeurs sont confrontés à des problèmes complexes toute la journée, tous les jours.

Nous vivons dans un monde compliqué, et il est tentant de croire que chaque problème alambiqué nécessite une solution byzantine à multiples facettes. En réalité, bien que le monde soit problématique, il est régi par des lois simples telles que la cause et l’effet, la gravité, l’énergie et la quantité de mouvement.

Nous pouvons tirer des leçons de la nature et les appliquer au code. La plupart du temps, la simplicité mène aux résultats les plus complexes.

Le code “intelligent” n’est pas la bonne solution

Il est assez facile de montrer ses compétences techniques en ajoutant des centaines de lignes de code jusqu’à ce qu’il résolve tous les problèmes, suive la logique booléenne dans tous les terriers de lapin imaginables et se transforme inévitablement en désordre.

Plus le code est “intelligent”, plus il est sujet aux bogues, plus il est difficile à déboguer et plus il est difficile à étendre et à maintenir. Travailler de cette manière rend également presque impossible l’estimation du temps nécessaire pour construire et gérer le code.

De plus, la durée de vie d’un code trop complexe a tendance à être très courte. Faire face aux bogues et à l’incertitude qui accompagnent ce type de code est frustrant, de sorte que les développeurs finissent par abandonner complètement la solution et créer autre chose. C’est une perte de temps et d’argent qui pourrait être consacré à d’autres projets.

Symptômes d’un code trop complexe

Comment savoir si votre code doit être simplifié ? Outre les problèmes généraux susmentionnés, il existe cinq façons d’identifier un code trop complexe.

1. Les fonctions prennent trop de paramètres

Trop de pièces mobiles sont mauvaises dans les machines physiques, et c’est tout aussi problématique dans le code. Les fonctions avec plus de deux paramètres (un mot-clé important en C#) sont un signal d’alarme indiquant que votre code est plus complexe qu’il ne devrait l’être.

2. La logique conditionnelle est la caractéristique dominante

Les instructions “If”, les instructions switch, la logique booléenne, les instructions ternaires et les opérateurs logiques sont autant d’opportunités pour le code d’échouer lorsqu’il se heurte à un cas limite. Trop de cette logique conditionnelle apportera souvent des problèmes.

3. Commentaires expliquant le code

Un bon code est comme une bonne blague. Si vous avez besoin d’expliquer ce qui se passe, cela ne fonctionne pas.

4. Code fragile

Un code qui casse souvent est une source de frustration au lieu d’être un outil utile. Si les tests détectent des cassures que vous n’avez pas vus, votre code est trop compliqué.

5. Difficile à suivre

Il n’y a rien de plus ennuyeux que de travailler sur un patch de code difficile et d’être interrompu à mi-parcours, pour revenir à votre bureau et réaliser que vous avez complètement perdu votre place. S’il faut 30 minutes pour comprendre sur quoi vous travailliez, ou si vous ne pouvez pas expliquer rapidement votre code aux développeurs juniors, c’est un symptôme que votre code essaie d’être trop intelligent, au lieu d’être stupidement brillant.

5 principes pour créer du code stupide à la place

Il existe une solution à tous ces problèmes. L’écriture de code simplifié ou simple et efficace permet à votre application d’être intelligente et polyvalente. Plus la solution est élégante, plus le produit fini sera poli.

Un code compliqué qui s’ajoute à chaque fois qu’un problème survient commence à ressembler à quelque chose qui a été conçu par un comité. Il est difficile à utiliser et difficile à changer. Au lieu de cela, utilisez les cinq principes suivants chaque fois que vous démarrez un nouveau projet, et vous créerez un code simple qui fera le travail à chaque fois.

1. Comprendre le problème

Quel est le but du code que vous écrivez ? Comprendre vraiment les objectifs principaux prend du temps et de l’énergie, mais cela peut vous faire gagner des heures dans la création de votre application et se traduira par un bien meilleur produit final.

Pour illustrer ce point, considérons un problème simple : étant donné les coordonnées de deux rectangles qui se croisent, écrivez un algorithme pour calculer la zone d’intersection. Il existe une myriade de façons d’aborder cette question et de créer une application qui y répondra, mais il y a un hic. Les rectangles peuvent être de n’importe quelle taille et dans presque n’importe quelle position, de sorte que les boîtiers périphériques peuvent s’éloigner rapidement de vous.

Cependant, si vous prenez du recul et réfléchissez vraiment au problème, vous vous rendrez compte d’une vérité essentielle : entre les huit coordonnées, il n’y a que quatre coordonnées distinctes. X valeurs, car les côtés sont toujours alignés. Seuls ceux du milieu importent pour trouver l’aire du rectangle d’intersection. Peu importe de quel rectangle ils font partie, seulement qu’ils sont au milieu.

Donc, si votre code peut trier les valeurs pour X, prenez les deux du milieu et trouvez la distance entre ces deux, vous avez la longueur. Appliquer le même principe à la Oui valeurs, et vous avez votre réponse. De cette façon, le code passe d’une pleine page de minuscules caractères à moins d’une douzaine de lignes (avec une fonction d’assistance), sans une seule instruction “if”.

Comprendre et simplifier le problème est probablement l’étape la plus importante dans la création d’un code stupidement brillant, alors ne sautez pas ou ne lésinez pas sur cette pièce du puzzle.

2. Découpler les idées

Quiconque a fait des études en informatique ou en informatique connaît le principe de responsabilité unique. Les fonctions fonctionnent mieux lorsqu’elles sont conçues pour faire une seule chose.

Appliquez cette idée plus largement à tout dans votre code. Séparez chaque résultat de celui qui lui est adjacent. L’interface utilisateur, la logique de l’interface utilisateur, les styles, les ensembles de données, la traduction des données, la logique métier et les intégrations tierces sont toutes des préoccupations différentes et doivent être séparées les unes des autres.

Il existe une variété de modèles architecturaux qui traitent de cela et peuvent être utilisés pour créer le type de code simple et découplé qui fonctionne à chaque fois. Le produit minimum viable, le modèle-vue-contrôleur, le modèle-vue-viewmodel et d’autres architectures et outils résolvent tous ce problème lorsqu’ils sont utilisés correctement.

3. Passez la chose au lieu des pièces pour construire la chose

Il existe des moyens plus techniques de décrire cela, mais le libellé “Passez la chose au lieu des pièces pour construire la chose” reste dans un esprit de simplicité stupide.

En résumé, cela signifie qu’au lieu d’utiliser plusieurs accessoires et étiquettes qui sont ensuite assemblés en un seul package, vous transmettez le résultat final : une image, un lien ou quoi que ce soit. Cela facilite la personnalisation ultérieure, car la chose elle-même peut être téléchargée au lieu d’essayer de décrire ses parties dans des lignes de code compliquées.

4. Refactoriser

Les écrivains modifient leur travail plusieurs fois avant de publier. Les photographes prennent des dizaines de clichés avant d’atterrir sur celui qui est parfait. Les athlètes essaient différentes techniques et entraîneurs pour affiner leur style de signature. Pourquoi le codage devrait-il être différent ?

La première ébauche de code est rarement parfaitement adaptée. C’est bien de l’envoyer s’il fait le travail. Mais, lorsque l’occasion se présente, revenir et refactoriser vous permet de simplifier le code et de le rendre meilleur qu’il ne l’était auparavant.

Reconnaissez que la refactorisation est un investissement. Cela prend du temps à d’autres choses et doit être pris en compte dans le budget. Cependant, le gain en vaut toujours la peine à la fin.

5. Développement piloté par les tests

Le développement piloté par les tests (TDD) a été couvert par de nombreuses personnes intelligentes. Robert C. Martin a écrit un livre intitulé Le codeur propre cela vous dira tout ce que vous devez savoir, mais pour les besoins de cet article, je vais vous donner la version stupidement simple.

Écrivez un (et un seul) test d’échec avant d’écrire un code de production. Écrivez juste assez de code pour réussir les tests, puis refactorisez, écrivez une autre partie et passez à autre chose. Fait correctement, TTD produit du code “stupide”, puisqu’il vous oblige à suivre les quatre autres principes.

Vous ne pouvez pas écrire un bon code piloté par les tests si vous ne comprenez pas le problème. Vous devez séparer le code, car vous ne pouvez pas tester une fonction qui fait 50 choses différentes. Cela encourage à passer la chose, et cela vous oblige à refactoriser à chaque étape du chemin.

Commence ton stupide voyage

Ce ne sont pas les seuls principes qui aident à écrire des applications stupidement brillantes, mais ils sont un excellent point de départ. Maintenant, allez et écrivez du code stupide !

Continue d’apprendre

.

Leave a Comment