10 principes de base de la programmation que chaque programmeur doit suivre

Tout le monde peut écrire du code. Mais bon code? C'est là que ça devient difficile.

Nous avons tous entendu des histoires d'horreur sur le code spaghetti, les énormes chaînes if-else, des programmes entiers qui peuvent être interrompus simplement en changeant une variable, des fonctions qui semblent obfusquées, etc. C'est ce qui se produit lorsque vous essayez de créer un produit pouvant être expédié avec seulement un semestre d'expérience en programmation..

Ne vous contentez pas d'écrire du code qui travaux. Vise à écrire du code pouvant être maintenu - non seulement par vous-même, mais par toute autre personne susceptible de travailler ultérieurement sur le logiciel. À cette fin, voici plusieurs principes pour vous aider à nettoyer votre acte.

1. KISS

le “sois simple, stupide” principe s'applique à peu près toute la vie, mais il est particulièrement nécessaire dans les projets de programmation de moyenne à grande.

Cela commence bien au début lorsque vous définissez la portée de ce que vous voulez créer. Ce n’est pas parce que vous êtes passionné par le développement de jeux que vous pouvez créer le prochain jeu. World of Warcraft ou Grand Theft Auto. Lorsque vous pensez avoir suffisamment simplifié, simplifiez-le un peu plus loin - le fluage des fonctionnalités est inévitable, commencez petit à petit..

Mais même après le début du codage, restez simple. Le code complexe prend plus de temps à concevoir et à écrire, est plus sujet aux bogues et aux erreurs et est plus difficile à modifier plus tard. Dans les paroles sages d'Antoine de Saint-Exupery, “La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il ne reste plus rien à enlever.”

2. SEC

le “ne te répète pas” principe est crucial pour un code propre et facile à modifier. Lorsque vous écrivez du code, vous voulez éviter la duplication de données et la duplication de logique. Si vous remarquez que le même morceau de code est écrit maintes et maintes fois, vous enfreignez ce principe..

Le contraire du code DRY est le code WET: “tout écrire deux fois” (ou “perdre tout le temps de tout le monde”). L’un des meilleurs moyens de diagnostiquer le code WET est de vous demander: pour modifier le comportement du programme d’une manière ou d’une autre, combien de zones de code devez-vous modifier??

Supposons que vous écriviez une application de répertoire de podcast. Sur la page de recherche, vous avez le code permettant d'extraire les détails d'un podcast. Sur la page podcast, vous avez le code pour extraire les détails de ce podcast. Sur la page des favoris, le même code de récupération. Envisagez de résumer tout cela en une fonction afin que, si vous avez besoin de la modifier plus tard, vous puissiez tout faire en un seul endroit..

3. Ouvert / Fermé

Que vous écriviez des objets Qu'est-ce que la programmation orientée objet? Les bases expliquées dans les termes de Layman Qu'est-ce que la programmation orientée objet? Les bases expliquées dans les termes de Layman La plupart des langages de programmation modernes prennent en charge le paradigme de la "programmation orientée objet" (OOP). Mais en quoi consiste exactement la programmation orientée objet et pourquoi est-ce si utile? En savoir plus en Java ou dans les modules en Python, vous devriez viser à rendre votre code ouvert à l'extension mais fermé à la modification. Ceci s'applique à tous les types de projets, mais est particulièrement important lors de la publication d'une bibliothèque ou d'un framework destiné à être utilisé par d'autres.

Par exemple, supposons que vous mainteniez un cadre d'interface graphique. Vous pouvez le publier tel quel, en supposant que les utilisateurs finaux modifient et intègrent directement votre code publié. Mais que se passe-t-il lorsque vous publiez une mise à jour majeure quatre mois plus tard? Comment mettent-ils en œuvre tous vos ajouts sans jeter tout le travail qu'ils ont fait?

Au lieu de cela, libérez le code qui empêche modification directe et encourage extension. Cela sépare le comportement principal du comportement modifié. Les avantages? Une plus grande stabilité (les utilisateurs ne peuvent pas rompre accidentellement le comportement principal) et une plus grande facilité de maintenance (les utilisateurs ne se soucient que du code étendu). Le principe d'ouverture / fermeture est la clé pour créer une bonne API Que sont les API et comment les API ouvertes modifient-elles Internet? Que sont les API et comment les API ouvertes modifient-elles Internet? Vous êtes-vous déjà demandé comment les programmes de votre ordinateur et les sites Web que vous visitez? "Parler l'un à l'autre? Lire la suite .

