Tout est dans le titre
9 conseils / principes utiles – l’article explique pourquoi
1. un niveau d’indentation par méthode
2. ne pas utiliser le mot clef « else »
3. encapsuler toutes les primitives dans des classes
4. créer des collections / ensembles dédiés
5. respecter la loi de Demeter
6. ne pas abréger les noms des variables
7. garder les entités les plus petites possibles
8. pas de classes avec plus de 2 variables d’instance
9. pas de getters / settersL'auteur décrit une manière de gérer les menaces potentielles sur une application, en les explicitant dans un document. Il prend l'application web JSONDiff comme exemple
Un article passionnant sur l'héritage vs la composition en POO. J'en retiens sa conclusion : il ne sert à rien de se forcer à utiliser des grands principes (DRY, héritage, composition, etc.) tant que l'on n'a pas une compréhension claire du problème que l'on essaye de résoudre... par contre, ces grands principes sont très utiles pour le refactoring.
L'auteur montre comment configurer un workflow Symfony via l'utilisation d'une interface PHP et des constantes - cela permet d'utiliser ensuite ces constantes un peu partout (dans workflow.yml, dans les classes PHP, dans les templates, etc.) Astucieux !
Plein de bons conseils sur la typographie (accessibilité et design responsive)
L'auteur montre l'installation de Debian sur un Kimsufi - il aborde pas mal de thèmes intéressants comme le réseau, la connexion par SSH, etc.
Avec quelques astuces et conseils en prime (certification Kubernetes)
L'auteur explique l'importance de choisir ses priorités et comment il fait
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
L'auteur parle de la nécessité de faire attention à ses commits publics dans git
Un article très intéressant... et un twist final pas mal ^^
Plein de bons conseils pratiques pour s'améliorer en programmation
L'auteur explique l'intérêt de multiplier les mesures dans le logiciel - aide à la décision, alertes sur des problèmes en cours ou à venir, etc. La mesure est indispensable si on souhaite agir au plus juste.
Dans cet article, l'auteur explique la relation entre cohésion et couplage. Pour paraphraser son résumé final :
- De par les limitations de notre cerveau pour appréhender des systèmes complexes, nous cherchons à modulariser notre base de code en parties indépendantes.
- Un module est un ensemble d'éléments qui devraient être autant liés entre eux (cohésion) que possible, avec une frontière nette entre "l'intérieur" et "l'extérieur".
- Les connexions entre les différentes frontières des modules devraient être réalisées via leurs interfaces, une manière contrôlée de communiquer à travers les frontières.
- La force du couplage de ces connexions dépend du nombre et de la complexité des interfaces des modules, la quantité et la nature des données échangées, et si les composants des modules changent souvent en même temps.
- Il y a plusieurs types de couplage, et de nouveaux sont toujours "découverts".
- Créer des modules cohérents est la meilleure manière d'éviter un couplage fort. Autrement dit, des modules faiblement couplés ont souvent une grande cohésion.
- Une cohésion imprécise ou de haut niveau devrait être évitée - il s'agit d'une cohésion artificielle (des bouts de code rassemblés en un même endroit bien qu'ils n'aient rien à voir). À la place, nous devrions tendre vers des modules dédiés à la résolution de problèmes métiers bien définis.
- Il est plus facile d'arriver à une grande cohésion fonctionnelle avec des modules mécaniques, tels que des modules dédiés à la résolution de problèmes mathématiques (ceux ci ont peu de chance de changer)
Une abstraction a 3 caractéristiques :
- Elle masque les informations inutiles.
- Elle généralise un concept.
- Elle est un point de vue de la réalité (ex: chaque type de carte traite d'un aspect de la géographie, carte routière, carte topographique, carte des monuments, etc.)
On n'oubliera pas qu'une abstraction n'est pas l'objet qu'elle représente !
Comme la programmation concerne les données et le contrôle de leur flux, il y a deux types d'abstractions : les abstractions de données, et les abstractions du contrôle de flux.
Les abstractions de données servent à :
- simplifier en masquant la gestion de la mémoire et les mécanismes de comportement (ex: ne pas faire d'addition sur des chaînes de caractère)
- fournir des comportements génériques réutilisables
- donner aux développeurs le pouvoir de créer de nouvelles abstractions via les "ADT" (Abstract Data Type)
Les abstractions de contrôle sont essentiellement les fonctions car :
- Le nom de la fonction simplifie et masque ses mécanismes internes.
- Une fonction généralise un comportement, qui peut être réutilisé partout.
- Vous devez être conscients que le nom de la fonction peut ne pas correspondre exactement à la réalité (problème du nommage)
En POO, une classe est une abstraction réunissant structure de données et comportement. Il existe aussi les classes abstraites qui permettent de généraliser certains comportements que l'on souhaite masquer. Enfin les interfaces sont aussi des abstractions, même si leur intérêt principal est plutôt la possibilité de changer d'implémentation concrète.
L'avantage principal des abstractions est la simplification en masquant les détails non pertinents. Il y a toutefois des inconvénients à ne pas négliger :
- problème du nommage
- sursimplification -> manque de contrôle par l'utilisateur (interface trop simple), perte de détails (tous les détails ne sont pas à masquer)
Pour pallier ces problèmes, il faut donc rester le plus proche possible du "métier" et ne pas utiliser d'abstraction de prime abord.
Les abstractions masquent les détails inutiles... mais ceux ci peuvent faire surface malgré tout ("fuite") L'endroit où se situe la fuite fera toute la différence dans la résolution du problème : votre code, le code d'un collègue, le code d'une librairie externe, le langage, le matériel !
Ensuite, l'auteur illustre par un exemple le danger de créer une abstraction trop tôt : il avait pensé à plusieurs cas possibles... mais pas suffisamment. Résultat : sa classe a fini par exploser les compteurs de complexité cyclomatique à coup de "if". Il vaut mieux dupliquer du code tant que l'on n'a pas une connaissance raisonnable des abstractions sous jacentes.
L'auteur parle aussi de la confusion entre abstraction et indirection. Une indirection permet de remplacer une partie de l'implémentation par autre chose (ex: les interfaces)
Certaines abstractions créent des indirections (classe abstraite, interfaces)
Créer une indirection ne signifie pas que vous créez une abstraction.
Les indirections facilitent le changement... mais au prix d'une lisibilité moindre.
En résumé de l'article :
- Les états globaux mutables doivent être évités à tout prix.
- On peut réduire le scope d'un état mutable - c'est le but - en passant cet état en tant qu'argument d'une fonction, en utilisant l'injection de dépendances ou des objets de contexte (similaires aux Value Objects).
- Les variables globales ne sont que le sommet de l'iceberg : le plus important est de respecter le principe d'encapsulation, et il y a plusieurs manières de ne pas le faire... Les états globaux mutables ne sont qu'un exemple extrême.
- Les états globaux immutables sont moins pires, mais il est préférable malgré tout de les éviter.
Une critique argumentée du principe ouvert/fermé...