Plus tu es abstrait plus tu gère de cas, mais ça peut être au détriment de l'évolution
J'ai commencé ma carrière pro en 1999, au cours de cette carrière de developpeur, puis de concepteur, puis d'architecte logiciel, puis d'architecte SI je me suis rendu compte qu'il existait un type de developpeur qui n'appréhendait pas bien l'abstraction. Or l'abstraction n'est qu'un outil comme un autre dans l'arsenal du developpeur. Un outil logique qui certe demande plus de rigueur mais n'en demeure pas moins une variable qui permet de dépasser des seuils quand même assez avancés. J'ai par exemple un projet assez complexe d'un point de vue algorithme en go qui ne peut pas avancer tant que je n'ai pas les génériques en go, c'est un side project, je ne vais pas me faire chier à gérer les switch sur des types.
Ainsi ces developpeurs ont en horreur TOUTE abstraction et véhiculent des inexactitudes voires des choses fausses sur les abstractions ne voyant que les défauts d'une mauvaise utilisation sans savoir expliquer/voir pourquoi elles sont parfois necessaires. J'ai des souvenir assez précis de discussions assez épiques quand je proposais des formations sur la conception et sur le DDD, où certains developpeurs ne comprenais pas/rien et ne voyait jamais l'intérêt d'un cas expliqué et parlais souvent de "bon sens". C'est que du bon sens disaient ils.
Des personnes influentes comme "Joel On Software" ont d'ailleurs parlé avec justesse du concept de "Leaky Abstraction" [1] pour dénoncer à l'époque et mettre en garde contre les dérives potentiels d'une utilisation abusive et non maitrisée des abstractions. Mais ce constat s'applique aussi à d'autre pratique par exemple l'optimisation prématurée [2] qui va conduire à des problématiques inutiles et couteuses à résoudre.
Bref, quand tu dis que l'abstraction se fait au détriment de l'évolution ou de l'utilisabilité, je pense personnellement qu'à minima, on ne parle pas de la même chose car la création d'une abstraction n'à qu'un seul but détecter une situation problématique récurrente bien cadrée et déterminée pour proposer une solution ouverte et non enfermante.
L'utilisation des génériques n'a jamais empecher une quelconque évolution du code, au contraire elle ouvre à plus de possibilité avec juste un seul bout de code !
Nous sommes d'accord que nous devons utiliser les abstractions avec mesure, mais c'est le cas de tous les outils logiques qu'utilisent les devs. Ils existent un biais chez certains developpeurs qui ont tendances à catégoriser toutes les abstractions dans un même tiroir, souvent parce qu'ils ne les maitrisent pas et surtout ils ne voient pas un autre avantage aux abstractions, c'est qu'on partage à peu près tous le même espace mental : autrement dit on parle de tous de la même chose et ça devient un langage technique international. J'ai récemment participé à un échange avec deux developpeurs "anti-abstraction" qui essayaient de résoudre et d'expliquer à l'autre d'abord l'espace du problème ensuite une solution les seuls concepts qu'ils utilisent sont 'table', 'index', clés etrangère , clef primaire ... très bas niveau , trop bas niveau pour des discussions de grooming ... le PO est plus que perdu. c'est fini le temps où les programmeurs savaient faire la différence entre Objet métier, MCD et MPD . Pour ces devs tout est table de base de données ... je m'arrête là désolé pour le pavé
[^] # Re: Trou de mémoire
Posté par Narmer . En réponse au lien Go 1.18 Beta : la généricité enfin !. Évalué à 1.
J'ai commencé ma carrière pro en 1999, au cours de cette carrière de developpeur, puis de concepteur, puis d'architecte logiciel, puis d'architecte SI je me suis rendu compte qu'il existait un type de developpeur qui n'appréhendait pas bien l'abstraction. Or l'abstraction n'est qu'un outil comme un autre dans l'arsenal du developpeur. Un outil logique qui certe demande plus de rigueur mais n'en demeure pas moins une variable qui permet de dépasser des seuils quand même assez avancés. J'ai par exemple un projet assez complexe d'un point de vue algorithme en go qui ne peut pas avancer tant que je n'ai pas les génériques en go, c'est un side project, je ne vais pas me faire chier à gérer les switch sur des types.
Ainsi ces developpeurs ont en horreur TOUTE abstraction et véhiculent des inexactitudes voires des choses fausses sur les abstractions ne voyant que les défauts d'une mauvaise utilisation sans savoir expliquer/voir pourquoi elles sont parfois necessaires. J'ai des souvenir assez précis de discussions assez épiques quand je proposais des formations sur la conception et sur le DDD, où certains developpeurs ne comprenais pas/rien et ne voyait jamais l'intérêt d'un cas expliqué et parlais souvent de "bon sens". C'est que du bon sens disaient ils.
Des personnes influentes comme "Joel On Software" ont d'ailleurs parlé avec justesse du concept de "Leaky Abstraction" [1] pour dénoncer à l'époque et mettre en garde contre les dérives potentiels d'une utilisation abusive et non maitrisée des abstractions. Mais ce constat s'applique aussi à d'autre pratique par exemple l'optimisation prématurée [2] qui va conduire à des problématiques inutiles et couteuses à résoudre.
Bref, quand tu dis que l'abstraction se fait au détriment de l'évolution ou de l'utilisabilité, je pense personnellement qu'à minima, on ne parle pas de la même chose car la création d'une abstraction n'à qu'un seul but détecter une situation problématique récurrente bien cadrée et déterminée pour proposer une solution ouverte et non enfermante.
L'utilisation des génériques n'a jamais empecher une quelconque évolution du code, au contraire elle ouvre à plus de possibilité avec juste un seul bout de code !
Nous sommes d'accord que nous devons utiliser les abstractions avec mesure, mais c'est le cas de tous les outils logiques qu'utilisent les devs. Ils existent un biais chez certains developpeurs qui ont tendances à catégoriser toutes les abstractions dans un même tiroir, souvent parce qu'ils ne les maitrisent pas et surtout ils ne voient pas un autre avantage aux abstractions, c'est qu'on partage à peu près tous le même espace mental : autrement dit on parle de tous de la même chose et ça devient un langage technique international. J'ai récemment participé à un échange avec deux developpeurs "anti-abstraction" qui essayaient de résoudre et d'expliquer à l'autre d'abord l'espace du problème ensuite une solution les seuls concepts qu'ils utilisent sont 'table', 'index', clés etrangère , clef primaire ... très bas niveau , trop bas niveau pour des discussions de grooming ... le PO est plus que perdu. c'est fini le temps où les programmeurs savaient faire la différence entre Objet métier, MCD et MPD . Pour ces devs tout est table de base de données ... je m'arrête là désolé pour le pavé
[1] https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/
[2] https://effectiviology.com/premature-optimization/