Aide-Mémoire Clean Code Qui Vous Aidera À Comprendre Les Bases - 12 Conseils Simples - Savvy Programmer

14/10/2023 09:28 Aide-mémoire Clean Code qui vous aidera à comprendre les bases : 12 conseils simples - Savvy Programmer
"Codez toujours comme si la personne qui finira par maintenir votre code
serait un psychopathe violent qui sait où vous habitez"
John Woods
Si la lecture de quelques lignes de code vous fait bouillir la tête ou vous donne envie de briser
l’écran de votre ordinateur, vous avez repéré un mauvais code. La mesure dans laquelle un code
est mauvais peut être déterminée par le nombre de gros mots qui sortent de votre bouche par
minute.
Un mauvais code n’est pas toujours erroné. La plupart du temps, cela fonctionne
parfaitement. Cependant, cela n’est pas viable à long terme. Souvent, le développeur qui a écrit le
code ne peut pas le comprendre correctement.
Un codage propre est un élément important de la maîtrise du logiciel. Lorsque vous travaillez dans
une équipe logicielle, écrire du code propre facilite la vie des membres de votre équipe.
Si vous souhaitez apprendre l’art d’écrire du code propre, ne cherchez pas plus loin. Cette aide-
mémoire complète sur le code propre vous guidera à travers tous les principes de codage propre
standard de l'industrie. Commençons.
1. KISS – Restez simple, stupide

« La simplicité est la condition préalable à la fiabilité. »
Edsger W. Dijkstra
L'algorithme du chemin le plus court de Dijkstra a parcouru un long chemin. Dans les applications
de recherche de chemin, il sert d’algorithme fondamental et fiable. C’est la preuve que des
algorithmes simples peuvent résoudre certains des problèmes les plus complexes.
KISS - l'un des premiers principes de conception, prône la simplicité du codage. C'est l'une des
règles générales qui s'appliquent à divers domaines. Cela signifie écrire du code qui fait le travail
de la manière la plus simple. Il ne suggère pas d’utiliser des méthodes triviales pour résoudre des
problèmes ou de trouver la solution la plus courte possible.
SDLC plus simple
https://savvyprogrammer.io/clean-code-cheat-sheet/ 1/14
Dans le développement logiciel général, l'objectif du principe KISS est de réduire la complexité tout
au long du cycle de vie du développement logiciel (SDLC). De la collecte des exigences à la
production, un cycle de vie de développement plus simple est plus facile à maintenir à long terme.
Exemples de baiser
L'utilisation de frameworks de développement Web tels que Django, Spring Boot et .NET peut
simplifier le processus de développement Web lors de la création d'applications à l'échelle de
l'entreprise. Leurs fonctionnalités intégrées peuvent grandement améliorer l’efficacité du
projet. Mais utiliser des frameworks Web pour créer un site Web pour une petite entreprise de
commerce électronique n’a aucun sens. Il est préférable d'utiliser des créateurs de sites Web
comme WordPress, Wix ou Squarespace.
De même, lorsqu’on travaille dans le domaine de l’intelligence artificielle (IA), on dit souvent qu’il
n’est pas nécessaire de former un modèle d’IA complexe lorsqu’une simple instruction if-else peut
faire l’affaire.
2. SEC – Ne vous répétez pas
La duplication de code est mal vue dans la communauté du logiciel. Le principe DRY stipule :
« Chaque élément de connaissance doit avoir une représentation unique, sans ambiguïté et faisant
autorité au sein d'un système. »
Chaque aide-mémoire de code propre doit contenir le principe DRY. Un codage propre n’est pas
possible sans programmation DRY. Si le code n'est pas SEC, alors il est HUMIDE - Nous aimons
taper ou tout écrire deux fois.
Si un logiciel contient des blocs de code en double, il est préférable de créer des fonctions et de
les appeler deux fois, car la duplication peut entraîner des erreurs potentielles.
« La répétition est la racine de tous les maux logiciels. »

Martin Fowler
Exemples SECS
Une bibliothèque de programmation fonctionne sur le principe DRY. Il peut être importé dans un
programme et seules les fonctionnalités nécessaires à l'exécution sont invoquées.
De nombreux frameworks de programmation sont conçus en suivant le principe de codage propre