4. Composition> Héritage

le “composition sur héritage” principe indique que les objets ayant des comportements complexes doivent le faire en contenant des instances d'objets ayant des comportements individuels plutôt qu'en héritant d'une classe et en ajoutant de nouveaux comportements.

Une dépendance excessive à l'égard de l'héritage peut conduire à deux problèmes majeurs. Premièrement, la hiérarchie des héritages peut devenir désordonnée en un clin d'œil. Deuxièmement, vous avez moins de flexibilité pour définir les comportements de cas spéciaux, en particulier lorsque vous souhaitez implémenter le comportement d'une branche d'héritage dans une autre branche d'héritage:

La composition est beaucoup plus propre à écrire, plus facile à gérer et permet une flexibilité quasi infinie quant aux types de comportements que vous pouvez définir. Chaque comportement individuel est sa propre classe et vous créez des comportements complexes en combinant des comportements individuels..

5. Responsabilité unique

le principe de responsabilité unique dit que chaque classe ou module d'un programme ne devrait se préoccuper que de fournir un bit de fonctionnalité spécifique. Comme le dit Robert C. Martin, “Une classe ne devrait avoir qu'une seule raison de changer.”

Les classes et les modules commencent souvent de cette façon, mais à mesure que vous ajoutez des fonctionnalités et de nouveaux comportements, il leur est facile de devenir des classes divines et des modules divins prenant des centaines, voire des milliers de lignes de code. À ce stade, vous devriez les diviser en classes et modules plus petits..

6. Séparation des préoccupations

le principe de séparation des préoccupations est comme le principe de responsabilité unique, mais à un niveau plus abstrait. Essentiellement, un programme doit être conçu de manière à avoir plusieurs encapsulations différentes qui ne se chevauchent pas, et ces encapsulations ne devraient pas se connaître..

Un exemple bien connu de ceci est le paradigme modèle-vue-contrôleur (MVC), qui sépare un programme en trois zones distinctes: les données (“modèle”), la logique (“manette”), et ce que voit l'utilisateur final (“vue”). Les variations de MVC sont courantes dans les frameworks Web les plus populaires.

Par exemple, le code qui gère le chargement et l'enregistrement des données dans une base de données n'a pas besoin de savoir comment restituer ces données sur le Web. Le code de rendu peut prendre une entrée de l'utilisateur final, mais passe ensuite cette entrée au code logique pour traitement. Chaque partie se manipule.

Il en résulte un code modulaire, ce qui facilite grandement la maintenance. Et à l'avenir, si vous avez besoin de réécrire tout le code de rendu, vous pouvez le faire sans vous soucier de la façon dont les données sont sauvegardées ou la logique traitée..

7. YAGNI

le “tu n'en auras pas besoin” principe est l’idée que vous ne devriez jamais coder pour une fonctionnalité que vous peut besoin à l'avenir. Les chances sont, vous habitude vous en aurez besoin et ce sera une perte de temps - et pas seulement, mais cela augmentera inutilement la complexité de votre code.

Vous pouvez voir cela comme une application spécifique du principe KISS et une réponse à ceux qui prennent le principe DRY trop au sérieux. Des programmeurs inexpérimentés essaient souvent d'écrire le code le plus abstrait et le plus générique possible pour éviter le code WET, mais trop d'abstraction aboutit à un code gonflé impossible à maintenir..

L'astuce consiste à appliquer le principe DRY uniquement lorsque vous en avez besoin. Si vous remarquez que des morceaux de code sont écrits à plusieurs reprises, abstenez-les - mais jamais lorsque vous pense un morceau de code sera écrit encore et encore. Plus de fois qu'autrement, ça ne sera pas.

8. Évitez l'optimisation prématurée

le pas de principe d'optimisation prématuré est similaire au principe YAGNI. La différence est que YAGNI aborde la tendance à mettre en œuvre des comportements avant qu'ils ne soient nécessaires, alors que ce principe traite de la tendance à accélérer les algorithmes avant qu'il soit nécessaire.

