Et on est tous persuadé que tu va :
1- En écrire pour leur montrer l'exemple (non mais c'est vrai c'est qui ces guignoles qui savent même pas bosser, heureusement que tu es là pour leurs ouvrir les yeux)
2- Convaincre touts les Ldevs d'en faire
3- En oublier strictement aucun
Je n'ai jamais dis (ni même pensé) qu'ils étaient des "guignoles". Il ne fait aucun doute qu'en développement système, ils sont bien meilleurs que moi.
Cependant, je pense qu'il y a des bonnes pratiques pour coder. J'ai malheureusement l'impression que les devs du noyau Linux n'en respectent pas beaucoup :
- API qui change tous les 4 matins
(exemple du pilote NVidia qui devient incompatible à chaque version)
- Absence de tests unitaires
(problèmes de non-régression, vu ici même : un pilote qui marchait pour une version n et plus pour la version n+1, tout re-marchait à n+2)
Pour ma part, j'évite de modifier une API sans y réfléchir. L'agrandir, OK, en modifier/supprimer des fonctions, non.
J'impose aussi à l'équipe dont j'ai la responsabilité de réfléchir aux tests unitaires et seulement ensuite de les coder. De cette façon, j'espère qu'aucun tests n'est oubliés. Un jour quelqu'un m'a dit que une fonctionnalité non testée est équivalent à une fonctionnalité non implémentée. Je trouve cette remarque tout à fait censée.
ça me fait penser à deux distributions bien connus dont l'une à décidée de faire des releases de choses à peine sortie qui ont des problèmes de retro-compatibilité et des bugs encore non dévoilé. Quand l'autre prend son temps (3 ans) pour ne sortir que du stable qui finalement reçoit des patchs la semaine suivante.
Ouf, j'évite le troll, je n'utilise ni l'une ni l'autre...
Plus sérieusement, avoir de "bonnes pratiques" n'impose pas d'être lent... On code la fonctionnalité, on code les tests et c'est bon. Ca rajoute juste une petite tâche supplémentaire au début.
Ensuite, c'est un gain de temps car il suffit de lancer les tests à chaque modification pour vérifier que tout va bien. À chaque fois qu'un bug auquel on avait pas pensé survient, on rajoute le test qui va bien pour vérifier qu'il ne reapparait pas plus tard sous une autre forme.
[^] # Re: Confirme
Posté par ondex . En réponse au journal Noyau Linux : Chasse aux Bugs.. Évalué à 6.
Je n'ai jamais dis (ni même pensé) qu'ils étaient des "guignoles". Il ne fait aucun doute qu'en développement système, ils sont bien meilleurs que moi.
Cependant, je pense qu'il y a des bonnes pratiques pour coder. J'ai malheureusement l'impression que les devs du noyau Linux n'en respectent pas beaucoup :
- API qui change tous les 4 matins
(exemple du pilote NVidia qui devient incompatible à chaque version)
- Absence de tests unitaires
(problèmes de non-régression, vu ici même : un pilote qui marchait pour une version n et plus pour la version n+1, tout re-marchait à n+2)
Pour ma part, j'évite de modifier une API sans y réfléchir. L'agrandir, OK, en modifier/supprimer des fonctions, non.
J'impose aussi à l'équipe dont j'ai la responsabilité de réfléchir aux tests unitaires et seulement ensuite de les coder. De cette façon, j'espère qu'aucun tests n'est oubliés. Un jour quelqu'un m'a dit que une fonctionnalité non testée est équivalent à une fonctionnalité non implémentée. Je trouve cette remarque tout à fait censée.
Ouf, j'évite le troll, je n'utilise ni l'une ni l'autre...
Plus sérieusement, avoir de "bonnes pratiques" n'impose pas d'être lent... On code la fonctionnalité, on code les tests et c'est bon. Ca rajoute juste une petite tâche supplémentaire au début.
Ensuite, c'est un gain de temps car il suffit de lancer les tests à chaque modification pour vérifier que tout va bien. À chaque fois qu'un bug auquel on avait pas pensé survient, on rajoute le test qui va bien pour vérifier qu'il ne reapparait pas plus tard sous une autre forme.