Développeur, je réponds à vos questions

Le 07 avril 2023 à 00:54:15 :

Le 07 avril 2023 à 00:50:38 :

Le 07 avril 2023 à 00:48:48 :

Le 07 avril 2023 à 00:47:41 :
pourquoi je devrais me soucier de la notion d'acquittement, ma techno de communication me fournie une garantie de delivery at least once en général

De façon abstraite comme ça je ne pourrais pas te répondre sans voir l'implémentation. Si c'est pris en compte de façon générique par la solution logicielle tant mieux... mais elle ne fait qu'implémenter un pattern

ok tu penses quoi des pratiques "craft" ?
tu utilises le bdd et le tdd ?
j'arrive pas bien à comprendre la différence entre un subdomain et un bounded context

T'as envie de me tester c'est ça ? Je vais pas rentrer dans ton jeu, et je suis coach "Craft".
Je dirais que les pratiques craft et ce que beaucoup vendent sur linkedin c'est du bullshit. Le craftsmanship c'est un état d'esprit et surtout 4 principes: https://manifesto.softwarecraftsmanship.org
Quand on est dans une mission "craft", on essaie d'inculquer une dynamique "craft", mettant en avant la compétence technique. C'est ça qui est important.

Il n'a jamais été question de BDD et de TDD, qui ne sont que des pratiques logicielles et non des principes.
Et qui plus est, le TDD ne veut pas dire faire du code propre et bien tester. Et même en TDD faut différencier l'approche classical TDD (detroit) et l'approche mockiste (London school) qui n'ont rien avoir.

je veux juste ton avis sur ces sujets, moi je suis junior alors je suis perdu avec tous ces trucs
donc en gros le craft c'est juste viser l'excellence technique ?
comment je chosis entre l'approche classical ou london school du coup ?

Le 07 avril 2023 à 00:59:05 :

Le 07 avril 2023 à 00:54:15 :

Le 07 avril 2023 à 00:50:38 :

Le 07 avril 2023 à 00:48:48 :

Le 07 avril 2023 à 00:47:41 :
pourquoi je devrais me soucier de la notion d'acquittement, ma techno de communication me fournie une garantie de delivery at least once en général

De façon abstraite comme ça je ne pourrais pas te répondre sans voir l'implémentation. Si c'est pris en compte de façon générique par la solution logicielle tant mieux... mais elle ne fait qu'implémenter un pattern

ok tu penses quoi des pratiques "craft" ?
tu utilises le bdd et le tdd ?
j'arrive pas bien à comprendre la différence entre un subdomain et un bounded context

T'as envie de me tester c'est ça ? Je vais pas rentrer dans ton jeu, et je suis coach "Craft".
Je dirais que les pratiques craft et ce que beaucoup vendent sur linkedin c'est du bullshit. Le craftsmanship c'est un état d'esprit et surtout 4 principes: https://manifesto.softwarecraftsmanship.org
Quand on est dans une mission "craft", on essaie d'inculquer une dynamique "craft", mettant en avant la compétence technique. C'est ça qui est important.

Il n'a jamais été question de BDD et de TDD, qui ne sont que des pratiques logicielles et non des principes.
Et qui plus est, le TDD ne veut pas dire faire du code propre et bien tester. Et même en TDD faut différencier l'approche classical TDD (detroit) et l'approche mockiste (London school) qui n'ont rien avoir.

je veux juste ton avis sur ces sujets, moi je suis junior alors je suis perdu avec tous ces trucs
donc en gros le craft c'est juste viser l'excellence technique ?

L'approche craft c'est miser sur les compétences des dev pour réaliser un produit de qualité.
Et aussi développer une communauté de professionnels. Cette notion de communauté (entraide, partage etc..) est importante.

comment je chosis entre l'approche classical ou london school du coup ?