Le problème avec l'optimisation prématurée est que vous ne pouvez jamais vraiment savoir où se trouveront les goulots d'étranglement d'un programme avant de passer à l'acte. Vous pouvez deviner, bien sûr, et parfois vous pouvez même avoir raison. Mais plus souvent qu'autrement, vous perdrez un temps précieux à essayer d'accélérer une fonction qui n'est pas aussi lente que vous le pensez ou qui n'est pas appelée aussi souvent que vous le souhaiteriez..

Atteignez vos jalons aussi simplement que possible, puis profilez votre code identifier les véritables goulots d'étranglement.

9. Refactor, Refactor, Refactor

Une des vérités les plus difficiles à accepter en tant que programmeur inexpérimenté est que le code vient rarement dès la première fois. Cela pourrait ressentir lorsque vous implémentez cette nouvelle fonctionnalité brillante, mais au fur et à mesure que la complexité de votre programme augmente, les fonctionnalités futures risquent d’être gênées par la façon dont vous avez écrit cette première version..

Les bases de code évoluent constamment. Il est tout à fait normal de revoir, de réécrire ou même de redéfinir des pans entiers de code - et pas seulement normal, mais sain de le faire. Vous en savez plus sur les besoins de votre projet à présent que quand vous avez fait à la début, et vous devriez utiliser régulièrement ces connaissances nouvellement acquises pour reformuler l'ancien code.

Notez que cela ne doit pas toujours être un gros processus. Prenez une page des Boy Scouts of America, qui vivent de ces mots: “Laissez le terrain de camping plus propre que vous ne l'avez trouvé.” Si vous avez besoin de vérifier ou de modifier un ancien code, nettoyez-le toujours et laissez-le dans un meilleur état..

10. Clean Code> Clever Code

En parlant de code propre, laissez votre ego à la porte et oublier d'écrire du code intelligent. Vous savez de quoi je parle: le type de code qui ressemble plus à une énigme qu’une solution et existe uniquement pour montrer à quel point vous êtes intelligent. La vérité est que personne ne s'en soucie vraiment.

Un exemple de code intelligent consiste à regrouper le plus de logique possible sur une seule ligne. Un autre exemple consiste à exploiter les subtilités d'un langage pour écrire des déclarations étranges mais fonctionnelles. Tout ce qui pourrait amener quelqu'un à dire “Attends quoi?” quand pencher sur votre code.

Les bons programmeurs et le code lisible vont de pair. Laissez des commentaires si nécessaire. Adhérez aux guides de style, qu'ils soient dictés par un langage (comme Python) ou une entreprise (comme Google). Observez les idiomes par langue et arrêtez d'écrire du code Java en Python ou inversement. Voir notre article sur les astuces pour écrire du code de nettoyant. 10 astuces pour écrire du code plus propre et plus performant. 10 astuces pour écrire du code plus propre et plus performant. Voici comment vous pouvez commencer à écrire du code plus propre aujourd'hui. Lire la suite .

Ce qui fait un bon programmeur?

Demandez à cinq personnes et vous obtiendrez 10 réponses différentes. Pour moi, un bon programmeur est celui qui comprend que le codage doit au final servir l'utilisateur final, avec lequel il est facile de travailler en équipe et qui termine ses projets dans les délais impartis..

Si vous débutez, ne vous inquiétez pas trop pour le moment. Concentrez-vous sur l’apprentissage du code sans stress. Si vous vous sentez bloqué, consultez notre article sur le blocage du programmeur. Et si vous n'êtes pas content d'écrire du code, lisez notre article sur les panneaux indiquant que vous n'êtes pas destiné à être programmeur. 6 Signes indiquant que vous n'êtes pas censé être programmeur. 6 Signes indiquant que vous n'êtes pas censé être programmeur. découpé pour être un programmeur. Si vous n'êtes pas complètement sûr d'être censé être un programmeur, voici quelques signes qui peuvent vous orienter dans la bonne direction. Lire la suite .

Comment définiriez-vous un bon programmeur? Vous avez des conseils pour les programmeurs inexpérimentés qui veulent améliorer? Partagez avec nous dans les commentaires ci-dessous!

En savoir plus sur: Programmation.