Ca me fait bien rire. Comme si les anciens développeurs codaient tout à la main. Je suis dans une boite où il y a de vieux développeurs et quand on regarde leur code de plus près, on remarque qu'il y a beaucoup de copié collé d'autres codes, qu'il s'agisse du leur où de celui de quelqu'un d'autre.
Reprendre sans comprendre n'est pas l'apanage de la nouvelle génération de développeur mais plutôt du jeune développeur qui ne peut pas tout comprendre du premier coup et qui doit parfois se contenter de faire marcher les choses comme il peut sans tout comprendre en profondeur.
Alors entre reprendre du vieux code qui traine sur les disques d'une boite depuis vingt ans et attaquer un développement avec une panoplie de framework à la mode, si je ne peux pas choisir une solution modérée, je choisi la dernière possibilité.
Quant à tout faire soi-même, je crains que les deadlines balaye cette possibilité.
Je pense qu'il n'est pas faux de dire que les gens intègrent trop souvent des framework et librairies sans réfléchir.
La preuve, dans cette discussion, quelqu'un à dit, je cite: "Apres il ne faut pas non plus réinventer la roue, sinon en .Net pourquoi utiliser le Framework, en Java..."
Programmer en .NET. Ces termes montrent à eux seuls ou on en est arrivé.
On en arrive a confondre langage et frameworK...
Par contre, la faute n'en reviens pas exclusivement aux développeurs...
Je ne suis pas vieux (25 ans) mais je constate que quand on lit les offres d'emploi, ce sont les recruteurs qui favorisent cette vision des choses. Il est rarement fait mention de gens qui maîtrisent un langage, mais bien plus souvent des noms de framework. De nos jours, on demande des gens qui programment en Qt, en .NET, en SWING... Pas des programmeurs C++, C# ou java, non non ça on s'en fiche.
Alors qu'une personne maîtrisant son langage sera capable d'acquérir un framework très rapidement, voire même de l'étendre ou d'en isoler l'usage. Elle sera donc capable de s'adapter plus facilement en cas de changement de contraintes, voire même de framework.
Quand aux bibliothèques modulaires, si, bien sûr que ça existe. En fait, la modularité poussée est l'un des intérêts des langages OO.
Ca fait même partie des célèbres pattern GRASP, si je ne m'abuse: le fameux "faible couplage".
Mais c'est régulièrement quelque chose de bien plus simple a dire qu'a faire.
Il est certain que lorsque on se lance dans le développement d’une application informatique l’idéal serait de développer ses propres composants, ainsi on pourrait les optimiser, les fusionner , les documenter , les fractionner comme on le souhaite. Le problème c’est que l’on risque d’être absorbé pour une grande part dans la résolution de problème techniques plus que de problèmes métiers.
Or , le fait d’utiliser des frameworks, permet justement de séparer ces deux préoccupations techniques et métiers,
Le développement d’une application informatique va pouvoir au fur et a mesure de la prise en main des composants des fraùmeworks entierement se focaliser sur le développement des processus métiers
Afin d’éviter que le développement devienne une usine à gaz il faut opter pour un design pattern qui va respecter les exigences de l’application ou construire son propre design pattern sur lequel agencer les composants
Personnellement , je ne pense pas que les framework ou les AGL soit des effets de modes , ce sont des outils qui répondent a un certain nombre de problématiques techniques car beaucoup de problèmes sont récurrents et ont été identifié.
Par contre le problème vient plutôt du fait que les gens qui utilisent les Framework doivent le faire ne connaissance de cause , c'est-à-dire qu’il doivent auparavant avoir développé avec les langages de bases, java, php , c++, visual basic,… pour comprendre ce que va leur apporter le framework par rapport à leur propre expérience.
Concernant le niveau des eleves au BTS SIO je confirme , mais cela est du au fait que la plupart des formateurs en BTS SIO n’ont aucune expérience pratique en entreprise , il doivent juste prodiguer des formations qui obéissent à un référentiel mais ne sont pas capable de prodiguer cet enseignement en le structurant par rapport à une expérience qu’ils aurait eu en entreprise, et pour ceux qui sont capables de le faire bien souvent on ne leur donne pas les moyens.
Ce à quoi je fais la réponse standard de l'ingénieur standard : ça dépend. Dans le lien que j'ai donné, l'auteur dit que l'équipe EXCEL dispose de son propre compilateur. C'est là un outil exclusivement technique. Mais, dans leur cas, c'est un avantage compétitif : par la maitrise de la compilation, ils peuvent garantir la portabilité de leur code sur les OS qui vont bien. Ce qui n'a aucun sens pour un boulanger qui veut faire son site web est fondamental pour eux.
La question à se poser serait plutôt : est-ce que c'est stratégique? Je connais une banque qui a développé son propre outillage de gestion de dates(hypercomplexe), parcequ'elle a des besoins, mmmh, "exotiques" de calcul de dates. pour 99,99% des clients, ça serait abérrant. Pas pour eux. L'existence de cet outillage leur donne un avantage important dans la gestion de leurs données. Permettre à un programmeur ne connaissant pas toutes les arcanes de leurs calculs de date très complexe de bêtement faire appel au module et de traiter le retour est un élément important d'industrialisation pour eux.
A condition que les frameworks soit complets et cohérents. L'article dénonce plutôt l'empilement de frameworks dans tous les sens. Le problème n'est pas d'utiliser des outils, mais d'en empiler sans faire gaffe, par exemple en achetant une gamme complète de forêts quand on a besoin d'un forêt de 12, puis une boite à outils complète parcequ'il y a un mètre ruban dedans.....
je déteste le mot "design pattern", qui remplace trop souvent le mot "reflexion". J'ai le plaisir de voir que pour toi, on peut avoir à réfléchir sur des méthodes un peu plus adaptées à chaque cas.
le problème, encore une fois, c'est l'utilisation anarchique qui peut en être faire.
permet moi de reformuler(et de corriger si je me trompe) : il est nécéssaire de maitriser ses gammes avant de jouer du Rachmaninov.
(je ne commente pas la partie formation, je ne suis pas armé pour ça).
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Tout à fait d'accord avec William Edwards.
Quand je vois les Design Pattern qui sont utilisés à tord et à travers. Il y a aussi le scénario où l'analyse fonctionnelle est bâclé mais c'est pas grave car grâce à la méthode agile on rattrape ça à la volé, c'est de la haute voltige.
William Edwards a tout à fait raison quand il dit que les développeurs cherchent la facilité et dans tous les cas au détriment de la qualité et de la maitrise du projet, sans compter la maintenance et des performances.
Là où j'ai vue le plus de bordel c'est en Java, suivi de très prêt par les projets en .NET quand aux projets Web c'est le top car ça mélange plusieurs technologies et plusieurs langages.
Quand il dit qu'aussi les développeurs utilisent des librairies sans réellement les maitriser c'est aussi vrai. Les gas choisissent ces librairies sans réellement réfléchir si c'est pertinent dans leur cas. Où alors ils ont la fléme de faire 3 fonctions et ils embarquent à la place tout un Framework voir dès fois une application tiers bien lourde bien consommatrice.
Enfin bref je suis content voir que je suis pas le seul a observer le phénomène car je le vis aussi au quotidien.
je suis un développeur "à l'ancienne" et je me trouve embarqué sur des projets dans lesquels fourmillent des librairies incontrolées.
Je fais la part des choses:
- je demande une évaluation de ces utilitaires (documentation, solidité, évolutions)
- bien souvent je réécris (à la main) du code qui remplace plusieurs de ces utilitaires. tout simplement parce que la partie réellement utilisée est petite et peut-être remplacé par un code plus focalisé. oui ce code peut-être moins mature ... mais au moins ce sont mes bugs!
-bien sûr je ne peux pas raisonnablement tout réécrire, donc je limite les librairies et je me repose sur celles qui sont bien évaluées (enfin on essaye).
même si ces reécritures font hurler dans les chaumières l'expérience me confirme qu'il faut s'y tenir: je participe à des codes à très longue durée de vie (10 ans minimum!*sur un précédent projet j'ai tout reécrit -c'était en C- et le code a tourné 12 ans sans anicroche!)
J'ai des principes: je peux toujours trouver une bonne raison pour les contredire .... mais j'ai des principes!
(mon excellent bouquin sur Java : https://eska-publishing.com/fr/livre...822407076.html)
Comme je l'ai dit, je suis entièrement d'accord..
Je pondérerais cependant un peu la "responsabilité"..
Je pense que l'effondrement de l'enseignement "de base" y est pour beaucoup, par omission de réflexes de base : ordres de grandeur et logique en premier..
Le nombre de posts (qui a tendance à diminuer depuis 1 an d'ailleurs, c'est à noter) faisant par exemple référence à des "librairies de calculs sur des grands nombres", ou "une précision de 40 chiffres" et (a été) effarant...
Vu que je suis physicien à l'origine, ce genre de trucs me pose toujours un TRES gros problème : à part en cryptographie, quel est le domaine où une précisiion à 40 chiffres veut dire quelque chose ?? J'avais dans un thread donné l'exemple que même la taille de l'Univers exprimée en Angstrom ne dépasse pas 21 chiffres, et que à cette échelle-là, vu les imprécisions, arriver à 9 est déjà un exploit..
Il semble cependant que ce soit des exercices donnés par des enseignants, pour la plupart, ce qui malheureusement forme des jeunes à utiliser tout et n'importe quoi sans réfléchir à la validité.
J'espère que le bon sens finira par prévaloir, mais donc j'exonérerais un peu la responsabilité desdits jeunes : on ne leur pas appris à réfléchir avec le bon sens et la logique...
Ceci dit, c'est à nous et aux forums sérieux comme DVP de justement redresser un peu la situation en attendant...
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Précision à 40 chiffres... Faut voir le papier. Je ne l'ai pas lu, mais en pratique, peut-être ont-ils cherché à avoir une précision moindre, pour les calculs en bourse par exemple, et que finalement, ils sont arrivés à une précision de 40 chiffres, sans perte de performance.
Dans ce cas, bon... Ben, t'as beaucoup de chiffres, c'est bien.
Le commentaire sur les enseignants : ça dépend beaucoup de la formation, je crois.
C'est vrai que les biblio tendent à intégrer le maximum de fonctionnalités. Résultat : pour faire UN truc on intègre des kilo-octets de code inutile.
Il serait sûrement plus pertinent de faire un ensemble de fonctions simples avec une API durable puis de piocher pour un site toutes les fonctions dont on a besoin et uniquement elles.
C'est ce qui se passe avec certaines biblio que l'on peut "composer" avant de télécharger.
C'est bien vrai !
En informatique au niveau recrutement on met la charrue avec les boeufs. Le premier niveau de sélection est fait par les gens de la DRH. Comme ils connaissent rien à l'informatique ils sélectionnent souvent les gens en fonction de mots clés. Ensuite, si tu passe cette sélection, tu vas peut être rencontrer quelqu'un de technique qui sera à même de juger si tu peux correspondre au besoin de l'entreprise. Le pire c'est quand l'entreprise fait appel à des sociétés pour leur trouver du personnel (soit disant SSII experte ou pire des sociétés de placement). Car les personnes qui recrutent dans ces boites ont très peu ou pas les compétences pour évaluer ton profile correctement mais en plus, comme elles se font une commission sur ton dos, elles enverront à leur client la personne sur qui elles se feront le plus de beurre. C'est rarement celle qui conviendrai le mieux à leur client.
Tu as tout à fait raison. Un bon programmeur se doit de bien maitriser son langage. Attention maitriser son langage ça veut pas dire savoir réciter par coeur le manuel comme je l'ai déjà vue. Une fois maitrisé il doit être capable de s'adapter et plus il a d'expérience plus c'est facile pour lui. Et quand tu commences à avoir un ou deux langages à ton actif en apprendre un nouveau c'est de la rigolade. Tous les concepts de base tu les as assimilés il te reste juste à intégrer les spécificités du nouveau langage. Si en plus le nouveau langage que tu apprends est plus simple que les précédent c'est encore plus facile. Enfin de compte le plus dur c'est le premier langage.
Oui les bibliothèques modulaires effectivement ça existe. Encore faut il choisir la bonne et en connaitre les avantages et les inconvénients. Et si elles font pas l'affaire soit le faire soi-même, soit prendre le temps d'en trouver plus adaptés. De nos jours les développeurs restent bloqués sur leur Framework et essayent de faire tous et n'importe quoi avec. Ils agissent un peu comme un singe qui s'obstine à mettre un carré là où l'emplacement est fait pour un cercle.
Bien souvent un peu d'huile de coudes et de bon sens permettent de résoudre la plus part des problèmes. C'est sur ça demande un peu plus d'effort cérébrale que de prendre la librairie à la mode.
En tout cas je suis content de voir qu'un "petit jeune" comme toi dans la profession est compris tous ça. Et pour être honnête j'en vois pas beaucoup au tour de moi des comme toi. C'est plus des moutons qui suivent les directives de Microsoft (pour ceux qui font du .NET) et qui sont plus proche de mon l'exemple du singe quand il s'agit d'utiliser les Design Pattern, par exemple. Et en plus ils sont têtues comme des mules même quand on essaye de leur montrer qu'il y a des manières plus élégantes et plus adaptés. L'avantage quand on commence à avoir de la bouteille c'est qu'on a rencontré des cas dont tu ne trouveras pas la solution dans des recettes de cuisines comme les Design Pattern. On a aussi appris de nos erreurs ce qui nous permet de voir venir les pbs bien avant qu'ils n'arrivent et on peut les éviter. Tu auras beau lire autant de livres que tu veux tu ne pourras pas acquérir ce savoir. Il faut le vivre ou travailler avec des gens qui ont acquis cette expérience avant toi. Si tu as la chance de travailler avec quelqu'un de plus expérimenté tu vas apprendre et évoluer très rapidement. Personnellement j'ai eu cette chance. Ces personnes m'ont évité de faire des bêtises et m'ont incité à voir les choses différemment. Nos discutions étaient assez "énergique" car je voulais qu'ils m'expliquent leur approche pas simplement que je la mette en pratique. Ça les agacés beaucoup car pour eux tous ça était devenu naturel et ils ne comprenaient pas que ça ne l'était pas encore pour moi. Du coup on a eut de bonnes discussions et j'ai beaucoup aimé ces échanges. Et eux aussi ont apprécié car dans le processus ils apprenaient aussi des choses Peu import son niveau d'expérience en Informatique on peut toujours apprendre quelque chose
Enfin bref continue à faire travailler ta tête et ton bon sens. Ça demande plus d'effort mais ça rend aussi ton boulot beaucoup plus intéressant.
On peut toujours s'y prendre de cinquante manières différentes pour résoudre un problème. Si certains pensent que développer une application, c'est assembler des gros bouts de code qui existent déjà et les adapter, c'est leur problème. Et si quelqu'un accepte de les payer pour faire cela, et est satisfait du résultat, c'est cool. Je tempère tout de même les propos précédents en disant qu'il y a heureusement des types de projets qu'on ne saurait mener à bien en procédant de cette façon, et que personnellement je n'accepte pas de travailler avec quelqu'un qui ne sait QUE bosser de cette façon. Mais ça, c'est juste une question de conviction personnelle, je suis borné, c'est tout.
Je dirais qu'il y a tout de même un seuil d'alerte à ne pas dépasser : c'est le moment où on n'est plus sûr de comprendre vraiment ce qu'on fait, mais où on se persuade quand même que c'est bon puisque "tout marche".
Si ce seuil est atteint, il faut se poser de sérieuses questions et éventuellement faire machine arrière ou accepter l'idée de travailler moins vite pendant un certain temps, cela pour éviter de faire de grosses débileries. Sinon on ne fait plus du développement mais de la sorcellerie, et il n'y a aucune excuse pour faire de la sorcellerie, surtout pas celle de délais prétendument impossibles à tenir autrement.
+1 pour les SSII. Quand j'ai changé de crèmerie, j'ai eu des entretiens avec 6 boites. Aucune ne m'a posé la moindre question technique. La seule chose qu'ils ont testé, c'est "est-ce que ce mec est vendable?". Point. J'aurais pu raconter du pipeau de A à Z sur mon CV, ils ne s'en serait pas rendu compte. Aucun n'a vérifié que j'avais bien les expériences requises. Par contre, "tu est resté 7 ans dans la SSII Schtoumpf. C'est bien, tu est assez loyal, j'aime ça".....(enfin, surtout pour le client si je ne fais pas l'affaire).
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
moi personnellement j'accuse tout le systeme d'enseignement.
l'enseignement s'est laisse invahir par les entreprises. consequense direct on forme pour que l'etudiant soit rentable a sont entreprise, or rentable ici signifie rentable a court terme: il faut que (dans le cas informatique mais valable dans beaucoup d'autre) le dev fasse un logiciel pret a l'emploi donc l'utilisateur/client se plaigne peu ou pas et surtout le plus rapidement possible.
mais quand on est developpeur on sait que la notion de temps que demande une entreprise est inversement proportionnel a la notion de temps requis par un soft tres peu bugge et efficace.
et ne pas reinventer la rue est une chose mais ne pas savoir reinventer la roue en est une plus grave. Il faut savoir le faire tout en ne le faisant qu'a de rareoccasions (surtout quand c'est indispensable).
mais a l'ecole on apprend aujourd'hui au jeune a etre productif car c'est ce que les boites veulent. On apprend plus la conpetence, etre competent est une affaire personnelle.
ayant fais mon master en chine, quand je suis arrive au debut vers 2005, j'etant passionne par la prog, je voulais creer un groupe bla bla bla... donc je suis alle de moi meme vers celui qui s'etait tape un 92/100 a l'examen d'assemble et plein d'autre magnifique note dans d'autre language. mais j'ai fait demi tour quand j'ai vue que malgres c'est 92 il pouvais pas me faire un simple helloword.com et d'ailleur il pouvait non plus me dire si il existait une difference entre un .com et .exe et laquelle si oui. quand a moi j'ai juste eu la moyenne et j'avais pu ecrire un tetris en asm,C et pascal tous en mode graphique avec chargement de pcx pour l'arriere plan.
apres plusieurs annee en chine j'ai compris le system qui demande d'avoir des grosses notes car bonne note=competent (ce qui telement faux) et que vu le nombre de chinois c'est le critere pour faire le trie.
je vois qu'en france aussi on juge sur lecture du cv, nom de l'ecole d'origine du diplome ...
bref tout sauf l'essentiel: la competence du candidat au poste.
Mieux ou pire, je connais des gens qui veule ressembler a cloe o'brian et qui ont des bonnes notes mais peuvent pas reproduire (en visuelle pas en fonctionnaliste) la page d'accueil google. mais il savent bien utilisr jason en js.
Petit lien vers mon premier jeux SDL2/C
http://store.steampowered.com/app/72..._Soul_Of_Mask/
la suite? ca vient,ca vient!
D'un coté c'est logique. Leur boulot c'est de vendre des types et donc ils sélectionnent les type les plus vendable. Après, une fois que le type est vendu, ils ont leur argent donc tout va bien... à court terme. Après le moyen terme... on s'en fout on verra demain
Conséquence d'une politique consistant à l'obligation de faire un certain chiffre tous les mois. Le système devient complètement vicié et implose.
J'ai des principes: je peux toujours trouver une bonne raison pour les contredire .... mais j'ai des principes!
(mon excellent bouquin sur Java : https://eska-publishing.com/fr/livre...822407076.html)
En tant qu'enseignant, je suis un village gaulois à moi tout seul
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
j'accuse pas les enseignants mais les decideurs, ceux qui dictent le prgramme (et souvent n'y connaissent rien)
sinon merci de resister. Vous allez permettre aux generations suivantes de ne pas etre juste des pisseurs de codes, et reflechir un peu a l'heure ou ca devient interdit d'utiliser son cerveau.
Petit lien vers mon premier jeux SDL2/C
http://store.steampowered.com/app/72..._Soul_Of_Mask/
la suite? ca vient,ca vient!
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager