Quand tu fais du code, il t'arrives de rencontrer des trucs affreux ?!
Alors comment passer d'un code crade à quelque chose d'évolutif et surtout durable ?
Lorsque l'on a trop de code dans une fonction, il est possible d'en extraire une fonction, afin de rendre l'ensemble plus lisible (code plus cours), plus com...
Est-ce que les frameworks et l'architecture hexagonale font bon ménage ?
Y-a-t-il des projets qui s’adaptent mieux que d’autres avec de l’hexa ou du framework ?
Quelles sont les contraintes, les atouts ?
Comment choisir et adapter son projet à l'une de ces 2 patterns ?
Merci pour ce podcast très chouette, j'ai particulièrement apprécié la partie sur la gestion/priorisation de la dette technique liée à l'absence d'archi hexa.
J'aurais bien aimé quelques précisions sur le fait de switcher vers de l'archi hexa avec Rails. Qu'entends-tu Benoit précisément ? Sur le sujet rails/harchi hexa j'ai la référence suivante que j'avais trouvée très intéressante : martinfowler.com/.... Ce que j'en ai retenu : si le métier s'y prête, il peut être pertinent de partir sur du Rails, donc avec la partie sgbd dans l'hexagone. En revanche cela n'empêche pas de faire de l'hexagonal sur les interactions que l'on considère à droite de l'hexagone, comme les appels vers d'autres partenaires. Et ce point me fait réagir aussi sur la définition de l'archi hexa qui serait "une standardisation du principe d'inversion de dépendance". L'inversion de dépendance me semble effectivement un point important de l'archi hexa, mais l'isolation des modèles (le côté anticorruption layer de l'archi) me parait tout aussi important et n'a pas été évoqué. Car on peut avoir de l'inversion de dépendance, mais se trimballer des objets d'api comme modèle métier, et ça, c'est bien galère :)
Bonne remarque.
Vis-à-vis de rails, mon point est simplement de dire que l'hexa dénature par mal le framework.
Si c'est pour faire ça, autant partir sur autre chose (ou créer un autre framework ?).
Ce n'est que mon avis.
Un talk sur le TDD par et pour ceux qui n'en n'ont pas besoin
Dans le podcast d’aujourd’hui, je reviens sur les side projects, souvent énergivores en temps et en énergie. Mais quels sont le ou les éléments déclencheurs qui te poussent à passer à l'action ?
Quel style de coding dojo préfères-tu ?
Les fins d’années sont souvent propices aux bilans et rétrospectives.
Aujourd'hui, on parle Clean Architecture avec Nicolas Deboose :
De quoi est-elle constituée ?
Quand l’utiliser et que peut-elle amener ?
Est-elle aussi sujette aux phénomènes de « mode » comme certains frameworks ?
Si tu veux aller plus loin, quelles sont les ressources ?
Nous avions essayé d'en s'en approcher avec un archi hexagonale + du DDD dans une de mes précédentes expériences et il y avait eu pas mal de réticences ou de frustration face à la verbosité du code lié aux différentes interfaces qui permettent d'abstraire les couches externes. J'avais alors eu pas mal de questions similaires à celles de Benoit. Hélas, je n'avais pas l'expérience de Nicolas pour y répondre.
Avec le recul, je pense que c'était un changement vraiment trop important et il aurait sûrement été plus avisé d'y aller incrémentalement. Ne serait-ce déjà que commencer par initier l'équipe à la notion de couplage du code et de son rapport gain/risque pour mieux comprendre l'intérêt des concepts qu'on applique ensuite.
Pour suivre le cursus Artisan Développeur : ad302.fr/3syGBo
Pour faire ton diagnostic de pratiques gratuit : ad302.fr/vA9131
Très dynamique avec plein de bonnes explications.