J'entends parler de théorèmes de maths complexes, et je dois avouer que quelque part, ça me bloque...
J'ai un "bête" DUT en informatique (spécialité Génie Logiciel), que j'ai validé avec quelque chose comme 3 en maths (je suis vraiment une brêle en math...), mais par contre j'ai avoiné avec 17-18 de moyenne en logique et en algo... Et je m'en sors très bien.
Je ferais jamais de logiciel "haut niveau" comme de l'IA ou quoi que ce soit, et je considère d'ailleurs que les mecs qui font ça, sont purement des génies...
Bref, ma conception du métier et que le mathématicien, et le dév' sont deux entités séparées: l'un modélise le modèle mathématique à utiliser, et l'autre l'implémente de manière à ce que la machine le comprenne...
Ca c'était la digression sur l'emploi des maths en informatique, que je trouve moins importantes que la logique pure et dure (je peux me tromper, j'suis pas non plus un vieux briscard
).
Pour en revenir à la qualité de code, je dirais que le soucis, c'est la société de consommation: toujours plus vite, toujours moins cher... Et ça marche pas... C'est comme si on demander à un entrepreneur de construire un building en 1 mois au lieu d'un an... On aurait quoi comme problème? une dalle et des fondations fendues parce qu'on aurait construit dessus, avant que le béton soit sec, et des murs pas droit, parce que pas le temps de les monter au niveau et au fil à plomb? C'est ubuesque...
Je travaille pour une école, et je démine le code pissé par un autodidacte de 55 ans maintenant... Et quand je vois ça, j'me dit que les dév' ou auto-proclammé dev' de la génération d'avant codait pas mieux que ceux de maintenant, c'est juste qu'on passait l'éponge pour une technologie naissante et à ses balbutiements... Mais la société juge qu'en 20 ans on connaît tout de l'informatique et qu'il ne devrait plus y avoir d'erreur...
Je bosse sur un code spaghetti avec des pansements et des rustines sur les pansements, la faute à quoi? Il sais pas coder? Non, il y a des bouts de codes très élégants pour certaines tâches. La faute en revient au manque de modélisation, qui existait il y a 30 ans quand des autodidactes bricolait leur truc dans leur coin, et qui existe maintenant par "faute de temps".
Je me rappelle un adage de mon prof de programmation système qui disais: "le premier outil d'un informaticien, c'est un crayon et une feuille"
Si t'a pas couché sur le papier tout ce que le programme et censé faire, tu va droit dans le mur:
Tu penses que ton programme est un cheval, alors tu programmes un cheval. puis on vient te dire que c'est un cheval de course, alors tu l'affines et tu lui fait des jambes plus longues, ensuite on te dit que ça serais plus joli avec une corne, alors t'en colles par dessus. et enfin on te dit, ça serait bien s'il volait mon cheval, et donc tu lui greffes des ailes...
Ca si c'est spécifié dès le début, t'a une licorne volante...Si c'est pas spécifié on obtient un mulet à grande jambes avec une corne à la place de la queue et des ailes ridiculement petite à la place des oreilles...
Je capilotracte le truc, mais l'essentiel et là: le code est mauvais parce que la spécif' est mauvaise, et quand la spécif' est bonne, les architectes et les dev' se comprennent pas, ou veulent pas parce que l'archi c'est un con qui y connaît rien (c'est parfois vrai) et que le dev' est un glandeur qui veut pas avancer assez vite... Il y aurais meilleure entente et compréhension entre les 2 corps de métier, je parie mon chapeau (que je n'ai pas
) que la qualité de code remonterait en flèche...
Si on ajoute à ça, le fait que le client est sensibilisé à la difficulté de la création, et comprend que ça ne se fasse pas d'un claquement de doigts, et on arriverait à mener des projets à bien sans tout les soucis qu'on peut rencontrer au niveau bug et spécif' foireuse...
Comme je travaille dans le SI d'une boîte, j'ai mes "clients" (les utilisateurs finaux en fait) sous la main. Alors je prends le temps de lui demander plusieurs fois ce qu'il veut, et je lui reformule, histoire d'être sûr d'être sur la même longueur d'onde.
Ensuite, je lui explique ce que je vais faire, et les écueils que je pourrait avoir sur le chemin (intégrité des données sur la DB, par exemple), soucis de compatibilité avec l'existant, et que donc j'aurais fait ça en X temps, sous réserve de ne pas tomber sur un autre problème, et dès que j'ai un nouveau souci, je lui en parle, en lui expliquant que ça me prendras X temps en plus... Résultat, le client est content (il voit que son problème est pris au sérieux) et moins à cheval sur des délais impossible puisqu'on lui détaille pourquoi ce délai. Et des fois, ils arrivent même à te proposer une solution viable à laquelle t'avais pas pensé...
Bref tout ça pour dire que s'il y avait plus de transparence pour le client, ça serait mieux aussi pour la qualité de code, mais les SSII préfèrent maintenir ses clients dans l'ignorance pour se faire du pognon en facturant des trucs immenses qui sont en fait une broutille corrigé dans la minute...
7 |
0 |