Nous avons dit ceci plus tôt.
Définir un grand cadre (Module)
Diviser cela en domaines spécifiques (Class)
Définir des actions réelles à l'intérieur (Method)
Cette méthode est clairement efficace.
Cependant, les lecteurs peuvent se sentir ainsi.
"Mais... c'est toujours difficile et intimidant."
"Je ne sais toujours pas comment implémenter l'ensemble."
"Je ne sais pas comment diviser les fonctionnalités détaillées."
C'est normal.
Parce que Module-Class-Method est une "pensée structurante",
Maintenant, ce dont vous avez besoin, c'est
une "pensée de démarrage de l'implémentation" à l'intérieur de cette structure.
Deux concepts apparaissent ici.
code pseudo (pseudo code)
TDD (Test Driven Development)
Ces deux éléments
réduisent radicalement la charge lors du développement.
1) Code Pseudo - Écrivez d'abord vos pensées avant de coder
Le code pseudo est littéralement
"du texte qui ressemble à du code mais qui n'en est pas".
Au lieu d'écrire directement du code fonctionnel,
nous écrivons d'abord ceci.
Par exemple, si vous voulez créer une fonction de connexion :
L'utilisateur saisit son email et son mot de passe
Recherche l'utilisateur ayant cet email dans la base de données
Vérifie si le mot de passe est correct
Crée un état de connexion réussie s'il est correct
Affiche un message d'erreur s'il est incorrect
Ce n'est ni du Ruby ni du Python.
C'est simplement un "flux de pensée".
Cependant, chaque ligne
devient une méthode,
une classe,
et entre dans la structure du module.
Si vous écrivez simplement les petites actions dans l'ordre sans vous soucier du grand schéma, la moitié du problème est déjà résolue.
C'est le pouvoir du code pseudo.
Le plus grand avantage du code pseudo
Vous pouvez concevoir des fonctionnalités sans connaître le code
Vous pouvez diviser des fonctionnalités complexes en phrases simples
L'anxiété de "par où commencer" disparaît
Moins d'erreurs lors de l'écriture du code réel plus tard
Une personne compétente en programmation
n'est pas quelqu'un qui écrit bien du code,
mais quelqu'un qui sait clairement expliquer le problème avant d'écrire du code.
2) TDD (Test Driven Development) - Écrivez d'abord les tests, puis remplissez le code
Le TDD commence ainsi.
"Définissez d'abord le comportement souhaité par écrit,
puis créez le code qui le passe plus tard."
C'est inverser l'ordre.
Par exemple, pour créer une fonction qui ajoute deux nombres,
vous écrivez d'abord un test comme ceci.
expect(add(2, 3)).to eq(5)
Cette phrase signifie :
"Il doit y avoir une fonction add"
"Si vous entrez 2 et 3"
"Le résultat doit être 5"
Ce test échoue initialement, bien sûr.
Pourquoi ? Parce que la fonction add n'existe pas.
Ensuite, pour résoudre cet échec,
vous ajoutez un code minimal.
def add(a, b)
a + b
end
Et le test devient vert (réussite).
Ce processus a pour effet d'inculquer naturellement
la manière de développer en divisant les fonctionnalités en petites unités.
L'effet puissant du TDD
Vous n'avez pas besoin de créer une fonctionnalité énorme en une seule fois
Vous ne devez penser qu'aux petites unités de fonctionnalité (niveau de méthode)
Votre pensée devient plus claire, réduisant radicalement les erreurs
Comme un assistant de conduite automatique, il vous indique si vous faites bien
Plus la fonctionnalité devient complexe, plus elle apporte de valeur
En d'autres termes, le TDD est
la méthode la plus efficace pour assembler un grand problème en petits blocs.
Code Pseudo + TDD = Une manière de penser le développement comme assembler des blocs Lego
Lorsque vous utilisez ces deux éléments ensemble,
le problème devient considérablement plus facile.
1. Écrivez le flux global en pseudo code
→ Pensez à créer un manuel Lego.
2. Implémentez-en un à la fois en le faisant passer par le TDD
→ Pensez à assembler un bloc Lego à la fois.
Cette méthode est
le flux de travail le plus stable pour implémenter
la structure Module → Class → Method.
La programmation n'est pas effrayante.
Parce que tous les problèmes
sont divisés en petites pièces,
en réussissant chaque pièce une par une,
le tout est naturellement construit.
Le lecteur réalise quelque chose ici
"Ah... J'essayais de tout finir en une fois, c'est pourquoi cela semblait difficile."
"Si je décris d'abord en pseudo code et réussis un par un avec TDD,
même une fonctionnalité complexe finira par être complétée.""Si c'est comme assembler des Lego...
je peux aussi créer de grands projets !"
Lorsque cette réalisation survient,
le lecteur ne commence plus le développement dans la peur.
Au lieu de cela, il acquiert un "état d'esprit de division et de composition".