DRY. Comme un framework frontal populaire, React garantit la programmation DRY en rendant
les composants et les variables d'état réutilisables.
3. SRP—Principe de responsabilité unique

Introduit par Robert C. Martin , SRP est l'un des cinq principes de conception SOLID qui servent
de base à la maintenabilité du codage. Il permet au développeur d'écrire du code qui peut être
géré, mis à l'échelle et étendu.
Le principe de responsabilité unique stipule :
« Une classe devrait avoir une et une seule raison de changer, ce qui signifie qu’une classe ne
devrait avoir qu’un seul travail. » Non seulement cela,
Explication du PRS
Dans le développement de logiciels, les exigences changent assez souvent. Dans la phase initiale,
ni le client ni l’équipe de développement ne sont pas sûrs du produit final. C'est là que le SRP joue
un rôle essentiel.
SRP garantit que chaque module, classe et fonction d'un logiciel fonctionne de manière
indépendante. Il exhorte les développeurs à réécrire les fonctions dépendantes en méthodes
indépendantes. Les développeurs doivent écrire de petites fonctions qui n'effectuent qu'une seule
opération et préfèrent moins d'arguments.
SRP fonctionne bien avec les architectures de conception populaires telles que les microservices .
Dans le développement de logiciels à grande échelle, il est difficile d’obtenir une indépendance
totale. Cela ne devrait pas empêcher les développeurs d’essayer de diviser le projet en petites
portions comme les microservices. Si les exigences changent, seule une petite partie du projet doit
être mise à jour plutôt que de mettre à jour plusieurs modules. Il ne doit y avoir aucune
dépendance directe ou un minimum de dépendances directes entre les modules.
Si les dépendances sont inévitables, essayez d'utiliser l'injection de dépendances pour les
ajouter. L'injection de dépendances est un modèle de conception qui permet la création et
l'utilisation d'objets dépendants entre deux ou plusieurs classes.
Demande PÉR
L'API Java Persistence est une excellente application pour SRP car elle n'a qu'une seule
responsabilité, à savoir appliquer le modèle standardisé de mappage objet-relationnel (ORM) pour
gérer la persistance dans les bases de données relationnelles.
Exemple de code SRP

Disons que vous devez mettre en œuvre un négociant en actions automatisé. Un négociant en
actions doit disposer de trois méthodes : acheter , vendre et conserver. Un développeur débutant
serait tenté de concevoir une classe Stock avec ces trois responsabilités. Le principe SRP interdit
à une classe d’avoir plusieurs responsabilités. Dans ce cas, il est préférable de séparer les trois
méthodes en trois classes distinctes à savoir Buy , Sell et Hold. Considérez les extraits de code ci-
dessous :
Avant d'appliquer le SRP : une classe d'actions unique avec de multiples

responsabilités
class Stock {
void Buy(string name, float price){
// Buy stock code implementation
}
void Sell(string name, float price){
// Sell stock code implementation
}
void Hold(string name, float price){
// Hold stock code implementation
}
}
Après avoir appliqué le SRP : trois classes avec une seule responsabilité
// Responsible for buying stocks

class Buy {
void run(string name, float price){
// Buy stock code implementation
}
}
// Responsible for selling stocks
class Sell {
// Sell stock code implementation
}
}
// Responsible for holding stocks
class Hold {
// Hold stock code implementation

}
}
// Responsible for executing stock methods only
class Stock {
Buy buy;
Sell sell;
Hold hold;
void Buy(string stock, float price){
// Call run method from Buy class
buy.run(stock, price);
}
void Sell(string stock, float price){
// Call run method from Sell class
sell.run(stock, price);
}
void Hold(string stock, float price){
// Call run method from Hold class
hold.run(stock, price);
}
}
Il existe de nombreuses autres façons de mettre en œuvre les mêmes fonctionnalités. On peut
faire des méthodes statiques ou même préférer le polymorphisme. Avec SRP, il n’y a pas de règles
strictes quant à la manière dont une classe doit être conçue. Les développeurs peuvent avoir des
idées contradictoires sur les responsabilités de classe, ce qui rend difficile la mise en œuvre du
SRP.
4. Ô FRIC ! (Fragilité, Rigidité, Immobilité,

Complexité)
Une mauvaise conception logicielle sent et pue.
Les odeurs de code sont un terme inventé par Kent Beck pour éventuellement identifier un
mauvais code. Il présente divers indicateurs tels que la fragilité, la rigidité, l’immobilité, la
complexité, les répétitions inutiles et la viscosité. Toute aide-mémoire de code propre doit inclure
ces indicateurs. Voici quelques-unes des règles générales pour un codage propre.
Qu’est-ce que la fragilité ?

