Je pense que c'est overkill dans des projets simple (linuxFR par exemple) mais bon, jamais inutile.
Ton objectif quelque soit le logiciel que tu développe que tu sois une SSII, un projet communautaire, quelque soit ton langage et quelque soit les utilisateurs. C'est que la version N+1 puisse faire ce que fait la version N avec des choses en plus.
Tu tourne le problème dans le sens que tu veux mais l'idée c'est de trouver une solution pour garantir au mieux cette hypothèse de base. Pour ça tu as pleins de solutions (faire faire des tests par ta communauté, avoir tes recettes, embaucher des gars hyper-bon qui ne font jamais d'erreur, prouver ton logiciel, faire des tests, prier un dieux) et tu évalue la solution que tu met en place en fonction des contraintes de ton logiciel et de ta confiance en ceux-ci.
Ne pas s'intéresser sérieusement à cette problématique c'est faire du logiciel à la noix où l'on continue à habituer les utilisateurs à avoir des bugs et des régressions. La preuve que beaucoup de logiciels sont dans ce cas ? Certains sont bien heureux de pouvoir downgrader leur logiciel. Toute la plus value des distributions « stable » (Debian et Red Hat) par exemple viens du fait qu'ils ne prennent pas les logiciels upstream mais les logiciels upstream testé (par eux même et pas les autres distributions).
Je sais pas ce que tu veux me faire dire de plus.
J'essaie juste de partager mon point de vu, rien de plus. On voit pleins de monde jouer des biscoto en expliquant qu'ils économisent x octets d'un coté et n de l'autre et qu'avec ça dans leur cas d'utilisation, le logiciel consommer 70 fois moins de mémoire et généraliser pour dire que c'est la base que nous devrions tous connaître. Alors que depuis des lustres le plus gros problème de l'informatique particulièrement quand c'est grand publique c'est les bugs, les régressions etc.
c'est gentil de me donner une vidéo de 50minutes mais si tu pouvais résumer le passage important?
Fais-toi, un kiff et clique sur le lien pour voir.
Si tu avais cliqué sur le lien tu aurais vu que tu tombe pile au moment où Greg explique comment ils testent (grosso modo ils s'appuient sur la communauté et ne font aucun autre test, chaque commiter est responsable des tests de sont code). Ça dure 1m15s.
Pour ce qui est de la « gestion de projet » dans les points indiqués :
c'est à toi d'utiliser un gestionnaire de version, c'est donc à toi de le maîtriser et d'expliquer à ton superieur ce que tu fait s'il y a besoin (le workflow choisi est appliqué par les développeurs, mais il est choisi de manière collégial avec s'il y en a un, le chef de projet)
savoir lire de spec c'est un boulot technique qui n'a rien avoir avec de la gestion de projet, la spec ça peut être un document pondu par le client, avec le client, une RFC, une XEP ou autre c'est à toi développeur de la lire. Si tu attend à ce que quelqu'un la lise pour toi tu es mal barré
tests unitaires, on en a parlé
tests fonctionnel, on en a parlé
gestion des bug, à la rigueur c'est pas primordial, mais ça demande des connaissances techniques pour savoir de quoi on a besoin pour reproduire le problème
savoir évaluer les charge seul quelqu'un de technique peu le faire et c'est en effet de la communication, mais je doute que ton chef accepte la réponse « quand ce sera prêt » quand il te demande quand est-ce que ce sera fini
c'est pas de l'informatique c'est juste primordial
Bref tout ça pour dire que ton étiqutage basique « gestion de projet » / « technique » ça ne tiens pas la route. Soit tu es dans le monde de l'entreprise et il tu dois savoir faire ça pour ton chef, tes collègue et/ou tes clients, soit tu fais du logiciel libre à titre personnel et tu doit faire tout ça parce que c'est à toi de tout faire.
A l'IUT ou j'ai été, l'accent était vraiment mis sur ce genre de cours. Je ne sais pas si c'est le cas de tous les IUT. En tout cas c'est ce qui m'a donnée envie de fuir le plus loin possible de ce genre de boulot. Je sais que dans les facs c'est très peu enseigné, sauf dans les master spécialisés (tard, donc), mais l'enseignement à la fac se veut plus théorique normalement. Dans certaines école d'ingé tout ce qui est gestion de projet est très prioritaire sur les autres cours.
L'IUT forme avec l'optique que tu arrête tes études à bac+2 et que potentiellement tu crée ton entreprise. C'est pour ça, entre autre, que tu as eu des cours de droit et de compta. Les programmes ont bien sûr un peu évolués lorsqu'ils se sont rendu compte que 70% de ceux qui sortent n'arrêtent pas leurs études.
Les facs se trimbales 2 ans de sciences assez générales pour permettre aux étudiants de switcher plus facilement. Ensuite l'enseignement y est relativement modulaire et tu choisi ce que tu fait (bien sûr il y a un tronc commun).
Les écoles, ben ça dépend des écoles, ENSIMAG et Epitech ne sont pas comme d'autres écoles (on verra ce que donnera 42).
En tout cas il faut comprendre que faire du logiciel c'est bien. Le rendre utilisable c'est mieux et ça ça englobe un tas de choses qui ne sont pas de l'algorithmique à proprement parlé mais qui sont très importante et qui doivent souvent être pris en considération par les développeurs eux-même.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ça dépend de ce que tu code!
Posté par barmic . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 2.
Ton objectif quelque soit le logiciel que tu développe que tu sois une SSII, un projet communautaire, quelque soit ton langage et quelque soit les utilisateurs. C'est que la version N+1 puisse faire ce que fait la version N avec des choses en plus.
Tu tourne le problème dans le sens que tu veux mais l'idée c'est de trouver une solution pour garantir au mieux cette hypothèse de base. Pour ça tu as pleins de solutions (faire faire des tests par ta communauté, avoir tes recettes, embaucher des gars hyper-bon qui ne font jamais d'erreur, prouver ton logiciel, faire des tests, prier un dieux) et tu évalue la solution que tu met en place en fonction des contraintes de ton logiciel et de ta confiance en ceux-ci.
Ne pas s'intéresser sérieusement à cette problématique c'est faire du logiciel à la noix où l'on continue à habituer les utilisateurs à avoir des bugs et des régressions. La preuve que beaucoup de logiciels sont dans ce cas ? Certains sont bien heureux de pouvoir downgrader leur logiciel. Toute la plus value des distributions « stable » (Debian et Red Hat) par exemple viens du fait qu'ils ne prennent pas les logiciels upstream mais les logiciels upstream testé (par eux même et pas les autres distributions).
J'essaie juste de partager mon point de vu, rien de plus. On voit pleins de monde jouer des biscoto en expliquant qu'ils économisent x octets d'un coté et n de l'autre et qu'avec ça dans leur cas d'utilisation, le logiciel consommer 70 fois moins de mémoire et généraliser pour dire que c'est la base que nous devrions tous connaître. Alors que depuis des lustres le plus gros problème de l'informatique particulièrement quand c'est grand publique c'est les bugs, les régressions etc.
Fais-toi, un kiff et clique sur le lien pour voir.
Si tu avais cliqué sur le lien tu aurais vu que tu tombe pile au moment où Greg explique comment ils testent (grosso modo ils s'appuient sur la communauté et ne font aucun autre test, chaque commiter est responsable des tests de sont code). Ça dure 1m15s.
Pour ce qui est de la « gestion de projet » dans les points indiqués :
Bref tout ça pour dire que ton étiqutage basique « gestion de projet » / « technique » ça ne tiens pas la route. Soit tu es dans le monde de l'entreprise et il tu dois savoir faire ça pour ton chef, tes collègue et/ou tes clients, soit tu fais du logiciel libre à titre personnel et tu doit faire tout ça parce que c'est à toi de tout faire.
L'IUT forme avec l'optique que tu arrête tes études à bac+2 et que potentiellement tu crée ton entreprise. C'est pour ça, entre autre, que tu as eu des cours de droit et de compta. Les programmes ont bien sûr un peu évolués lorsqu'ils se sont rendu compte que 70% de ceux qui sortent n'arrêtent pas leurs études.
Les facs se trimbales 2 ans de sciences assez générales pour permettre aux étudiants de switcher plus facilement. Ensuite l'enseignement y est relativement modulaire et tu choisi ce que tu fait (bien sûr il y a un tronc commun).
Les écoles, ben ça dépend des écoles, ENSIMAG et Epitech ne sont pas comme d'autres écoles (on verra ce que donnera 42).
En tout cas il faut comprendre que faire du logiciel c'est bien. Le rendre utilisable c'est mieux et ça ça englobe un tas de choses qui ne sont pas de l'algorithmique à proprement parlé mais qui sont très importante et qui doivent souvent être pris en considération par les développeurs eux-même.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)