Share
Les odeurs de code et leur refactorisation peuvent être très intimidantes et intimidantes pour les débutants. Donc, dans cette série, j'ai essayé de les rendre faciles à comprendre, à la fois pour les développeurs Ruby légèrement expérimentés et les débutants..
Ce dernier article mentionne quelques odeurs supplémentaires à surveiller et résume les objectifs de cette petite série. Une dernière bouffée, si vous voulez…
Le dernier article de cette série ressemble à un tour de bonus. Je voulais vous présenter quelques autres odeurs qui peuvent être traitées rapidement et sans problème. Un pour la route, pour ainsi dire. Je pense qu'avec les connaissances que vous avez acquises dans les articles précédents, la plupart d'entre eux n'auront même pas besoin d'exemples de code pour comprendre..
Lorsque vous ouvrez un livre sur la refactorisation, vous trouverez facilement plus d'odeurs que ce dont nous avons discuté. Cependant, avec ces principaux à votre ceinture, vous serez bien préparé pour traiter avec l'un d'eux.
Les commentaires généreusement appliqués sont rarement une bonne idée - probablement jamais. Pourquoi pas? Parce que cela pourrait suggérer que votre conception ne parle pas pour elle-même. Cela signifie que votre code est probablement si compliqué à comprendre qu'il nécessite des explications littérales..
Tout d’abord, qui veut parcourir des trésors de texte dans votre code - ou pire, à travers un code difficile à comprendre. Jackpot si les deux sont une occurrence commune. C'est juste une mauvaise forme et pas très prévenant envers les gens qui viennent après vous - aucune offense, masochistes, ne vous torturez pas votre avenir tout ce que vous voulez.
Vous voulez écrire un code assez expressif en soi. Créez des classes et des méthodes qui parlent d’elles-mêmes. Dans le meilleur des cas, ils racontent une histoire facile à suivre. C'est probablement l'une des raisons conventions sur les configurations est devenu si influent. Réinventer la roue est certes parfois une bonne pratique pour affiner votre compréhension et explorer de nouveaux territoires, mais dans des environnements de développement rapides, vos collègues recherchent la clarté et une navigation rapide - non seulement dans vos fichiers, mais également dans la carte mentale que vous créez. dans votre code.
Je ne veux pas me perdre dans un tout nouveau sujet, mais nommer joue un rôle important dans tout cela. Et les commentaires excessifs dans votre code sont légèrement en contradiction avec les bonnes pratiques et conventions de nommage. Ne vous méprenez pas, c'est bien d'ajouter des commentaires - restez sur le chemin qui «éclaire» votre code plutôt que de le distraire. Les commentaires ne doivent certainement pas être des instructions pour un code intelligent que vous pouvez généralement déchiffrer parce que vous vouliez vous montrer. Si vous gardez vos méthodes simples - comme vous devriez le faire - et nommez tout avec considération, vous n'avez alors que peu besoin d'écrire des romans entiers entre votre code.
Restez à l'écart de ce qui suit:
Il est également utile de décomposer des parties de méthodes via méthode d'extrait et attribuer à cette partie de la méthode un nom qui nous en dit plus sur sa responsabilité plutôt que de laisser tous les détails encombrer une compréhension de haut niveau de ce qui se passe dans le corps de la méthode.
def create_new_agent… end… # créer une nouvelle visite d'agent chemin_processus click_on 'Créer Agent' fill_in 'Nom de l'agent', avec: 'Jinx' fill_in 'Email', avec '[email protected]' fill_in 'Mot de passe', avec: 'secretphrase 'click_button' Soumettre '…
Qu'est-ce qui est plus facile à lire? Une évidence, bien sûr! Utilisez le kilométrage gratuit que vous obtenez en nommant les choses correctement via des méthodes extraites. Cela rend votre code beaucoup plus intelligent et plus facile à digérer, en plus des avantages de la refactorisation en un seul endroit si elle est réutilisée, bien sûr. Je parie que cela aidera à réduire vos commentaires d'un montant très important.
C'est simple. N'utilisez pas de rappels qui ne sont pas liés à la logique de persistance! Vos objets ont un cycle de vie de persistance - création, sauvegarde et suppression d'objets, pour ainsi dire - et vous ne souhaitez pas «polluer» cette logique avec un autre comportement, comme la logique métier de vos classes..
Gardez les choses simples, souvenez-vous? Les exemples typiques de ce qu’il faut éviter sont l’envoi de courriels, le traitement des paiements, etc. Pourquoi? Parce que le débogage et la refactorisation de votre code doivent être aussi simples que possible, et que les rappels désordonnés ont la réputation d’interférer avec ces plans. Les callbacks rendent un peu trop facile de brouiller les pistes et de se tirer dans le pied plusieurs fois.
Un autre problème des rappels est qu’ils peuvent masquer l’implémentation de la logique métier dans des méthodes telles que #enregistrer ou #créer. Donc, ne soyez pas paresseux et abusez-vous juste parce que cela semble pratique!
La plus grande préoccupation est le couplage des préoccupations, bien sûr. Pourquoi laisser la méthode create de SpectreAgent, par exemple, traiter de la livraison d’un #mission_assignment ou quelque chose? Comme souvent, ce n'est pas parce que nous pouvons le faire facilement que nous devrions le faire. C'est une garantie de morsure dans le cul qui va arriver. La solution est en fait assez simple. Si le comportement d'un rappel n'a rien à voir avec la persistance, créez simplement une autre méthode et vous avez terminé..
Les mauvais choix de nommage ont des conséquences graves. En fait, vous gaspillez le temps des autres personnes, ou même mieux le vôtre, si vous devez revoir ce code ultérieurement. Le code que vous écrivez est un ensemble d'instructions à lire par vous-même et par d'autres personnes. Une approche purement logique, super prosaïque, trop astucieuse, ou pire, de nommer des noms est l'une des pires choses que vous pouvez laisser derrière. Essayez de rendre votre code plus facile à comprendre en fournissant de meilleurs noms..
La clarté l'emporte sur la fausse intelligence ou la concision inutile tous les jours de la semaine! Travaillez dur sur les méthodes de nommage, les variables et les classes qui facilitent le suivi d'un fil de discussion.
Je ne veux pas aller jusqu'à dire que vous devriez avoir pour objectif d'essayer de raconter une histoire, mais si vous le pouvez, foncez! Les machines ne sont pas celles qui ont besoin de "lire" votre code - c'est elles qui les gèrent, bien sûr. C'est peut-être l'une des raisons pour lesquelles le terme «éditeur de logiciel» s'est un peu développé sur moi ces derniers temps. Je ne dis pas que l'aspect technique devrait être diminué, mais écrire un logiciel, c'est plus qu'écrire des instructions sans âme pour des machines - du moins un logiciel élégant et qui procure du plaisir à travailler avec.
Ne paniquez pas si cela s'avère beaucoup plus difficile que vous ne le pensiez. Nommer est notoirement difficile!
Les mixins sont une odeur? Eh bien, disons qu'ils peuvent avoir une odeur. Les héritages multiples via Mixins peuvent être utiles, mais plusieurs facteurs les rendent moins utiles que vous ne le pensiez quand vous avez commencé avec OOP:
Je vous suggère de lire un peu sur «Composition sur l'héritage». L'essentiel est que vous devriez davantage vous fier à la réutilisation de vos propres classes, composées séparément, qu'à l'héritage ou au sous-classement. Les mixins sont une forme d’héritage qui peut être utilisée à bon escient, mais qui doit également être un peu suspecte..
Faites attention à passer à plusieurs reprises les mêmes arguments multiples dans vos méthodes. Cela suggère souvent qu’ils ont une relation qui peut être extraite dans une classe à part, ce qui peut souvent simplifier considérablement l’alimentation de ces méthodes avec des données en réduisant la taille des arguments. Que ce soit la peine d'introduire une nouvelle dépendance est la chose que vous devez peser, bien que.
Cette odeur est une autre forme de duplication subtile que nous pouvons mieux gérer. Un bon exemple consiste à transmettre une longue liste d'arguments constituant une adresse et des informations de carte de crédit. Pourquoi ne pas regrouper tout cela dans une classe existante, ou extraire d’abord une nouvelle classe et transmettre à la place les objets adresse et carte de crédit? Une autre façon de penser est d'avoir un objet de plage au lieu d'un début et d'une fin. Si vous avez des variables d'instance qui tombent pour cette odeur, l'extraction d'une classe vaut la peine d'être envisagée. Dans d'autres cas, un objet paramètre pourrait offrir la même qualité d'abstraction.
Vous saurez que vous avez obtenu un petit gain si votre système est plus facile à comprendre et si vous avez trouvé un nouveau concept de carte de crédit, que vous pouvez encapsuler dans un objet..
Toutes nos félicitations! Vous avez considérablement amélioré vos compétences en POO! Le niveau de boss approche. Non, sérieusement, excellent travail si tout ce sujet était plutôt nouveau pour vous!
En guise de recommandation finale, je veux que vous reteniez une chose. S'il vous plaît rappelez-vous qu'il n'y a pas de recette qui fonctionnera toujours. Vous devrez peser chaque problème différemment et mélanger souvent des techniques différentes pour répondre à vos besoins. En outre, pour le reste de votre carrière, il est fort probable que vous ne cessiez jamais de vous battre. Je suppose que c'est un bon combat, mais créatif et stimulant..
C'est une petite supposition, mais je pense que si vous comprenez la plupart des sujets que nous avons abordés, vous serez sur la bonne voie pour écrire du code que les autres développeurs aiment découvrir. Merci pour votre temps à lire cette petite série et bonne chance pour devenir un hacker heureux!
Accentsconagua