Avec plus de fragilité , le programme risque de planter en introduisant un petit changement. Les
logiciels doivent être suffisamment robustes pour accepter de nouvelles modifications sans
perturber les fonctionnalités existantes. Si un logiciel critique tombe en panne, cela peut se
transformer en un désastre financier ou humanitaire.
Qu’est-ce que la rigidité ?

Le code sent la rigidité. La rigidité signifie que l'ajout d'un nouveau code ou la modification du
code existant aurait un effet domino sur l'ensemble du système. Si les modules ont une
dépendance logique élevée, divers modules doivent être mis à jour pour apporter une petite
modification.
Qu’est-ce que l’Immobilité ?

L'immobilité fait référence à l'incapacité de réutiliser le code. Le programme ne peut pas être
divisé en petits modules. Le code ne peut donc pas être réutilisé.
Qu’est-ce que la complexité ?

La complexité inutile fait référence aux fonctionnalités inutilisées dans un programme. Un
développeur peut ajouter une fonctionnalité qui reste inutilisée tout au long du cycle de vie du
logiciel. Cela peut ajouter des problèmes indésirables lors du test du code associé.
Minimiser l’étendue de ces indicateurs peut rendre votre programme parfumé.
5. La règle des scouts
Ne serait-il pas bien si vous n'aviez pas à perdre de temps à réparer le mauvais code de
quelqu'un ? C'est possible si chaque développeur suit la règle des boy-scouts.
La règle du boy-scout est une entrée courante dans toute aide-mémoire de code propre. Il est dit:
"Laissez toujours le code que vous modifiez un peu meilleur que vous ne
l'avez trouvé."
Odeurs anti-code
C’est l’un des meilleurs remèdes contre le code odorant. Avec un développement continu, la
qualité des logiciels peut se dégrader et les développeurs doivent cesser de travailler sur de
nouvelles fonctionnalités pour nettoyer la base de code.
La règle du boy-scout permet aux équipes logicielles d'améliorer la qualité de la structure du code
source au fil du temps. À chaque engagement, chaque membre de l’équipe apporte une petite
amélioration qui porte ses fruits sur le long terme.
6. POLA—Principe du moindre étonnement
Les développeurs détestent les surprises. Une surprise signifie une erreur potentielle dans le
système.
Le principe du moindre étonnement ou principe de la moindre surprise est un autre principe de

conception de code propre qui garantit un risque minimum de panne logicielle.
POLA Explication
Chaque module logiciel ou fonctionnalité ne doit faire que ce pour quoi il a été conçu. Par exemple,
si en appuyant sur le bouton de paiement, le système passe une commande sans demander
l'adresse de livraison ni le mode de paiement. Eh bien, dans ce cas, l'utilisateur final pourrait être
content mais le développeur se retrouverait dans des situations difficiles avec le gestionnaire.
POLA recommande des tests rigoureux sur chaque module. Chaque module doit fonctionner
indépendamment sur la base du SRP.
7. Suivez une convention de dénomination

cohérente
"Vous devez nommer une variable avec le même soin avec lequel vous
nommez un premier-né."
Robert C. Martin, Clean Code : un manuel de savoir-faire logiciel agile
Différents langages de programmation ont des conventions de dénomination différentes pour les
variables, les fonctions et les classes, mais quelques conventions de code épuré sont les mêmes.
Des noms significatifs

Les variables doivent avoir des noms descriptifs et sans ambiguïté. Les variables explicites sont
toujours préférées. Le nom de la variable doit indiquer son objectif. Si un tableau contient des
noms de différentes voitures, alors il doit être appelé cars, et non array , ou arr , ou arrayofcars ,
etc.
Il est préférable d'éviter les noms de variables ou de fonctions comportant un seul caractère ou des
mots incomplets. Par exemple, pour stocker le nom d'un chien, vous pouvez simplement
écrire dogname ou dog_name (appelé cas Snake) , au lieu de d, dname ou dgname.
Certaines directives préfèrent également l'écriture au cas Camel, par exemple dogName ou au
cas Pascal, par exemple DogName .
Les constantes sont écrites en majuscules.
Tous les principaux langages de programmation ont leur propre guide de style de codage qui doit
être suivi pour garantir la cohérence du codage.
8. Écrivez de bons commentaires : prenez votre

