Principes généraux de programmation
-
Je rassemblerais ici un ensemble de principes de programmation, auxquels tout programmeur devrait être sensibilisé.
Ces grands principes sont toujours présentés de façon malheureusement un peu abstraites, et pas forcément simples d’abord. Il serait intéressant de les détailler avec des exemples métier concret, et du code, tirés de nos expériences, pour étudier dans quelle mesure it.rocks utilise (ou pas) ces patterns pour aider à résoudre des cas métiers concrets dans le cadre de la création de logiciels de gestion, et peut-être parfois de sites internet.
Un des axes du framework est la suppression au maximum des couches d’abstraction du code métier réalisé par le développeur : l’abstraction nuit à la lisibilité, la conception du framework doit donc aider à la masquer pour apporter des solutions qui peuvent s’appuyer sur ces patterns, mais toujours dans l’object d’en masquer la complexité.
Il ne faut enfin jamais oublier que les patterns et philosophies de programmation sont avant tout des outils, et pas des fins en soi : on n’appliquera jamais un pattern “à la lettre” pour le plaisir de le maîtriser, mais parce qu’il s’avère qu’il apporte une solution à des problèmes métiers concrets auxquels notre expérience a pu se heurter.
Les principes de pgorammation
- Keep it simple and stupid
Un programme simple est plus facile à maintenir et à comprendre : retirer de la complexité
- SOLID
- S : Responsabilité unique
une classe doit avoir une et une seule responsabilité - O : Ouvert/fermé
une classe doit être ouverte à l’extension, mais fermée à la modification - L : Substitution de Liskov
une instance de type T doit pouvoir être remplacée par une instance de type G, tel que G sous-type de T, sans que cela ne modifie la cohérence du programme - I : Ségrégation des interfaces (Interface segregation principle)
préférer plusieurs interfaces spécifiques pour chaque client plutôt qu’une seule interface générale - D : Inversion des dépendances
il faut dépendre des abstractions, pas des implémentations
- S : Responsabilité unique
- YAGNI
Le développeur ne devraient pas ajouter de fonctionnalité à un logiciel tant que celle-ci n’est pas absolument nécessaire.
- Ne vous répétez pas
Il faut éviter la redondance de code afin de faciliter la maintenance, le test, le débogage et les évolutions.
Les outils
- Programmation dirigée par les tests
et débogage dirigé par les tests
voir Tests
Les patrons de conception (design patterns)
- General Responsibility Assignment Software Patterns
- Expert
- Créateur
- Faible couplage
- Forte cohésion
- Contrôleur
- Polymorphisme
- Indirection
- Fabrication pure
- Protection des variations
- Certaines évolutions de ces patrons
- Autres patrons de conception
- Inversion de contrôle
et son implémentation Injection de dépendances
- Inversion de contrôle
- A voir aussi :
Anti-patrons
- Anti-patrons de développement
- Abstraction inverse
- Action à distance
- Ancre de bateau
- Attente active
- Interblocages et famine
- Erreur de copier/coller
- Programmation spaghetti
- Réinventer la roue (carrée)
- Surcharge des interfaces
- L’objet divin
- Vous n’en aurez pas besoin (anti-YAGNI)
- Anti-patrons architecturaux
- Architecture as requirements
- Architecture by implication
- Coulée de lave
- Deuxième système
- Marteau doré
- Code smell
- Duplication de code
- Feature envy
- Blob / God class / Winnebago
- Long parameter list
- Long method
- Large class
- A voir aussi :
- Keep it simple and stupid