Il n'y a pas de recette toute faite. Certains préfèrent le outside-in, d'autres le Inside-out. Ce sont deux façons différentes de concevoir le code (c'est vraiment lié à la conception et la vision du code).

Moi j'ai tendance à préférer l'approche mockiste qui bien que plus longue, permet d'externaliser facilement une classe dans une librairie. Là où l'approche traditionnelle (en testant davantage en use case sur toute une grappe) se focus sur le résultat mais ne permet pas d'externaliser facilement le code.

Je sais que des dev "anciens" (Uncle Bob, Martin Fowler..) préfèrent le classical TDD surtout par habitude. L'idée n'est pas de dire si une approche est meilleure qu'une autre, mais de savoir ce qu'on aime et comprendre ce que chacune des approches apporte.

Derrière ça ne fait qu'utiliser la notions de test doubles pour tester..

Le 07 avril 2023 à 01:03:45 :

Le 07 avril 2023 à 00:59:05 :

Le 07 avril 2023 à 00:54:15 :

Le 07 avril 2023 à 00:50:38 :

Le 07 avril 2023 à 00:48:48 :

> Le 07 avril 2023 à 00:47:41 :

>pourquoi je devrais me soucier de la notion d'acquittement, ma techno de communication me fournie une garantie de delivery at least once en général

De façon abstraite comme ça je ne pourrais pas te répondre sans voir l'implémentation. Si c'est pris en compte de façon générique par la solution logicielle tant mieux... mais elle ne fait qu'implémenter un pattern

ok tu penses quoi des pratiques "craft" ?
tu utilises le bdd et le tdd ?
j'arrive pas bien à comprendre la différence entre un subdomain et un bounded context

T'as envie de me tester c'est ça ? Je vais pas rentrer dans ton jeu, et je suis coach "Craft".
Je dirais que les pratiques craft et ce que beaucoup vendent sur linkedin c'est du bullshit. Le craftsmanship c'est un état d'esprit et surtout 4 principes: https://manifesto.softwarecraftsmanship.org
Quand on est dans une mission "craft", on essaie d'inculquer une dynamique "craft", mettant en avant la compétence technique. C'est ça qui est important.

Il n'a jamais été question de BDD et de TDD, qui ne sont que des pratiques logicielles et non des principes.
Et qui plus est, le TDD ne veut pas dire faire du code propre et bien tester. Et même en TDD faut différencier l'approche classical TDD (detroit) et l'approche mockiste (London school) qui n'ont rien avoir.

je veux juste ton avis sur ces sujets, moi je suis junior alors je suis perdu avec tous ces trucs
donc en gros le craft c'est juste viser l'excellence technique ?

L'approche craft c'est miser sur les compétences des dev pour réaliser un produit de qualité.
Et aussi développer une communauté de professionnels. Cette notion de communauté (entraide, partage etc..) est importante.

comment je chosis entre l'approche classical ou london school du coup ?

Il n'y a pas de recette toute faite. Certains préfèrent le outside-in, d'autres le Inside-out. Ce sont deux façons différentes de concevoir le code (c'est vraiment lié à la conception et la vision du code).

Moi j'ai tendance à préférer l'approche mockiste qui bien que plus longue, permet d'externaliser facilement une classe dans une librairie. Là où l'approche traditionnelle (en testant davantage en use case sur toute une grappe) se focus sur le résultat mais ne permet pas d'externaliser facilement le code.

je fais comment pour m'intégrer à cette communauté de professionels ? je veux devenir craft moi

Le 07 avril 2023 à 01:05:59 :

Le 07 avril 2023 à 01:03:45 :

Le 07 avril 2023 à 00:59:05 :

Le 07 avril 2023 à 00:54:15 :

Le 07 avril 2023 à 00:50:38 :

> Le 07 avril 2023 à 00:48:48 :

>> Le 07 avril 2023 à 00:47:41 :

> >pourquoi je devrais me soucier de la notion d'acquittement, ma techno de communication me fournie une garantie de delivery at least once en général

>

> De façon abstraite comme ça je ne pourrais pas te répondre sans voir l'implémentation. Si c'est pris en compte de façon générique par la solution logicielle tant mieux... mais elle ne fait qu'implémenter un pattern

ok tu penses quoi des pratiques "craft" ?
tu utilises le bdd et le tdd ?
j'arrive pas bien à comprendre la différence entre un subdomain et un bounded context

T'as envie de me tester c'est ça ? Je vais pas rentrer dans ton jeu, et je suis coach "Craft".
Je dirais que les pratiques craft et ce que beaucoup vendent sur linkedin c'est du bullshit. Le craftsmanship c'est un état d'esprit et surtout 4 principes: https://manifesto.softwarecraftsmanship.org
Quand on est dans une mission "craft", on essaie d'inculquer une dynamique "craft", mettant en avant la compétence technique. C'est ça qui est important.

Il n'a jamais été question de BDD et de TDD, qui ne sont que des pratiques logicielles et non des principes.
Et qui plus est, le TDD ne veut pas dire faire du code propre et bien tester. Et même en TDD faut différencier l'approche classical TDD (detroit) et l'approche mockiste (London school) qui n'ont rien avoir.

je veux juste ton avis sur ces sujets, moi je suis junior alors je suis perdu avec tous ces trucs
donc en gros le craft c'est juste viser l'excellence technique ?

L'approche craft c'est miser sur les compétences des dev pour réaliser un produit de qualité.
Et aussi développer une communauté de professionnels. Cette notion de communauté (entraide, partage etc..) est importante.

comment je chosis entre l'approche classical ou london school du coup ?

Il n'y a pas de recette toute faite. Certains préfèrent le outside-in, d'autres le Inside-out. Ce sont deux façons différentes de concevoir le code (c'est vraiment lié à la conception et la vision du code).

Moi j'ai tendance à préférer l'approche mockiste qui bien que plus longue, permet d'externaliser facilement une classe dans une librairie. Là où l'approche traditionnelle (en testant davantage en use case sur toute une grappe) se focus sur le résultat mais ne permet pas d'externaliser facilement le code.

je fais comment pour m'intégrer à cette communauté de professionels ? je veux devenir craft moi

Va aux meetups, suis les recommandations des dev "seniors" que tu croises en mission et tu adhèreras aux principes "craft".

Le 07 avril 2023 à 01:12:03 :
justement je profite que t'es senior pour te demander tes recommandations mais tu me dis que mes questions m'éloignent du craft c'est à cause de mon ego ? tu as de conseils pour devenir egoless ?

Bon t'es un troll.

Lis les 4 principes du manifeste craftsmanship.
Puis lis l'egoless programming.

Et la prochaine fois t'essaieras davantage de prendre des conseils que de descendre ou tester des gens plus expérimentés que toi.

Le 07 avril 2023 à 01:13:12 :

Le 07 avril 2023 à 01:12:03 :
justement je profite que t'es senior pour te demander tes recommandations mais tu me dis que mes questions m'éloignent du craft c'est à cause de mon ego ? tu as de conseils pour devenir egoless ?

Bon t'es un troll.

Lis les 4 principes du manifeste craftsmanship.
Puis lis l'egoless programming.

Et la prochaine fois t'essaieras davantage de prendre des conseils que de descendre ou tester des gens plus expérimentés que toi.

en quoi je suis un troll wtf j'ai descendu personne