temps
« Les commentaires redondants ne sont que des lieux de collecte de
mensonges et de désinformations. »
Robert C. Martin, Clean Code : un manuel de savoir-faire logiciel agile
Les commentaires de code sont massivement sollicités dans l’industrie du logiciel. Un développeur
doit penser à ses pairs lors de l'écriture du code et ajouter des commentaires appropriés afin qu'ils
puissent comprendre le code plus tard.
Qu’est-ce qui rend les commentaires bons ?

Se fier trop aux commentaires indique de mauvaises pratiques de codage.
Le code doit être facilement compréhensible et les commentaires doivent être compacts et précis.
Évitez les commentaires redondants car ils indiquent une duplication de code.
N'ajoutez pas de commentaires pour chaque ligne de code, ciblez plutôt un bloc de code comme
une fonction, une classe ou un module. Résumez le bloc de code avec des mots simples à l'aide
de commentaires de bloc.
Exemple de commentaire de bloc

Considérez la classe Person suivante :
class Person
{
/* Person class constructor.
Initialize the age and height property of the Person object.
*/
public Person(int personAge, int personHeight)
{
age = personAge;
height = personHeight;
}
public int age { get; set; }
public int height { get; set; }
}
Dans l'exemple ci-dessus, nous avons uniquement écrit un commentaire de bloc pour le
constructeur Person et ignoré les commentaires pour les méthodes getter et setter de l'âge et de la
taille, car ils sont assez évidents.
Enfin, n'oubliez pas de supprimer les commentaires absurdes (« HIIII » ou « Helloooo ») ajoutés
lors du débogage.
9. Structurez votre code de manière esthétique
Une bonne structuration du code est l’une des pratiques de codage propre les plus importantes. Il
comprend de nombreux composants tels que le formatage correct de la structure interne d'une
fonction ou d'une classe, l'espacement des blancs, les lignes vides, l'indentation et la longueur
maximale des lignes, etc.
Échancrure
Les langages de programmation ont différents formats d'indentation. Certains définissent un niveau
de retrait avec 4 espaces et d'autres avec 8 espaces.
L'indentation occupe une place centrale dans les langages de programmation comme Python qui
n'ont pas de parenthèses de codage. Faites attention à ne pas casser l'indentation.
Flux de contrôle - Conditions et boucles if-else
Dans tous les langages, il est important de maintenir des niveaux d'indentation pour chaque niveau
de flux de contrôle afin d'améliorer la lisibilité du code. Par exemple, les boucles for imbriquées et
les instructions if-else doivent être correctement mises en retrait.
Exemple de mauvaise indentation
for (int i = 0; i < 10; i++)

{
for (int j = 0; j < 10; j++)
{
if (i > 5)
{
//print Hello
cout<<"Hello";
}
}
}
Bon exemple d'indentation
for (int i = 0; i < 10; i++) {

for (int j = 0; j < 10; j++) {
if (i > 5) {
//print Hello
cout<<"Hello";
}
}
}
Limite maximale de caractères

La plupart des langages de programmation prennent en charge 80 à 120 caractères par ligne. Il est
toujours préférable de diviser les gros morceaux de code en plusieurs lignes.
Des lignes vides sont également utilisées pour identifier des fonctionnalités de code distinctes et
améliorer la lisibilité du code.
Code multithread séparé

