10 principes de base de la programmation que tout programmeur doit connaître
Il est facile d’écrire un code. Il est difficile d’écrire un bon code.
Un mauvais code se présente sous de nombreuses formes. Un code mal rangé, des chaînes massives, des programmes qui rompent avec un ajustement, des variables qui n’ont pas de sens. Le programme peut fonctionner une fois, mais ne résistera jamais à un examen minutieux.
Ne vous contentez pas de raccourcis. Essayez d’écrire un code facile à maintenir. Facile à maintenir pour vous, et facile à maintenir pour tout autre développeur de votre équipe. Comment écrire un code efficace ? Vous écrivez du bon code en étant discipliné avec des principes de programmation.
Voici 10 principes de programmation qui vous permettront d’être un meilleur codeur.
1. Faire simple et stupide (KISS)
Cela semble un peu dur, mais c’est un principe de codage à respecter. Qu’est-ce que cela signifie ?
Cela signifie que vous devez écrire un code aussi simple que possible. Ne vous laissez pas prendre à essayer d’être trop intelligent ou à vous vanter avec un paragraphe de code avancé. Si vous pouvez écrire un script en une seule ligne, écrivez-le en une seule ligne.
Voici une fonction simple :
function addNumbers(num1,num2){
return num1 + num2;
}Plutôt simple. Il est facile à lire et vous savez exactement ce qui se passe.
Utilisez des noms de variables clairs. Profitez des bibliothèques de codage pour utiliser les outils existants. Facilitez le retour au travail après six mois. La simplicité vous évitera les maux de tête.
2. Écrivez le code de la sécheresse
Le principe « Don’t Repeat Yourself » (DRY) signifie, en clair, ne pas répéter le code. Il s’agit d’une erreur de codage courante. Lorsque vous écrivez un code, évitez de dupliquer les données ou la logique. Si vous avez déjà copié et collé du code dans votre programme, ce n’est pas du code SEC.
Jetez un coup d’œil à ce scénario :
function addNumberSequence(number){
number = number + 1;
number = number + 2;
number = number + 3;
number = number + 4;
number = number + 5;
return number;
}Au lieu de dupliquer les lignes, essayez de trouver un algorithme qui utilise l’itération. Pour les boucles, et tandis que les boucles sont des moyens de contrôler le code qui doit s’exécuter plusieurs fois.
Le code DRY est facile à maintenir. Il est plus facile de déboguer une boucle qui traite 50 répétitions que 50 blocs de code qui traitent une répétition.
3. Ouvert / Fermé
Ce principe signifie que vous devez viser à rendre votre code ouvert à l’extension mais fermé à la modification. C’est un principe important lors de la publication d’une bibliothèque ou d’un cadre que d’autres utiliseront.
Par exemple, supposons que vous mainteniez un cadre d’interface graphique. Vous pourriez permettre aux codeurs de modifier et d’intégrer directement le code que vous avez publié. Mais que se passe-t-il lorsque vous publiez une mise à jour majeure quatre mois plus tard ?
Leur code va se casser. Cela rendra les ingénieurs malheureux. Ils ne voudront plus utiliser votre bibliothèque pendant longtemps, aussi utile soit-elle.
Au lieu de cela, un code de déblocage qui empêche la modification directe et encourage l’extension. Cela permet de séparer le comportement de base du comportement modifié. Le code est plus stable et plus facile à maintenir.
4. Composition sur l’héritage
Si vous écrivez du code en utilisant la programmation orientée objet, vous allez trouver cela utile. Le principe de la composition sur l’héritage stipule que les objets ayant des comportements complexes doivent contenir des instances d’objets ayant des comportements individuels. Ils ne doivent pas hériter d’une classe et ajouter de nouveaux comportements.
Le fait de compter sur l’héritage pose deux problèmes majeurs. Premièrement, la hiérarchie des héritages peut devenir désordonnée dans l’urgence. Vous avez également moins de souplesse pour définir les comportements des cas particuliers. Supposons que vous vouliez mettre en place des comportements à partager :
La programmation de la composition est beaucoup plus propre à l’écriture, plus facile à maintenir et permet une flexibilité dans la définition des comportements. Chaque comportement individuel est sa propre classe. Vous pouvez créer des comportements complexes en combinant des comportements individuels.
5. Responsabilité unique
Le principe de la responsabilité unique stipule que chaque classe ou module d’un programme ne doit fournir qu’une seule fonctionnalité spécifique. Comme le dit Robert C. Martin, « Une classe ne devrait avoir qu’une seule raison de changer ».
Les cours et les modules commencent souvent de cette façon. Faites attention à ne pas ajouter trop de responsabilités car les cours deviennent plus compliqués. Réfléchissez et divisez-les en classes et modules plus petits.
La conséquence de la surcharge des classes est double. Premièrement, cela complique le débogage lorsque vous essayez d’isoler un certain module pour le dépannage. Deuxièmement, il devient plus difficile de créer des fonctionnalités supplémentaires pour un module spécifique.
6. Séparation des préoccupations
Le principe de la séparation des préoccupations est une version abstraite du principe de la responsabilité unique. Cette idée stipule qu’un programme doit être conçu avec différents conteneurs, et que ces conteneurs ne doivent pas avoir accès les uns aux autres.
Un exemple bien connu est la conception modèle-vue-contrôleur (MVC). Le MVC sépare un programme en trois zones distinctes : les données (modèle), la logique (contrôleur) et ce que la page affiche (vue). Des variantes de MVC sont courantes dans les cadres de travail web les plus populaires d’aujourd’hui.
Par exemple, le code qui gère la base de données n’a pas besoin de savoir comment rendre les données dans le navigateur. Le code de rendu prend les données de l’utilisateur, mais le code logique gère le traitement. Chaque morceau de code est complètement indépendant.
Le résultat est un code facile à déboguer. Si jamais vous devez réécrire le code de rendu, vous pouvez le faire sans vous soucier de la manière dont les données sont sauvegardées ou dont la logique est traitée.
7. Vous n’en aurez pas besoin (YAGNI)
Ce principe signifie que vous ne devez jamais coder une fonctionnalité au cas où vous en auriez besoin à l’avenir. N’essayez pas de résoudre un problème qui n’existe pas.
Dans un effort pour écrire du code DRY, les programmeurs peuvent violer ce principe. Souvent, les programmeurs inexpérimentés essaient d’écrire le code le plus abstrait et le plus générique possible. Trop d’abstraction provoque un code gonflé qu’il est impossible de maintenir.
N’appliquez le principe du DRY que lorsque vous en avez besoin. Si vous remarquez des morceaux de code écrits à l’infini, alors abstenez-les. Ne pensez pas trop loin au détriment de votre lot de code actuel.
8. Documentez votre code
Tout développeur senior soulignera l’importance de documenter votre code avec des commentaires appropriés. Tous les langages les proposent et vous devez prendre l’habitude de les écrire. Laissez des commentaires pour expliquer les objets, améliorer les définitions de variables et rendre les fonctions plus faciles à comprendre.
Voici une fonction JavaScript avec des commentaires vous guidant dans le code :
//This function will add 5 to the input if odd, or return the number if even
function evenOrOdd(number){
//Determine if the number is even
if(number % 2 == 0){
return number;
}
//If the number is odd, this will add 5 and return
else {
return number + 5;
}
}Laisser des commentaires est un peu plus de travail pendant que vous codez, et vous comprenez assez bien votre code, n’est-ce pas ?
Laissez quand même des commentaires !
Essayez d’écrire un programme, en le laissant seul pendant six mois, et revenez le modifier. Vous serez heureux d’avoir documenté votre programme au lieu de devoir passer sur chaque fonction pour vous rappeler comment il fonctionne. Vous travaillez dans une équipe de codage ? Ne frustrez pas vos collègues développeurs en les forçant à déchiffrer votre syntaxe.
9. Refactor
C’est difficile à accepter, mais votre code ne sera pas parfait la première fois. Refacturer le code signifie revoir votre code et chercher des moyens de l’optimiser. Rendre le code plus efficace tout en gardant les résultats exactement les mêmes.
Les bases de code sont en constante évolution. Il est tout à fait normal de revoir, réécrire ou même reconcevoir des pans entiers de code. Cela ne signifie pas que vous n’avez pas réussi la première fois que vous avez écrit votre programme. Vous allez vous familiariser avec un projet au fil du temps. Utilisez ces connaissances pour ajuster votre code existant afin qu’il soit SEC, ou en suivant le principe KISS.
10. Un code propre à tout prix
Laissez votre ego à la porte et oubliez d’écrire des codes intelligents. Le genre de code qui ressemble plus à une énigme qu’à une solution. Vous ne codez pas pour impressionner les étrangers.
N’essayez pas de mettre une tonne de logique dans une seule ligne. Laissez des instructions claires dans les commentaires et la documentation. Si votre code est facile à lire, il sera facile à maintenir.
De bons programmeurs et un code lisible vont de pair. Laissez des commentaires si nécessaire. Respectez les guides de style, qu’ils soient dictés par une langue ou par votre entreprise.
Qu’est-ce qui fait un bon programmeur ?
Apprendre à être un bon programmeur demande beaucoup de travail ! Ces 10 principes de codage constituent une feuille de route pour devenir un programmeur professionnel.
Un bon programmeur comprend comment rendre ses applications faciles à utiliser, travaille bien en équipe et termine les projets selon les spécifications et dans les délais. En suivant ces principes, vous vous préparerez à réussir dans votre carrière de programmeur.