Développement Rails : conventions de codage et meilleures pratiques

Qu'est-ce qu'il y a dans un nom

A good name answers important questions. What does it contain? What does it mean? How would I use it?
What  role  does  it  play?
Always name your methods based on their behaviour, not implementation.
Consider,

By looking at the method name above, we can predict it’s going to perform 2-3 database operations, but
when I’m working in Business model, why would it concern me?
Going  by,  naming  method  based  on  their  business  role,  the  method  can  be  renamed  as,

Dénomination structurelle

Another common strategy is to name things for their role in the program. It’s the input or the output. It’s the recurring phrase or the middle sentence.  Consider the code for counting differences between two points;

Here the arguments first and second are pretty vague, considering the fact that we’re not even sure if the order matters. In this context, it doesn’t.
I can then restructure my code as;

Ce que nous pouvons en conclure, c’est que la première étape consistait à décrire le problème en anglais. Le calcul de la distance entre deux brins concerne le nombre de mutations rencontrées entre les deux brins.

Refactorisation

La réorganisation du code est généralement assez triviale. Le plus délicat est de savoir par où commencer et de reconnaître que vous pouvez le faire. Pour surmonter cet obstacle, il suffit de le faire plusieurs fois. Trouvez un conditionnel et pour chacun de ses blocs, créez un objet dont la seule responsabilité est de faire cette chose.

Refactoring is about recognizing a snippet of code as exhibiting characteristics that are known to be problematic.Applying a change that is known to fix this category of problem.
This problematic pattern is called Code Smell, “code smell is a surface indication that usually corresponds to a deeper problem in the system.” – Martin Fowler
Starting small is never a bad idea, if you can refactor code at micro level, then when it all comes together, it will become a refactored code.
Consider two code snippets for example,

                      

Quelle est la similitude entre les morceaux de code ci-dessus ? Les deux ont chaque boucle, et si nous essayons de trouver leur code qui sent mauvais,

• Une boucle avec une variable temporaire.
• Une boucle avec un conditionnel imbriqué.

Essayons de les refactoriser

La première boucle n'a qu'une variable temporaire, qui peut être corrigée en utilisant 'inject'

Celui-ci a deux variables temporaires et une boucle imbriquée, puisque nous essayons de les classer, sort_by devrait fonctionner !. Le code peut être encore plus refactorisé, puisque nous essayons de trouver la valeur maximale, nous pouvons directement utiliser la fonction max_by ici,

Pratiques générales

• What if we devise a set of rules to follow while coding, that later on reduces our efforts in refactoring.
  The most basic and important point is FORMATTING. It sounds like the most obvious and easy thing to do but it’s very important to format your code correctly. In terms of code readability, understanding for future references, and also while resolving conflicts that occur while merging two different branches.
• Lorsque vous écrivez une condition if avec plusieurs sous-conditions, essayez toujours de les ordonner de manière à nécessiter le moins d'effort possible. Par exemple,

• Si vous disposez d'une grande partie de la logique, qui va tourner autour d'une seule fonctionnalité, essayez de la diviser en plusieurs méthodes plus petites. Cela augmente la réutilisabilité et il devient facile pour un nouveau développeur de comprendre facilement le code. Au lieu de tout écrire dans une seule méthode et de lui donner l’apparence d’une logique complexe, divisez-la en morceaux de méthodes plus petits et lisibles.
• Commentez votre code magique. Ruby fournit de nombreuses méthodes de métaprogrammation, qui permettent de réduire vos efforts et de gagner du temps. Mais ils ne sont pas toujours aussi simples à comprendre lorsque l'on souhaite s'y référer, c'est toujours une bonne idée d'ajouter des commentaires appropriés afin que lorsque vous reviendrez plus tard pour y jeter un œil, il vous soit plus facile de vous reconnecter.
• Utilisez before_filter, au lieu de vous répéter dans le contrôleur.
• Utilisez des rappels de modèle pour éviter d'écrire trop de code dans les contrôleurs pour les actions qui tournent autour des opérations CRUD de base.
• FORMATING: there are certain gems which makes your life much easier : awesome_print ; pretty print ;  rubocop.
• Suivez toujours la pratique de la révision de code dans Git. Le code écrit par un développeur doit être examiné par les autres membres de l'équipe avant de fusionner avec les branches principales, car cela permet d'éliminer toute erreur potentielle ou résultat inattendu. Cela aide également à tenir chaque membre informé et informé de ce sur quoi travaille son collègue.
• Les instructions qui s'étendent sur 80 caractères doivent être décomposées en lignes suivantes afin d'éviter la barre de défilement lors de l'affichage du code sur d'autres supports comme GitHub.
• Lorsque vous validez du code dans votre référentiel, git diff me dit ce que vous avez fait, votre message de validation devrait indiquer pourquoi vous avez fait cela.
• NE PAS OPTIMISER pour les performances – OPTIMISER POUR LA CLARTÉ DU CODE
• Les tests unitaires sont toujours une bonne idée pour garantir que la fonctionnalité fonctionne comme prévu. Aide par aspect : Rails génère par défaut un assistant pour chaque contrôleur. Éliminez-les et essayez d'utiliser des assistants orientés aspect comme ; -> link_helper      –> menu_helper
• Conformément à la convention de MVC, il faut éviter d'appeler la base de données à partir de la couche View. Déplacez cette partie de votre code dans des contrôleurs pour garantir la séparation des préoccupations.
• Réduisez les appels aux bases de données. Si une page souvent visitée déclenche plusieurs appels vers la base de données, cela vaut la peine de consacrer un peu de temps à réduire le nombre d'appels à quelques-uns seulement. Dans de nombreux cas, il s’agit simplement d’utiliser .includes() ou .joins().
• Il devient fastidieux de vérifier la structure de votre modèle de temps en temps. Pour cela, incluez la structure de votre modèle en haut du fichier comme référence.

J'espère que cela a aidé ! Se déconnecter, Niyanta

Sauvegarder

Sauvegarder

Sauvegarder

Sauvegarder

Sauvegarder

Sauvegarder