Dans le cas du parallélisme, un code multithread distinct doit être géré. Il est facile de perdre la
trace du code multithread. Essayez de rendre les threads aussi indépendants que possible et
évitez les dépendances logiques.
10. Gestion des erreurs
La gestion des erreurs est un autre conseil important dans l’aide-mémoire du code propre. Il est
souvent ignoré par la communauté des développeurs. Il peut empêcher le système logiciel de
tomber complètement en panne en cas de bogues et d'erreurs indésirables.
Un code qui génère des exceptions gérées est meilleur que celui qui plante complètement.
Bloc Try-Catch
Pour une gestion appropriée des erreurs, utilisez le bloc try-catch-finally. Son implémentation peut
varier selon les langages de programmation. Le but est de détecter les exceptions indésirables
comme la division d'un nombre par zéro ou si un fichier n'est pas trouvé. Ces exceptions peuvent
provoquer le blocage d'un programme.
Modèle de code
try {
// A protected code block that may throw exceptions
} catch (ExceptionName e) {
// Catch exceptions and print relevant error message
// A single catch block can only catch one exception
// Multiple catch blocks can be used to handle multiple exception
} finally {
// This block can free up any occupied resources
// like closing the database connection or closing the file stream
}
Exemple de gestion des erreurs

Tous les codes d'erreur HTTP (comme 404 Not Found, 500 Internal Server Error, etc.) doivent être
traités par les développeurs pour afficher les messages d'erreur appropriés au client, au lieu d'un
crash du système.
Un autre exemple courant de gestion des exceptions est la connexion à un serveur de base de
données. Le serveur peut être inaccessible en raison d'une perte de connexion Internet. Si le
programme exécute du code propre, toutes les exceptions sont redirigées de manière appropriée.
11. Refactoriser le code encore et encore

La refactorisation du code est l’une des techniques de codage propre les plus puissantes. Il s'agit
d'un processus systématique et progressif par lequel les développeurs peuvent améliorer la qualité
du code sans modifier ni ajouter de nouvelles fonctionnalités.
Améliorer l'efficacité du code

Cela permet au développeur de restructurer le code et de le rendre plus efficace. Cela peut réduire
la duplication de code et supprimer le code mort. Ce faisant, le code sale résultant de délais
serrés, de développeurs inexpérimentés et de solutions rapides est automatiquement éliminé.
Un simple exercice de refactorisation du code peut consister à supprimer les variables d'instance
dispersées et à les conserver au début du code après avoir attribué des noms descriptifs. Ou
aligner les éléments de l’interface utilisateur et garantir des tailles de boutons et de police
cohérentes.
Test du code refactorisé

La refactorisation du code et les tests de code vont de pair. Lorsqu'une partie du code est
refactorisée, elle doit être testée pour garantir une exécution propre. Le code refactorisé doit
réussir tous les cas de test existants.
Un code bien organisé est facile à comprendre et conserve les modifications ultérieures.
12. Choisissez un bon IDE

L'environnement de développement intégré ou IDE garantit automatiquement de nombreuses
pratiques de codage propres.
Un IDE est un ensemble de divers outils de développement tels qu'un éditeur de texte, un
compilateur, des langages de programmation, des frameworks Web, des outils de débogage, des
frameworks de test et un système de complétion de code intelligent, dans certains cas.
Avantages de l'EDI
Les IDE garantissent un codage propre en proposant une coloration syntaxique, en détectant les
erreurs de syntaxe et en indentant automatiquement le code source.
Les IDE peuvent écrire des opérations CRUD et générer des tests unitaires, permettant aux
développeurs d'économiser beaucoup de temps et de se concentrer davantage sur l'écriture du
code principal.
Si vous travaillez sur un projet de développement logiciel traditionnel, vous ne pouvez pas vivre
sans IDE. Les IDE peuvent gérer les répertoires de projets. Ils peuvent se connecter depuis
l’intérieur aux systèmes de contrôle de version tels que Github et Gitlab, permettant une gestion
des versions de code rapide et facile.
Exemples d'EDI
Les développeurs peuvent choisir un IDE en fonction des exigences de leur
projet. Comme Microsoft Visual Studio est compatible avec la programmation C#
et PhpStorm fonctionne bien pour la programmation PHP.
BONUS : sachez quand être incohérent
Les astuces de code propre évoquées ci-dessus peuvent ne pas remplir les critères d'un bon code
dans certains cas. Si l’application des techniques de codage propre ajoute plus de complexité au
système existant, il est préférable de les éviter.
Maintenance des systèmes existants

