Comment trancher entre séparation des responsabilités et simplicité du flux?

[Patrick.L]

Salut tout le monde. Je suis un peu coincé sur un truc qui doit pourtant être simple : j’ai une fonction qui doit traiter une liste d’objets, et selon un état interne, soit les filtrer, soit les transformer. Mon instinct a été de créer deux fonctions séparées pour la lisibilité, mais maintenant je me retrouve avec un petit fouillis de conditions pour appeler la bonne, et ça commence à sentir le code spaghetti. Je me demande si je n’aurais pas dû tout garder dans une seule grosse fonction, même si c’est moins élégant. Vous avez déjà eu ce genre de dilemme entre séparation des responsabilités et simplicité du flux ?

[Matthew_W]

Le dilemme touche au cœur du principe de séparation des responsabilités et du flux logique. Si tu préfères deux petites fonctions pour clarifier ce qui se passe, tu t exposes à un risque de prolifération et de conditions dispersées. Une approche pragmatique serait une fonction orchestratrice qui appelle de petites primitives filtre et transforme selon l etat interne. Cela peut garder la lisibilité tout en facilitant les tests et l évolution sans tomber dans le spaghetti

[LaylaAT]

Franchement je suis pas convaincu que c est vraiment le vrai souci. La séparation des responsabilités peut paraitre sexy mais ce qui compte c est le flux et la comprehension collective. Deux fonctions cela peut aider mais aussi compliquer la navigation du code quand l appel devient un labyrinthe d etats. Bref j ai vu des projets qui preferent garder une seule fonction et un petit diagramme des branches quand c est indispensable et ca peut marcher

[DavidS]

Si je reformule ce que tu décris tu as une liste et un etat qui décide soit de filtrer soit de transformer et tu te demandes si un seul bloc serait plus simple a écrire. Ce que tu appelles séparation des responsabilités reste le point central mais cela touche aussi a l idee de flexibilité et de test. Tu cherches la solution qui allie clarté du flux et modularite sans devenir indisciplinée

[GraceR]

Est ce que l objectif est vraiment la lisibilite ou la capacite a faire evoluer le code sans toucher a la separation des responsabilites ?

[Larry_H]

On peut aussi parler des habitudes de lecture des développeurs et des attentes des lecteurs. Dans ce genre de micro architecture le choix entre separation des responsabilités et flux fluide peut dependre du style des ecritures et de ce que l equipe valorise. Un flux plus courant peut etre plus excitant a lire que des blocs encombrants et cela peut influencer les tests aussi et l estimation du temps de livraison. Peut etre il s agit de trouver une harmonie entre coherence contextuelle et modularite sans tout dire clairement

[JeffreyL]

C est frustrant de se prendre la tete pour un choix mineur et pourtant ce type de details pese lourd. Je me suis senti comme ca plusieurs fois et j ai prefere nommer clairement les etapes et clarifier le role de chaque morceau afin de nourrir la separation des responsabilités sans imposer le chaos. Ca ne donne pas une solution magique mais ca aide a respirer et a tester sans tout faire a la mano