Notes d'amélioration du code difficile à lire

"Ne détestez pas les gens, détestez le code."

Même ainsi, est-ce que tout le monde a l'expérience de penser comme ça plus d'une fois? Avec quel type de code Umi-sensei s'est-il fâché? Et que dois-je faire?

Quand j'ai écrit un tel code, j'aimerais revenir sur mon code et mes actions et le résumer pour pouvoir écrire un code qui n'offense pas le professeur Ohara. C'est écrit de manière simple pour tout le monde, mais j'apprécierais que vous me pardonniez.

Qu'est-ce qu'un code difficile à lire?

1. Suffisamment long pour nécessiter un défilement pour lire un seul processus. Le nombre de lignes, 100 lignes ou plus.
2. L'expression conditionnelle de l'instruction if est longue.
3. Il existe de nombreuses branches dans l'instruction if.
4. Il y a une instruction if dans l'instruction if, et ... la boucle infinie fait peur, n'est-ce pas?
5. Les noms de méthodes et les noms de variables sont abstraits.

N'est-ce pas comme ça?

Quel est le problème avec l'écriture de code difficile à lire!

1. Je ne veux pas le lire en premier.
2. C'est mon travail, donc je n'ai pas d'autre choix que de lire le code. C'est aussi très concentré.
3. Dites «Je ne sais pas pourquoi» et sortez prendre un café fatigué. J'ai mal aux yeux. Et ne plus jamais regarder.
4. Je veux l'implémenter, mais il faut du temps pour comprendre le code et le temps supplémentaire est gaspillé.
5. J'ai peur quand j'essaye de le mettre en œuvre. Et je ne veux plus m'impliquer à nouveau dans ce code.
6. Le problème est que ce phénomène est le même pour la personne qui a écrit le code.
7. Je ne sais pas où frapper cette colère si la personne qui l'a écrite est transférée dans une autre équipe (Idadan ... Joudandesu? Joudan ...)

La quantité de travail qui serait autrement faible est gonflée en raison du travail supplémentaire de «compréhension du code complexe, mystérieux et difficile à lire», ce qui entraîne des opportunités perdues. De plus, ** des fonctions ajoutées et des fonctions existantes peuvent provoquer une réaction chimique pour créer de nouveaux bogues **. Et relisez le code à nouveau pour corriger le bogue ... juste ** spirale négative! !! ** **

Si vous écrivez comme un passe-temps personnel, ce serait bien si vous pouviez vous satisfaire, mais si vous le développez en équipe ou le gérez après la livraison, le crime du code difficile à lire est très profond.

Comment puis-je créer du code difficile à lire?

Par exemple, dans un jeu sur smartphone, il y a des quêtes, mais en cours de démarrage d'une quête,

• Essayez-vous de démarrer une quête pendant la période? -Est-ce que vous remplissez les conditions pour jouer cette quête? ―― Quel genre d'ennemis sortira? ―― Quel genre de récompense obtiendrez-vous si vous battez l'ennemi? -Est-ce que le membre de la quête triche? -L'objet que vous apportez à la quête est-il frauduleux?

(Je pense qu'il y en a d'autres selon le jeu). Si vous écrivez ces différents processus tels quels dans une seule méthode, vous pouvez créer du code difficile à lire. En fait, il est ** oui ** d'écrire ces processus dans une seule méthode (car vous pouvez en faire un rôle de contrôleur de quête et l'appeler avec l'API), mais il est dangereux de l'écrire trop docilement.

Comment écrire du code qui n'est pas difficile à lire?

Voici ce que je fais actuellement pour corriger mon code afin qu'il ne devienne pas un héritage négatif.

Créer une méthode pour chaque fonction

Le code est long car il implémente diverses fonctionnalités. Donc, n'écrivez pas le code tel quel, mais pour chaque fonction

-Est-ce une quête pendant la période? => check_quest_period () -Remplissez-vous les conditions de jeu de quête? => is_playable_quest () ―― Quel genre d'ennemis apparaîtra? => select_enemy ()

Créez une méthode comme celle-ci et appelez-la.

En faisant cela, par exemple, si vous devez "ajouter une nouvelle spécification à la méthode de loterie de l'ennemi", vous pouvez commencer à travailler rapidement car vous n'avez qu'à regarder select_enemy () sans lire les autres processus. Si select_enemy () est long, il est fort probable que plusieurs fonctions soient implémentées telles quelles, donc divisons-les en méthodes pour chaque fonction.

Faire de l'instruction if une méthode

La condition de l'instruction if est longue et il existe de nombreuses branches, selon les spécifications. Dans ce cas, si vous faites de l'instruction if une méthode, vous pouvez comprendre ce que vous faites simplement en regardant le nom de la méthode, ce qui aide à déchiffrer l'instruction if.

Par exemple, le traitement des quêtes

quest_start.py

class QuestStartManager(object):
    @classmethod
    def quest_start(cls, player, quest, now_datetime)
        #Vérifiez si la quête est en cours
        if quest.start_datetime > now_datetime or now_datetime > quest.end_datetime:
           raise OutOfPeriodError

        #Vérifiez si les conditions de lecture de la quête sont remplies
        if player.level < quest.need_level or quest.need_clear_quest_id not in player.clear_quest_ids ou (Omis car il ne peut pas être écrit):
           raise PlayerQuestStatusIsNotPlayableError

(Ci-après, le code est omis)

