Charly Laurent
Bretagne
Pour toutes celles et ceux qui ont, comme moi, du mal à écrire leurs premiers cas de tests : un petit acronyme sympa !
Derniers commentaires :
Charly Laurent
il y a plus de 3 ans
Bel article! Je trouve les informations pertinentes, pour moi qui fait du TDD. Mais un exemple pourrait aider les développeurs qui n'ont jamais essayé.
1
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Aujourd'hui, je vais te montrer les pires bouts de code que j’ai jamais vus. Des sataneries qu'il ne faut surtout pas produire !
Derniers commentaires :
Benoit GANTAUME
il y a presque 4 ans
Salut,
Par personnellement, mais j'ai vu ça en coaching d'équipes.
Fuir est une option rapide.
Défendre sa cause est plus long et plus impactant sur à terme. Mais il faut en avoir la patience et l'envie.
Si tu aimes le côté évangéliste, c'est intéressant à faire. Si tu veux juste coder dans de bonnes conditions, tu as probablement plus vite fait de changer d'environnement.
Par personnellement, mais j'ai vu ça en coaching d'équipes.
Fuir est une option rapide.
Défendre sa cause est plus long et plus impactant sur à terme. Mais il faut en avoir la patience et l'envie.
Si tu aimes le côté évangéliste, c'est intéressant à faire. Si tu veux juste coder dans de bonnes conditions, tu as probablement plus vite fait de changer d'environnement.
Marc Tourneux
il y a presque 4 ans
Salut,
Je n'ai pas pris la peine de défendre mon point de vue car je suis le principal développeur. Les personnes opposées étaient les chefs de projet, qui ne touchent que très ponctuellement au code... et qui étaient beaucoup intéressées à définir la place de l'accolade pour le "if" (retour à la ligne ou pas ?! ça c'est un grand débat !)
Je n'ai pas pris la peine de défendre mon point de vue car je suis le principal développeur. Les personnes opposées étaient les chefs de projet, qui ne touchent que très ponctuellement au code... et qui étaient beaucoup intéressées à définir la place de l'accolade pour le "if" (retour à la ligne ou pas ?! ça c'est un grand débat !)
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Lorsque l’on utilise Git, surtout quand on est débutant, on ne sait pas toujours comment nommer correctement ses branches ou ses messages de commits. Pourtant il est primordial pour s’y retrouver dans un projet, de respecter une convention de nommage.
Derniers commentaires :
Axel Shaïta
il y a environ 4 ans
@Corentin Leffy J'ai pas mal utilisé cette convention que je trouve, comme tu dis, très visuelle. J'en fais d'ailleurs mention très brièvement dans mon article.
@Marc Bouvier C'est exactement cette convention ! Effectivement elle est de plus en plus suivie car pas mal d'outils se basent sur celle-ci pour automatiser la génération des changelogs ou le versionning (en se basant sur semver.org/lang/fr/)
@Marc Bouvier C'est exactement cette convention ! Effectivement elle est de plus en plus suivie car pas mal d'outils se basent sur celle-ci pour automatiser la génération des changelogs ou le versionning (en se basant sur semver.org/lang/fr/)
Baptiste Pottier
il y a environ 4 ans - modifié il y a environ 4 ans
@benoit Oui, nous l'utilisons depuis une année en mode "souple", c'est à dire que nous gardons une branch develop en plus de la master, là ou certain "extremistes" ne gardent que la master (et franchement on s'interroge à ne pas pousser jusque là tellement c'est pratique).
Les gains sont :
- l'obligation de travailler propre (il faut penser au copain)
- obligation de faire de petit commit
- incitation forte au feature flag
- Jamais de gros diff, jamais de branch qui se meurent ou qui durent des jours et des jours voir plus (sympa à merger ...)
On peut très bien savoir faire cela avec des branches, mais alors elles n'ont plus d’intérêt (si on merge toutes les heures, autant faire dans develop).
A chaque onboarding, le nouvel arrivant est dérangé mais très vite il adore (et on utilise les tags!) c'est queque chose qu'il faut pratiquer pour véritablement en comprendre l'avantage (comme le TDD sur ce point)
Les gains sont :
- l'obligation de travailler propre (il faut penser au copain)
- obligation de faire de petit commit
- incitation forte au feature flag
- Jamais de gros diff, jamais de branch qui se meurent ou qui durent des jours et des jours voir plus (sympa à merger ...)
On peut très bien savoir faire cela avec des branches, mais alors elles n'ont plus d’intérêt (si on merge toutes les heures, autant faire dans develop).
A chaque onboarding, le nouvel arrivant est dérangé mais très vite il adore (et on utilise les tags!) c'est queque chose qu'il faut pratiquer pour véritablement en comprendre l'avantage (comme le TDD sur ce point)
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.