Lorsqu'ils travaillent sur des systèmes logiciels existants, les développeurs peuvent observer des
conventions de codage obsolètes. Dans de tels cas, il est préférable de rester cohérent avec les
anciennes directives de codage, plutôt que de s’adapter aux normes de codage modernes, qui
peuvent ajouter davantage de complexité.
Si le système utilise des méthodes obsolètes dans l'ensemble de l'application, il ne sert à rien de
supprimer ces méthodes ou de les mettre à jour vers la dernière version (sauf approbation de votre
responsable).
Dans certains cas, s’il n’est pas possible d’appliquer le principe DRY, il est alors temps de passer
au WET. La duplication de code peut permettre d'économiser d'innombrables heures de
développement au lieu de perdre du temps à trouver un moyen de l'éviter.
Réflexions finales
"Si vous voulez aller vite, si vous voulez faire vite, si vous voulez que votre code soit facile à écrire,
rendez-le facile à lire" - Robert C. Martin, Clean Code: A Handbook of Agile Software
Craftsmanship
Maîtriser les compétences de codage propre nécessite de la pratique et de la patience. Les

nouveaux développeurs peuvent apprendre rapidement en faisant réviser leurs codes par des
développeurs seniors. Ils peuvent souvent faire face à de sévères critiques pour avoir écrit du code
sale, comme ils le devraient. La clé est d’accepter les critiques de manière constructive avec le
désir d’apprendre et de s’améliorer.
Les techniques de codage propre partagées dans ce guide peuvent être un bon début pour
améliorer la qualité de vos futurs efforts de codage.
Les références
1. https://brilliant.org/wiki/dijkstras-short-path-finder/
2. https://reactjs.org/docs/thinking-in-react.html
3. http://cleancoder.com/products
4. https://www.digitalocean.com/community/conceptual_articles/solid-the-first-five-principles-of-
object-oriented-design
5. https://microservices.io/patterns/decomposition/decompose-by-business-capability
6. https://jcp.org/en/jsr/detail?id=338
7. https://www.kentbeck.com/
8. https://visualstudio.microsoft.com/
9. https://www.jetbrains.com/phpstorm/

Aide-Mémoire Clean Code Qui Vous Aidera À Comprendre Les Bases - 12 Conseils Simples - Savvy Programmer

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Aide-Mémoire Clean Code Qui Vous Aidera À Comprendre Les Bases - 12 Conseils Simples - Savvy Programmer

Transféré par

Droits d'auteur :

Formats disponibles

14/10/2023 09:28 Aide-mémoire Clean Code qui vous aidera à comprendre les bases : 12 conseils simples - Savvy Programmer

1. KISS – Restez simple, stupide

SDLC plus simple

2. SEC – Ne vous répétez pas

« La répétition est la racine de tous les maux logiciels. »

De nombreux frameworks de programmation sont conçus en suivant le principe de codage propre

3. SRP—Principe de responsabilité unique

Le principe de responsabilité unique stipule :

Exemple de code SRP

Avant d'appliquer le SRP : une classe d'actions unique avec de multiples

// Responsible for buying stocks

// Hold stock code implementation

4. Ô FRIC ! (Fragilité, Rigidité, Immobilité,

Qu’est-ce que la fragilité ?

Qu’est-ce que la rigidité ?

Qu’est-ce que l’Immobilité ?

Qu’est-ce que la complexité ?

Minimiser l’étendue de ces indicateurs peut rendre votre programme parfumé.

5. La règle des scouts

6. POLA—Principe du moindre étonnement

Le principe du moindre étonnement ou principe de la moindre surprise est un autre principe de

7. Suivez une convention de dénomination

Des noms significatifs

Les constantes sont écrites en majuscules.

8. Écrivez de bons commentaires : prenez votre

Qu’est-ce qui rend les commentaires bons ?

Exemple de commentaire de bloc

Considérez la classe Person suivante :

9. Structurez votre code de manière esthétique

Flux de contrôle - Conditions et boucles if-else

les instructions if-else doivent être correctement mises en retrait.

Exemple de mauvaise indentation

for (int i = 0; i < 10; i++)

Bon exemple d'indentation

for (int i = 0; i < 10; i++) {

Limite maximale de caractères

Code multithread séparé

10. Gestion des erreurs

Exemple de gestion des erreurs

11. Refactoriser le code encore et encore

Améliorer l'efficacité du code

Test du code refactorisé

12. Choisissez un bon IDE

BONUS : sachez quand être incohérent

Maintenance des systèmes existants

Maîtriser les compétences de codage propre nécessite de la pratique et de la patience. Les

Vous aimerez peut-être aussi