https://fr.wikipedia.org/wiki/Effet_Dunning-Kruger
- Comprenez et acceptez que vous allez faire des erreurs.
- Vous n’êtes pas votre code. Rappelez-vous que le but de la revue de code est de trouver des problèmes, et des problèmes seront trouvés. Ne les prenez pas personnellement lorsqu’ils sont découverts.
- Recherchez et acceptez l’avis des autres, surtout lorsque vous pensez que ce n’est pas nécessaire.
- Ne pas réécrire le code de quelqu’un sans le consulter.
- La seule constante dans le monde est le changement. Soyez ouvert et acceptez cela avec un sourire. Percevez chaque changement (outils, besoins, plateformes, etc.) comme un nouveau défi.
- La seule véritable autorité acceptable découle de la connaissance et non du pouvoir. La connaissance engendre l’autorité, et l’autorité suscite le respect. Si vous voulez du respect, cultivez le savoir.
- Il faut se battre pour ses idées, mais accepter gracieusement la défaite. Acceptez que, parfois, votre raisonnement ne soit pas suivi. Même si plus tard il s’avère juste, il ne sert à rien de remettre sur le tapis le « Je vous l’avais bien dit ».
- Ne pas être « le gars dans la chambre ». Être hors de contact, hors de vue et hors de contrôle n’a pas sa place dans un environnement ouvert et collaboratif.
- Critiquer le code plutôt que la personne. On peut être gentil avec la personne tout en commentant le code. Autant que possible, faire des commentaires positifs et orientés vers l’amélioration du code. Par exemple, les commentaires relatifs aux normes, standard, spécifications, performances sont toujours bien perçus.
- Réutilisable Répondant aux contraintes et obligation de l’Open Source. (Meme si les projets sont privés)
- Standard Ayez un code neutre pour pouvoir le réutiliser partout.
- Compréhensible Même sans commentaire, être explicite est toujours mieux qu'implicite.
- Respectant les principes SOLID
- Utilisant les design patterns Vous devez savoir justifier votre architecture
- Respectant les Objects Calisthenics
- Respectant la Programmation Objet Utilisez les outils et concept du paradigme objet
- *Performant Vous devez justifier d’un temps de traitement, et d’utilisation de ressources materiel
- Qualitatif Le diable est dans les détails, veillez à toujours rajouter ce petit truc qui fera gagner du temps, rendra votre création parfaite, etc.
- Utilisant des technologies adaptées au projet Ne vous limitez pas à ce que vous connaissez, apprenez constamment et experimentez. Evitez le Golden Hammer (Quand on maitrise un marteau, tout est un clou)
- Testable Vos fonctions et objets ne doivent pas être trop dépendants les uns des autres, il faut pouvoir injecter facilement des données en entrées à des fins de tests
- Réfléchir Avant de coder il faut réfléchir son architecture et la documenter. (UML, Merise, Schema algorithmique)
- Simple La simplicité est toujours mieux que la fonctionnalité. Votre code à un objectif, réalisez le le plus simplement possible (c’est le plus difficile) Voir aussi YAGNI
- Répondant aux 90% des cas d’utilisation Ignorez ceux qui pinaille sur quelques cas isolés. YAGNI
- Qui respecte la gestion sémantique de version
- La rigidité : « Chaque changement cause une cascade de modifications dans les modules dépendants. » Une intervention simple au premier abord se révèle être un véritable cauchemar, à la manière d’une pelote de laine qui n’a pas de fin.
- La fragilité : « Tendance d’un logiciel à casser en plusieurs endroits à chaque modification. ». La différence avec la rigidité réside dans le fait que les interventions sur le code peuvent avoir des répercussions sur des modules n’ayant aucune relation avec le code modifié. Toute intervention est soumise à un éventuel changement de comportement dans un autre module.
- L’immobilisme : « Incapacité du logiciel à pouvoir être réutilisé par d’autres projets ou par des parties de lui même. » – « Il est presque impossible de réutiliser des parties intéressantes du logiciel. » L’effort demandé et les risques encourus sont trop importants.
- La viscosité : « Il est plus facile de faire un contournement plutôt que de respecter la conception qui a été pensée. » Lorsque nous intervenons sur du code existant, nous avons souvent plusieurs possibilités d’implémentations. Nous allons retrouver des solutions préservant, améliorant le design du code et d’autres qui vont « casser » ce design. Lorsque cette dernière catégorie est plus simple à mettre en place, nous considérons que le code est visqueux.
- L’opacité correspond à la lisibilité et la simplicité de compréhension du code. La situation la plus courante est un code qui n’exprime pas sa fonction première. Ainsi, plus un code est difficile à lire et à comprendre et plus nous allons considérer que ce dernier est opaque.
- Single Responsability Principle ou « principe de responsabilité unique »
- Open Close Principle ou « principe Ouvert / Fermé »
- Liskov Substitution Principle ou « principe de substitution de Liskov »
- Interface Segregation Principle ou « principe de ségrégation d’interface »
- Dependency Inversion Principle ou « principe d’inversion des dépendances »
Il existe des centaines de principes qui en découle, des patterns, des anti-pattern etc.
Dites vous bien que si vous voulez faire un travail de qualité, vous n'êtes pas seul, et toutes ces lois, règles, conseil et méthodologies sont la pour vous donner un cadre à suivre.
Attention toutefois les principes ci-dessus ne doivent pas toujours s'appliquer à lettre.
Ayez toujours en têtes ces quelques autres principes :
- Seulement un niveau d’indentation
- Éviter l’usage du mot-clé else
- Encapsuler les types primitifs
- Maximum un opérateur d’objet par ligne
- Ne pas abréger
- Développer des petites classes
- Limiter le nombre de propriétés d’instance dans une classe
- Éviter les classes de collection de premier ordre
- Limiter l’usage d’accesseurs et mutateurs publiques
YAGNI (anglicisme, acronyme anglais de you ain't gonna need it, qui peut se traduire par « vous n'en aurez pas besoin ») est un principe d'extreme programming qui déclare que les programmeurs ne devraient pas ajouter de fonctionnalité à un logiciel tant que celle-ci n'est pas absolument nécessaire.
Ron Jeffries recommande par ailleurs : « mettez toujours en œuvre les choses quand vous en avez effectivement besoin, pas lorsque vous prévoyez simplement que vous en aurez besoin »
Keep it simple, stupid (en français, mot à mot : « garde ça simple, bête », dans le sens de « ne complique pas les choses »), ou principe KISS, est une ligne directrice de conception qui préconise la simplicité dans la conception et que toute complexité non indispensable devrait être évitée dans toute la mesure du possible.
La complexité, souvent utile pour assurer de bonnes performances, est en effet elle-même une source de coûts de conception et de maintenance, ainsi qu'une source potentielle d'erreurs.
L'idée est de ne pas optimiser quoi que ce soit avant de maîtriser totalement une version simple de ce que l'on crée. Dans le produit fini, la simplicité d'usage, même au prix du renoncement à quelques fonctionnalités, est aussi un moyen de séduire l'utilisateur qui maîtrisera pour sa part l'usage du produit.
Cela se rapproche de l'anti-pattern "Overengineering" ou "sur-intellectualiser", je le rapproche aussi de la sur-qualité.
Ne vous répétez pas (don’t repeat yourself en anglais, aussi désigné par l’acronyme DRY) est une philosophie en programmation informatique consistant à éviter la redondance de code au travers de l’ensemble d’une application afin de faciliter la maintenance, le test, le débogage et les évolutions de cette dernière.
La philosophie DRY est explicitée par la phrase suivante, formulée par Andy Hunt et Dave Thomas dans leur livre The Pragmatic Programmer :
« Dans un système, toute connaissance doit avoir une représentation unique, non-ambiguë, faisant autorité ».
Les auteurs appliquent ce principe pour inclure les bases de données, les plans de tests, le système de construction logiciel et même la documentation logicielle.
Lorsque le principe DRY est bien appliqué, la modification d'un élément d'un système ne change pas les autres éléments non liés logiquement.
De plus, tous les éléments liés logiquement changent uniformément, de manière prévisible et restent synchronisés. En utilisant les méthodes et les sous-routines dans leur code, Thomas et Hunt se reposent sur les générateurs de code source, les systèmes de construction automatique, et les langages de scripts pour respecter le principe DRY à travers les diverses étapes de construction d'un logiciel.
--- Auteurs de ce petit mémo -- Damien Dabernat, Anthony Da Cruz