Best practices Flashcards
Qu’est-ce que le principe DRY (Don’t Repeat Yourself) et pourquoi est-il important ?
Le principe DRY (Don’t Repeat Yourself) stipule qu’une information ou une logique ne doit être représentée qu’une seule fois dans le code. Cela permet de réduire les erreurs, de faciliter la maintenance et de rendre le code plus lisible et modulaire. En évitant la duplication, les changements ne doivent être effectués qu’à un seul endroit, réduisant ainsi le risque d’incohérences.
Pouvez-vous expliquer ce qu’est le principe KISS (Keep It Simple, Stupid) ?
Le principe KISS (Keep It Simple, Stupid) recommande de garder le code aussi simple que possible. La simplicité permet de comprendre, de tester et de maintenir le code plus facilement. Complexifier inutilement le code peut mener à des bugs, des difficultés de maintenance et une courbe d’apprentissage plus raide pour les nouveaux développeurs.
Qu’est-ce que le principe YAGNI (You Aren’t Gonna Need It) et comment l’appliquez-vous ?
Le principe YAGNI (You Aren’t Gonna Need It) conseille de ne pas ajouter de fonctionnalités supplémentaires au code tant qu’elles ne sont pas nécessaires. Cela évite la sur-ingénierie, réduit le temps de développement et limite les bugs potentiels. Les développeurs doivent se concentrer sur les fonctionnalités actuelles requises plutôt que de prédire les besoins futurs.
Qu’est-ce que le refactoring et pourquoi est-il important ?
Le refactoring consiste à modifier le code existant pour améliorer sa structure et sa lisibilité sans changer son comportement externe. Il est important car il permet de maintenir le code propre, d’améliorer la maintenabilité, de faciliter l’ajout de nouvelles fonctionnalités et de réduire le risque de bugs. Le refactoring contribue également à la réduction de la dette technique.
Qu’est-ce que la dette technique et comment peut-elle être gérée ?
La dette technique fait référence aux compromis faits dans le code pour atteindre des objectifs à court terme, comme des solutions de contournement ou du code mal structuré, qui nécessiteront des efforts supplémentaires pour être corrigés plus tard. Elle peut être gérée en planifiant régulièrement des sessions de refactoring, en écrivant du code propre dès le départ, et en utilisant des revues de code pour identifier et corriger les problèmes avant qu’ils ne s’accumulent.
Qu’est-ce qu’un code smell (code odor) et pouvez-vous en donner quelques exemples ?
Un code smell est un indicateur de mauvaise conception ou de code problématique qui peut suggérer la nécessité de refactoring. Quelques exemples incluent :
Code dupliqué : le même code apparaissant dans plusieurs endroits.
Méthodes longues : des méthodes avec trop de lignes de code.
Classes trop volumineuses : des classes qui ont trop de responsabilités.
Noms peu significatifs : des noms de variables, de méthodes ou de classes qui ne décrivent pas clairement leur rôle.
Utilisation excessive de commentaires : lorsque le code est si complexe qu’il nécessite de nombreux commentaires pour être compris.
Qu’est-ce que le principe SOLID et pouvez-vous expliquer chacun de ses principes ?
Le principe SOLID est un ensemble de cinq principes de conception qui aident à rendre le code plus compréhensible, flexible et maintenable.
S : Single Responsibility Principle (SRP) – Une classe doit avoir une seule responsabilité ou raison de changer.
O : Open/Closed Principle (OCP) – Les classes doivent être ouvertes à l’extension mais fermées à la modification.
L : Liskov Substitution Principle (LSP) – Les objets d’une classe dérivée doivent pouvoir remplacer les objets de la classe de base sans altérer le fonctionnement du programme.
I : Interface Segregation Principle (ISP) – Les clients ne doivent pas être forcés à dépendre d’interfaces qu’ils n’utilisent pas.
D : Dependency Inversion Principle (DIP) – Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Les deux doivent dépendre d’abstractions.
Qu’est-ce que le Test-Driven Development (TDD) et comment le pratiquez-vous ?
Le Test-Driven Development (TDD) est une pratique de développement logiciel où les tests unitaires sont écrits avant le code de production. Le cycle TDD se compose de trois étapes :
Red : Écrire un test qui échoue parce que la fonctionnalité n’est pas encore implémentée.
Green : Écrire le code de production minimal nécessaire pour faire passer le test.
Refactor : Améliorer le code en respectant les principes de conception, tout en s’assurant que les tests continuent de passer.
Pourquoi les revues de code sont-elles importantes et comment les effectuez-vous efficacement ?
Les revues de code sont importantes car elles permettent de détecter les erreurs, d’améliorer la qualité du code, de partager des connaissances entre les membres de l’équipe et de s’assurer que les meilleures pratiques sont suivies. Pour effectuer des revues de code efficacement :
Utiliser des outils de revue de code pour faciliter le processus (comme GitHub, GitLab, Bitbucket).
Définir des critères clairs pour la revue de code.
Se concentrer sur un seul aspect à la fois (par exemple, la lisibilité, la performance, la sécurité).
Donner des commentaires constructifs et spécifiques.
Limiter la taille des revues de code pour les rendre gérables.
Qu’est-ce que le principe de responsabilité unique (SRP) et comment l’appliquez-vous dans votre code ?
Le principe de responsabilité unique (Single Responsibility Principle, SRP) stipule qu’une classe doit avoir une seule responsabilité ou raison de changer. Cela signifie que chaque classe doit encapsuler une fonctionnalité distincte et ne devrait pas être surchargée de multiples responsabilités. Pour appliquer le SRP, vous devez identifier les différentes responsabilités dans votre code et les séparer en différentes classes ou modules, en veillant à ce que chaque classe ait un rôle clair et bien défini.