Je ne veux plus le lire rien qu'en regardant ça ... c'est juste quelques lignes! si déclaration ... un enfant effrayant!

quest_start

class QuestStartManager(object):
    @classmethod
    def quest_start(cls, player, quest, now_datetime):
        check_quest_period(quest, now_datetime)
        is_playable_quest(player, quest)

Que dis-tu de ça? N'est-il pas plus facile à lire que l'instruction if est écrite directement? Une instruction if est écrite dans chaque méthode, mais vous pouvez imaginer à partir du nom de la méthode, "C'est un contrôle de période" ou "Est-ce qu'il vérifie si vous pouvez jouer la quête?"

Écrire des noms de méthodes et des noms de variables spécifiques

Je pense qu'un code court comme celui ci-dessous est acceptable (ce n'est qu'un exemple, et je l'écris en fait comme essayez ... sauf. Je vais excuser juste au cas où).

quest.py

class Quest(models.Model):
    @classmethod
    def get_quest(cls, quest_id):
        obj = cls.objects.get(quest_id)
        if obj:
            return obj
        else:
            return None

Mais que faire si vous écrivez ce nom de variable obj dans un long processus? Si cet "obj" apparaît à de nombreux endroits pendant que vous faites défiler, vous serez inquiet. ** "De quel objet s'agit-il !!" ** Vous voudrez mettre un tsukkomi.

Si le nom de la méthode est juste get_obj () ou update_obj (), vous ne saurez pas quel objet vous essayez d'obtenir ou de mettre à jour, et vous douterez de la fiabilité de ce code.

Au moment de décider d'un nom, ** le nom est inhabituellement long (il y a plusieurs verbes) ** ou ** je pense à un nom, mais quand je m'inquiète du type de nom qui convient **, il est presque ** surchargé de fonctions dans la méthode ** Alors coupons la fonction.

Je veux dessiner un commentaire en détail! !! Si oui, arrêtons

Des syndromes que vous souhaitez écrire en détail se produisent souvent. J'analyse que c'est parce que l'état psychologique dans lequel les autres responsables ne comprendront pas le contenu du code que j'ai écrit est exposé (je suis).

C'est ridicule de le laisser tel quel! !!

Voyons s'il peut être divisé en méthodes pour chaque fonction.

Design pattern

** C'est un processus compliqué, donc il ne peut pas être aidé s'il devient difficile à lire **. Dans ce cas, demandez-vous si vous pouvez utiliser un modèle de conception. Il y a peut-être une solution là-bas. alors. Si c'est un modèle de conception.

Inclure l'effort de refactoring dans l'estimation

Rappelez-vous les examens que vous aviez lorsque vous étiez étudiant. L'enseignant n'a-t-il pas dit «Veuillez revoir»? Peu importe la qualité des élèves, ils commettront des erreurs. C'était ** examen ** pour éviter cela.

C'est la même chose pour l'implémentation du code. Parfois, je pensais que c'était bien quand je l'ai conçu et mis en œuvre, mais au fur et à mesure que le travail progressait, cela s'est transformé en quelque chose de mauvais. Même la personne qui a écrit que c'était terrible peut avoir un code comme "Qu'est-ce que c'est? Qu'est-ce que c'est?"

Disons au directeur d'inclure l'effort d'examen dans l'effort de mise en œuvre estimé.

Je pense que «bouger sans problèmes» n'est autorisé que dans le cadre de loisirs personnels. (Dites-vous (larmes sanglantes)) Les extensions et les corrections de bogues se produiront tant que le service continuera. ** Pouvez-vous dire que ce code prendra soin de vous pour toujours? ** **

** Avis important. ** **

Écrivons le code de test

Si vous pouvez écrire du code facile à lire depuis le début, vous n'aurez peut-être pas besoin de ce genre de travail ... Non, quel que soit le test, des retouches se produiront (je veux croire).

• Séparez le processus en méthodes.
• Faire du traitement de l'instruction if une méthode.

Et, si vous modifiez le processus qui fonctionnait jusqu'à présent, cela peut provoquer un bogue.

Mais il serait prudent d'avoir un code de test. J'obtiens une erreur lorsque j'exécute le test! !! Et si le test réussit, vous pouvez demander au débogueur de le déboguer en toute confiance.

Le test unitaire est également couvert ici publié sur notre calendrier de l'Avent, veuillez donc vous y référer également.

Jusqu'à ce que vous puissiez automatiser les tests unitaires

Aussi, mon message est également w À propos du test

finalement

Après la sortie, nous devons mettre en œuvre les mesures, donc cet effort devient assez difficile. De plus, le code qui était facile à lire avant sa sortie a tendance à devenir plus difficile à lire avec le temps. Si vous souhaitez fournir le service pendant une longue période et de manière solide, je pense que vous devriez planifier le temps de refactoring et le temps de mise en œuvre du test unitaire, même après la publication. Et améliorons-nous ** progressivement **.

Si vous livrez le système à un client et que vous devez corriger un bogue, le code difficile à lire entraînera une estimation inexacte (j'ai bien peur que j'aimerais économiser du travail supplémentaire, mais le client sera sûrement en désaccord. Quand cela arrive, l'esprit du personnel de vente est malade ...). Un code difficile à lire est vraiment un péché.

J'aimerais travailler sur ce qui précède pour que le code que j'ai écrit ne soit au moins "pas difficile à lire".