Une application C++, une image debian dumpée sur des Beaglebone black. Code tout pété, pas portable (mais fait par des étudiants, donc c'est pas choquant pour moi).
Besoin de porter vers x86 + dalle graphique + dalle tactile (avant c'était RS232 vers un clavier/écran tout pourrave et tout buggué).
1ère interface graphique: ÉtronJS. Échec, trop de problèmes de stabilité, difficultés de MàJ, et les devs assassinaient leur pauvre OS qui n'avait rien demandé à coup de "wget npm | sudo bash -" ou trucs dans ce genre.
2nd interface graphique, SDL2 en xorg-less (parce qu'un certain nombre de problèmes difficiles à résoudre venaient de xorg). Échec, la gestion de l'entrée était bancale. Tentative de lecture du code (par moi, 1ère fois que j'interviens dans cette partie, du coup): nope, le code des framebuffer est... bon, disons, pas fou, et surtout, considéré expérimental.
Du coup, 3ème, faite par moi, dans l'urgence. J'ai malgré tout pris le temps de voir comment étaient foutues les (rares) libs qui prétendaient faire ce que j'avais besoin, systématiquement overkill, complexité de mise en oeuvre. Au final, ça a été faire une lib basique de widgets moi-même, en me basant sur /usr/include/linux/fb.h et une lib, qui est libinput-dev.
Si jamais il devait arriver que cette lib ne soit pas adaptée, un portage vers autre chose serait trivial.
Autre exemple, sur le même projet (l'appli graphique n'étant qu'un seul élément): le code historique implémentait, de mémoire, les websockets à la main, ou je ne sais trop comment, peut-être des fichiers dupliqués à la sauvage, je ne sais vraiment plus.
Mon choix a été d'évaluer plus d'une dizaine de libs et de lire la RFC, au cas où. Il s'avère que la plupart des libs qui font du websockets en C ou C++ ont une assez gueule, mais la RFC est trop complexe pour moi (enfin, j'y arriverai, mais perte de temps considérable). Malgré ça, j'ai trouvé une lib(pub parce qu'elle le vaut bien) qui tenait la route, mais ce n'était vraiment pas la 1ère que j'ai évaluée. J'ai également eu le plaisir de leur remonter un problème (de doc, rien de méchant) qui a été très vite corrigé. Si un jour il y avait eu un bug critique dans le code, j'aurait été probablement capable d'intervenir, de ce que j'ai lu du code (propre, documenté, par de techniques à la conW mode, du simple, de l'efficace).
Pour moi, la gestion de ses dépendances, c'est ça: un travail qui certes prend un peu de temps, mais permets de réduire les risques: de faire un mauvais choix, déjà, et si ton choix est pas optimal, soit de pouvoir corriger le problème toi-même, soit de pouvoir aisément changer pour une autre lib.
Ce n'est pas prendre l'outil parfait, vu que ça existe pas, mais de prendre un truc qui ne te fout pas dans la merde si t'as besoin de changer ou d'intervernir dessus.
Alors, non, je ne lis pas chaque foutu commit, ça serait horrible, surtout depuis que les gens s'amusent à coller les commits de CI dans l'historique du projet, mais oui, je lis quelques fichiers source "au hasard", je regarde la fréquence de commits, je lis la doc, je regarde la licence aussi.
Pour ce qui est projets à framework... bah, désolé pour ceux qui bossent avec, hein. Ce que j'ai vu, c'est que quand on se base sur un framework, il est compliqué d'en sortir le jour ou ça colle plus aux besoins. C'est sûr, il fait tout, c'est propre (vu de l'extérieur, et encore, même pas toujours) c'est rassurant, mais j'ai déjà vu des boîtes réimplémenter from scratch leur outil qu'ils avaient codé depuis plus de 10 ans parce qu'ils avaient utilisé, justement, un framework qui s'était avéré pas si adapté que ça, finalement.
Pour moi, utiliser un framework, c'est mettre tout ses oeufs dans le même panier: c'est rapide à faire, mais le jour ou le panier est percé, on perd tout.
Je comprend bien que l'auteur du journal va loin, à dire d'inspecter chaque commit, mais a bien y réfléchir, de ce que j'ai vu dans des boulots, remplacer le temps perdu à contourner l'API du framework et dans des réunions stériles pourrait très bien abattre une bonne partie du boulot en question.
Boulot qui peut être dégrossi, mutualisé, par ailleurs, par exemple en essayant d'utiliser au maximum des outils fournis par, au hasard, debian, ou toute autre distribution logicielle qui ne fait pas de rolling release. Évidemment, ça implique d'avoir confiance upstream, mais bon, on le fait déjà quand on utilise une lib de toute façon, parce que c'est pas lire un historique de commit qui va renseigner sur ce que fait vraiment le code.
Note: de manière très amusante, alors que je suis un grand utilisateur de C++, j'ai constaté qu'après revue de code, la plupart du temps, j'opte pour des bibliothèques C, dont l'interface publique tend à être plus propre, plus simple et mieux documentée. Je crois bien qu'a part GLM, je n'ai pas été impressionné par une seule lib C++ ces dernières années, en fait.
[^] # Re: Tu dois pas produire grand chose
Posté par freem . En réponse au journal De l'art d'être indépendant des dépendances. Évalué à 3.
Un truc que j'ai vécu.
Une application C++, une image debian dumpée sur des Beaglebone black. Code tout pété, pas portable (mais fait par des étudiants, donc c'est pas choquant pour moi).
Besoin de porter vers x86 + dalle graphique + dalle tactile (avant c'était RS232 vers un clavier/écran tout pourrave et tout buggué).
1ère interface graphique: ÉtronJS. Échec, trop de problèmes de stabilité, difficultés de MàJ, et les devs assassinaient leur pauvre OS qui n'avait rien demandé à coup de "wget npm | sudo bash -" ou trucs dans ce genre.
2nd interface graphique, SDL2 en xorg-less (parce qu'un certain nombre de problèmes difficiles à résoudre venaient de xorg). Échec, la gestion de l'entrée était bancale. Tentative de lecture du code (par moi, 1ère fois que j'interviens dans cette partie, du coup): nope, le code des framebuffer est... bon, disons, pas fou, et surtout, considéré expérimental.
Du coup, 3ème, faite par moi, dans l'urgence. J'ai malgré tout pris le temps de voir comment étaient foutues les (rares) libs qui prétendaient faire ce que j'avais besoin, systématiquement overkill, complexité de mise en oeuvre. Au final, ça a été faire une lib basique de widgets moi-même, en me basant sur /usr/include/linux/fb.h et une lib, qui est libinput-dev.
Si jamais il devait arriver que cette lib ne soit pas adaptée, un portage vers autre chose serait trivial.
Autre exemple, sur le même projet (l'appli graphique n'étant qu'un seul élément): le code historique implémentait, de mémoire, les websockets à la main, ou je ne sais trop comment, peut-être des fichiers dupliqués à la sauvage, je ne sais vraiment plus.
Mon choix a été d'évaluer plus d'une dizaine de libs et de lire la RFC, au cas où. Il s'avère que la plupart des libs qui font du websockets en C ou C++ ont une assez gueule, mais la RFC est trop complexe pour moi (enfin, j'y arriverai, mais perte de temps considérable). Malgré ça, j'ai trouvé une lib(pub parce qu'elle le vaut bien) qui tenait la route, mais ce n'était vraiment pas la 1ère que j'ai évaluée. J'ai également eu le plaisir de leur remonter un problème (de doc, rien de méchant) qui a été très vite corrigé. Si un jour il y avait eu un bug critique dans le code, j'aurait été probablement capable d'intervenir, de ce que j'ai lu du code (propre, documenté, par de techniques à la conW mode, du simple, de l'efficace).
Pour moi, la gestion de ses dépendances, c'est ça: un travail qui certes prend un peu de temps, mais permets de réduire les risques: de faire un mauvais choix, déjà, et si ton choix est pas optimal, soit de pouvoir corriger le problème toi-même, soit de pouvoir aisément changer pour une autre lib.
Ce n'est pas prendre l'outil parfait, vu que ça existe pas, mais de prendre un truc qui ne te fout pas dans la merde si t'as besoin de changer ou d'intervernir dessus.
Alors, non, je ne lis pas chaque foutu commit, ça serait horrible, surtout depuis que les gens s'amusent à coller les commits de CI dans l'historique du projet, mais oui, je lis quelques fichiers source "au hasard", je regarde la fréquence de commits, je lis la doc, je regarde la licence aussi.
Pour ce qui est projets à framework... bah, désolé pour ceux qui bossent avec, hein. Ce que j'ai vu, c'est que quand on se base sur un framework, il est compliqué d'en sortir le jour ou ça colle plus aux besoins. C'est sûr, il fait tout, c'est propre (vu de l'extérieur, et encore, même pas toujours) c'est rassurant, mais j'ai déjà vu des boîtes réimplémenter from scratch leur outil qu'ils avaient codé depuis plus de 10 ans parce qu'ils avaient utilisé, justement, un framework qui s'était avéré pas si adapté que ça, finalement.
Pour moi, utiliser un framework, c'est mettre tout ses oeufs dans le même panier: c'est rapide à faire, mais le jour ou le panier est percé, on perd tout.
Je comprend bien que l'auteur du journal va loin, à dire d'inspecter chaque commit, mais a bien y réfléchir, de ce que j'ai vu dans des boulots, remplacer le temps perdu à contourner l'API du framework et dans des réunions stériles pourrait très bien abattre une bonne partie du boulot en question.
Boulot qui peut être dégrossi, mutualisé, par ailleurs, par exemple en essayant d'utiliser au maximum des outils fournis par, au hasard, debian, ou toute autre distribution logicielle qui ne fait pas de rolling release. Évidemment, ça implique d'avoir confiance upstream, mais bon, on le fait déjà quand on utilise une lib de toute façon, parce que c'est pas lire un historique de commit qui va renseigner sur ce que fait vraiment le code.
Note: de manière très amusante, alors que je suis un grand utilisateur de C++, j'ai constaté qu'après revue de code, la plupart du temps, j'opte pour des bibliothèques C, dont l'interface publique tend à être plus propre, plus simple et mieux documentée. Je crois bien qu'a part GLM, je n'ai pas été impressionné par une seule lib C++ ces dernières années, en fait.