Discussion :

[JeanDeJean]

Je ne comprends pas cette opposition idéologique à l'utilisation de composants... Alors qu'ils sont justement là pour faire gagner du temps aux développeurs, et non pas à briller en société !

Ceux qui passent beaucoup de temps à tout recoder oublient que le fruit de leur travail n'est pas forcément meilleur ou plus facile à maintenir que les composants standards.

Bref, il faut faire les deux, car tout dépend du contexte comme la plupart des commentaires le font remarquer : dans un cas il est stupide d'utiliser tel composant pour telle utilisation restreinte ou erronée, dans un autre il ne faut pas passer des semaines pour tout refaire en moins bien...

[souviron34]

Bonjour

Outre le fait que tu sembles d'acord avec notre version non jusqu-au-boutiste, je me permet de commenter sur :

Alors qu'ils sont justement là pour faire gagner du temps aux développeurs, et non pas à briller en société !

Le fond du problème est bien là : peut-être que ça fait gagner du temps aux développeurs (quoique, les docs et pbes d'intégration sont à prendre en compte), mais ça ne fait pas forcément gagner du temps au projet - et surtout comme on l'a souligné à sa maintenance / évolution.. Or le coût d'un logiciel est et doit tout intégrer..

C'est ce que l'on reproche principalement : penser à courte vue pour un gain de temps maintenant qui va se traduire par une perte très nettement supérieure plus tard..

Alors, avec d'une part le taylorisme forcené, les équipes temporaires, l'appel à des équipes tierces, plus l'obsolescence programmée, cela peut avoir un intérêt, mais pas pour les applis longs termes..

Disons que c'est là le point d'achoppement, comme nombre de mes collègues "bouteilleux" l'ont fait remarqué..

[zelegolas2]

Je ne comprends pas cette opposition idéologique à l'utilisation de composants... Alors qu'ils sont justement là pour faire gagner du temps aux développeurs, et non pas à briller en société !

On n'est pas opposé à l'utilisation de composants à partir du moment où ils sont choisies pour résoudre une problématique tout en tenant en compte les contraintes du projet. Dans la vrai vie c'est souvent n'importe quoi et ça fini généralement par un empilage de couches avec des fonctions redondantes d'une couche à l'autre et personne n'est capable de maintenir ce genre d'usine à gaz. En Java comme en .NET j'ai vécue ce genre de scénario un certain nombre de fois. Et c'est souvent par ce que le responsable du projet c'est fait bourrer le mou par IBM ou Microsoft avec leur dernier framework super génial ou leur super outil du moment. Ou encore mieux quand un commercial d'IBM ou de Microsoft discute directement avec la direction qui se fait refourguer tous un tas de trucs dont l'entreprise n'a pas besoin et qu'il faut ensuite supporter dans l'ensemble des projets. On se retrouve avec des composants super lourds et des environnements complexes. Mais c'est super car à ce moment là le commercial d'IBM ou Microsoft vous met en relation avec des revendeurs de matériels pour booster les serveurs et des SSII agrées pour avoir des "experts" qui vont se faire un plaisir de vous aider (moyennant des factures bien salées). On part d'une bonne idée que sont les composant réutilisables et on fini avec un monstre qui coute plusieurs million d'euros par an.

[Carlvercetty]

Étant étudiant en IT, il est vrai que l'amalgame entre langage et framework est très vite fait. On nous donne par exemple des cours de .NET, au cours desquels on voit des langages tels que le C# et l'ASP.NET. C'est assez aberrant dans ce cas de figure. Cependant, je pense qu'il faut savoir évoluer. Les frameworks sont quand même là pour nous faciliter la vie en tant que développeurs. Vouloir toujours reprendre un projet "from scratch" pour pondre des solutions moins évidentes à maintenir n'est pas forcément la bonne solution. Comme ça a été dit auparavant, je suis d'accord qu'il faut savoir penser au besoin avant de foncer tête baissée. Il y a des fois des APIs lourdes que les développeurs n'utilisent que pour une fonction plutôt que de réfléchir au problème. Dans cette optique, il est clairement inutile d'utiliser l'API et il est plus intéressant de réécrire ses propres outils pour mieux répondre au besoin. Mais il serait dommage de cracher sur des frameworks aussi puissant que le .NET qui permettent quand même de se faciliter la vie. Tout du moins, c'est mon point de vue de "baby developer". =)

[MiaowZedong]

Pour commencer, je pense que la multiplication des composants tiers répond au besoin de coder vite, plus que celui de coder bien.

Je pense que c'est bien un problème générationel, mais pas dans le sens où William Edwards le conçoit. On connait tous la loi de Wirth, mais tout comme la loi de Moore, elle ne s'exprime pas de façon intangible. La loi de Moore s'exprime par des finesses de gravure accrues; celle de Wirth s'exprime par le code bloat généralisé.

Quand on montre un site Web qui charge une librairie JavaScript de 300k à un "vieux" dev qui a connu l'époque des modems 1200 baud et de la RAM qui coûtait une fortune pour 32k, il est scandalisé. C'est normal qu'un jeune dev, à qui on dit qu'il faut 4GiB de RAM minimum pour faire tourner son OS et qui trouve qu'un débit de 2Mb/s est scandaleusement bas, ne trouve pas choquant de charger 300k inutiles ("ce n'est que 300k, c'est rien").

Maintenant, l'important c'est de savoir pourquoi l'on raisonne comme ça et de ne pas le faire bêtement parce que tout le monde le fait. Parfois on peut se permettre de produire une appli qui consomme beaucoup plus de resources que nécessaire, ou qui prend trop de place sur le disque. Ce n'est pas toujours le cas. Parfois aussi les composants tiers vont devenir un cauchemar à mettre à jour, à maintenir. Parfois le délai est trop court, et l'optimisation trop minime; mais parfois le projet est trop critique, et le code bloat trop handicapant.

La seule règle, c'est de prendre le bon outil pour son projet.

[teddyalbina]

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!)

Moi j'ai 26 ans et la dernière fois que j'ai codé un truc qui fonctionne du premier coup et sans aucun bug on m'a reproché le fait de ne pas pouvoir du coup vendre de support étendu au client.

Du coup maintenant je travail deux fois moins vite (on m'a reproché de bosser trop vite du coup même pas le temps de factuer ^^) et je laisse des bugs mais pas trop quand même des trucs simple comme ça on peux facturer au moins 1 an de support .

Je n'ai jamais autant tapé de Quick & Dirty que depuis que je bosse ^^ . Même si sur le projet ou je suis actuellement je fais du refactoring massif parce que les anciens dev sont allés trop loin de le n'importe quoi et que rien ne fonctionnait bien.

[alex_vino]

Moi j'ai 26 ans et la dernière fois que j'ai codé un truc qui fonctionne du premier coup et sans aucun bug on m'a reproché le fait de ne pas pouvoir du coup vendre de support étendu au client.

Il y en a qui font souvent des applis avec 0 bugs... Tiens donc. J'imagine que tu avais une table dans ta base de données et un screen de visualisation

Du coup maintenant je travail deux fois moins vite (on m'a reproché de bosser trop vite du coup même pas le temps de factuer ^^) et je laisse des bugs mais pas trop quand même des trucs simple comme ça on peux facturer au moins 1 an de support .

Je n'ai jamais autant tapé de Quick & Dirty que depuis que je bosse ^^ . Même si sur le projet ou je suis actuellement je fais du refactoring massif parce que les anciens dev sont allés trop loin de le n'importe quoi et que rien ne fonctionnait bien.

C'est avec des entreprises comme la tienne que l'informatique régresse et que ses développeurs stagnent. Change de boite!

[teddyalbina]

Il y en a qui font souvent des applis avec 0 bugs... Tiens donc. J'imagine que tu avais une table dans ta base de données et un screen de visualisation



C'est avec des entreprises comme la tienne que l'informatique régresse et que ses développeurs stagnent. Change de boite!

Ah mais j'ai changé de boite . Pis sisi il y a bien 0 bug dans l'application que j'ai développé, j'en suis très content.

[zelegolas2]

Ce n'est pas un problème de génération entre "vieux" développeurs et "jeune" développeurs mais la manière dont on veut exercer sa profession en faisant un travail de qualité ou non.
C'est vrai que ce n'est pas facile et que nos entreprises veulent que les choses se fassent vite, de plus en plus vite. Du coup on essaye de gagner du temps en s'appuyant sur des composants tiers. Si le choix est fait intelligemment et en toute connaissance les composants tiers permettent d'atteindre cet objectif. Malheureusement ce scénario relève de la fiction quand on se retrouve en entreprise dans la vrai vie. Pourquoi ? Parce que le choix d'outils sont décidés par des responsables qui n'ont souvent qu'une vue d'ensemble et un vernis technique insuffisant. Parce qu'on privilégie des solutions "à la mode" au détriment d'une analyse préalable du besoin qui nous permettrait ensuite de choisir les outils les mieux adaptés à son contexte.
La seule différence entre "jeune" développeurs et "vieux" développeurs c'est que le jeune qui sort de l'école a été formé pour trouver normale d'empiler les couches et qu'il ne connait rien d'autre. Il a été formé en fonction de la "mode" du moment. Cette mode est sponsorisé par de grosses entreprises qui plus tard vous refourguera tous leurs produits. Certains jeunes, qui toute fois réfléchissent par eux-même, trouvent cette logique d'empilement dur à avaler et se demandent si on peut faire mieux, ils s'inquiètent aussi de ces effets de modes qui par nature sont changeantes ou devrais je plutôt dire que les entreprises qui les font les changes au fur et à mesure de leur chiffre d'affaire. Le "vieux" développeur pour aller plus vite va lui aussi empiler les couches pour respecter ses délais ou parce que sa direction lui impose les outils qu'il doit utiliser tous simplement, mais il le fera la mort dans l'âme (pour ceux qui ont à coeur leur travail et leur entreprise) car, sans parler de réinventer la roue, si on lui donnait le temps de bien faire son travail il pourrait mieux utiliser les composants à sa disposition grâce à l'expérience qu'il a acquise. D'autre part opposer "jeune" vs "vieux" en Informatique c'est une idée tellement ridicule. Car si vous croyez qu'une fois sortie de l'école vous serez tranquille pour les 40 prochaine années c'est FAUX !!! Ne choisissez pas l'option Informatique si vous croyez ça. Un Informaticien c'est quelqu'un qui commence sa formation à l'école ET qui continue à se former tout au long de sa carrière. N'oubliez pas non plus que ce que vous apprenez dans vos manuels les "vieux" les ont vécus et expérimentés bien avant que vos manuels ne soient mis sous presse. Alors dites vous bien que quand vous commencerez à travailler vous devrez vous mettre à niveau pour intégrer ce qui se fait (bon ou mauvais) en entreprise. Si vous aimez apprendre et travailler dans une profession en perpétuel évolution vous allez adorer l'informatique, sinon changez d'orientation pour une profession moins exigeante.

[deathness]

Ce n'est pas un problème de génération entre "vieux" développeurs et "jeune" développeurs mais la manière dont on veut exercer sa profession en faisant un travail de qualité ou non.
C'est vrai que ce n'est pas facile et que nos entreprises veulent que les choses se fassent vite, de plus en plus vite. Du coup on essaye de gagner du temps en s'appuyant sur des composants tiers. Si le choix est fait intelligemment et en toute connaissance les composants tiers permettent d'atteindre cet objectif. Malheureusement ce scénario relève de la fiction quand on se retrouve en entreprise dans la vrai vie. Pourquoi ? Parce que le choix d'outils sont décidés par des responsables qui n'ont souvent qu'une vue d'ensemble et un vernis technique insuffisant. Parce qu'on privilégie des solutions "à la mode" au détriment d'une analyse préalable du besoin qui nous permettrait ensuite de choisir les outils les mieux adaptés à son contexte.
La seule différence entre "jeune" développeurs et "vieux" développeurs c'est que le jeune qui sort de l'école a été formé pour trouver normale d'empiler les couches et qu'il ne connait rien d'autre. Il a été formé en fonction de la "mode" du moment. Cette mode est sponsorisé par de grosses entreprises qui plus tard vous refourguera tous leurs produits. Certains jeunes, qui toute fois réfléchissent par eux-même, trouvent cette logique d'empilement dur à avaler et se demandent si on peut faire mieux, ils s'inquiètent aussi de ces effets de modes qui par nature sont changeantes ou devrais je plutôt dire que les entreprises qui les font les changes au fur et à mesure de leur chiffre d'affaire. Le "vieux" développeur pour aller plus vite va lui aussi empiler les couches pour respecter ses délais ou parce que sa direction lui impose les outils qu'il doit utiliser tous simplement, mais il le fera la mort dans l'âme (pour ceux qui ont à coeur leur travail et leur entreprise) car, sans parler de réinventer la roue, si on lui donnait le temps de bien faire son travail il pourrait mieux utiliser les composants à sa disposition grâce à l'expérience qu'il a acquise. D'autre part opposer "jeune" vs "vieux" en Informatique c'est une idée tellement ridicule. Car si vous croyez qu'une fois sortie de l'école vous serez tranquille pour les 40 prochaine années c'est FAUX !!! Ne choisissez pas l'option Informatique si vous croyez ça. Un Informaticien c'est quelqu'un qui commence sa formation à l'école ET qui continue à se former tout au long de sa carrière. N'oubliez pas non plus que ce que vous apprenez dans vos manuels les "vieux" les ont vécus et expérimentés bien avant que vos manuels ne soient mis sous presse. Alors dites vous bien que quand vous commencerez à travailler vous devrez vous mettre à niveau pour intégrer ce qui se fait (bon ou mauvais) en entreprise. Si vous aimez apprendre et travailler dans une profession en perpétuel évolution vous allez adorer l'informatique, sinon changez d'orientation pour une profession moins exigeante.

Petit conseil : découpe ton texte en paragraphe, c'est bien plus facile a lire derrière

[Luckyluke34]

Prenez une bonne idée : utiliser des composants tierce partie pour ne pas réinventer la roue à chaque fois.

Poussez-la à l'extrême - fourrez dans votre projet tous les nouveaux frameworks à la mode sans discernement. Cela devient bien évidemment ridicule et contre-productif.

Comme tous les abus, l'abus d'outils shiny et en vogue est néfaste. Pas besoin d'être sorcier pour comprendre ça...

[davcha]

Comment faire la différence entre un abus et une utilisation correcte ?

Je ne parle pas des cas évidents, bien sûr. Je parle des cas où on peut se poser la question, sincèrement, avant de se lancer dans l'utilisation de tel ou tel composant : est-ce qu'utiliser ce composant va vraiment être une bonne chose ?
Comment faire ça, alors qu'on a pas de connaissance précise du composant, qu'on a pas de connaissance précise sur les besoins réels du projet... ?

[deathness]

Comment faire la différence entre un abus et une utilisation correcte ?

Je ne parle pas des cas évidents, bien sûr. Je parle des cas où on peut se poser la question, sincèrement, avant de se lancer dans l'utilisation de tel ou tel composant : est-ce qu'utiliser ce composant va vraiment être une bonne chose ?
Comment faire ça, alors qu'on a pas de connaissance précise du composant, qu'on a pas de connaissance précise sur les besoins réels du projet... ?

C'est pour ça que pour moi la question est mal posée. Il faut plutôt se demander sur quels critères il faut se baser pour décider quand il faut empiler des composants externes ou non.

Du genre est que c'est open ou close-source, sur un segment critique ou non, sujet à évolution ou non, ...

[souviron34]

Comment faire ça, alors qu'on a pas de connaissance précise du composant, qu'on a pas de connaissance précise sur les besoins réels du projet... ?

Je dirais que le problème est posé à l'envers

• Primo il faut avoir déterminé les besoins réels du projet
  
  
• Secondo il faut évaluer précisément les possibilités de composants externes (les différents fournisseurs, les différences fines entre chaque propostion)
  
  
• Tertio, éventuellement décider de l'utiliser..

Si effectivement on utilise sans analyse préalabe, c'est encore pire que tout...

Est-ce que c'est comme ça qu'on fait dans ta boîte ????

Parce que ce que j'ai exposé ci-dessus est la base même d'une réflexion logique... Sans plus.. Donc là tu me fais réellement douter de ce qui se passe...

[el_slapper]

(.../...)Est-ce que c'est comme ça qu'on fait dans ta boîte ????

Ce que j'ai vu, c'est un directeur de projet qui avait sa prime de 2008 seulement si il installait un progiciel dans le fonctionnement de l'équipe. Donc il a installé un progiciel(hors de prix, utile une dizaine d'heures par an). Les surcouches (quasiment) inutiles peuvent avoir plein d'origines différentes

ça ne me surprendrait pas que des commerciaux imposent l'usage de technologies à la mode sur un forfait(tout simplement parceque c'est ce qu'ils sont vendu). Je ne fait quasiment pas de forfait, et le peu que j'ai fait, c'est sur des technos de dinosaure. Mais, connaissant les requins, ça ne me surprendrait pas.

ça, plus le nullard recruté en sortie d'école parcequ'il a un beau diplôme(eu uniquement grâce à ses 19/20 en Anglais, vu que ses parents lui ont payé une année de lycée aux States) qui ne comprend rien à la programmation, trouve une "solution" à son problème qui nécéssite tel framework, et qui va rajouter tout un framework à un projet Java juste pour pouvoir faire une regex comme il a trouvé sur internet(alors qu'il y a d'excellentes solution regex simples en natif java, il me semble).

Tout ça, ça amène a des solutions, hum, lourdissimmes et inmaintenables.

[gangsoleil]

entre la vision "académique" du développement et la réalité économique il y a un monde. Le but c'est de torcher un truc pour remplir les objectifs annuels. Dans 10 ans on s'en fout, on sera plus là. C'est triste mais c'est comme ça.

C'est ce que m'a explique mon N+2 : tu fais le truc en 5 jours, et on n'en parle plus.

Je lui ai repondu que des N+2, j'en avais vu 5 en 3 ans, mais que par contre moi j'etais toujours la, et que je maintenais les codes que j'avais ecris depuis le debut, plus d'autres.

Il a visiblement compris que je ne lui ferai pas une merde en 5 jours, mais que je ferai un truc maintenable dans le temps que j'avais estime.

Ce logiciel, qui a donc pris plus de temps, n'a eu qu'un ou deux bugs mineurs en prod, jamais d'interruption de service, jamais d'operations de maintenance la nuit ou le week-end.

Tu crois vraiment que si je l'avais fait en 5 jours ca aurait ete pareil ? Non.

[davcha]

Je dirais que le problème est posé à l'envers

• Primo il faut avoir déterminé les besoins réels du projet
  
  
• Secondo il faut évaluer précisément les possibilités de composants externes (les différents fournisseurs, les différences fines entre chaque propostion)
  
  
• Tertio, éventuellement décider de l'utiliser..

Si effectivement on utilise sans analyse préalabe, c'est encore pire que tout...

Est-ce que c'est comme ça qu'on fait dans ta boîte ????

Parce que ce que j'ai exposé ci-dessus est la base même d'une réflexion logique... Sans plus.. Donc là tu me fais réellement douter de ce qui se passe...

Je réfléchissais juste à la façon dont les concepteurs de composants pouvaient décider si une fonctionnalité était la bienvenue ou si elle était de trop.

Autrement dit : sans connaissance précise du produit final dans lequel le composant sera utilisé, comment définir les limites des fonctionnalités d'un composant ?

Une analogie, puisqu'on parle de réinventer la roue... Une roue de voiture. C'est un composant. Elle un a cadre très bien défini. Aucun constructeur n'a encore eu la "bonne idée" d'ajouter un système aux pneus qui permet de téléphoner en prenant des photos et de les envoyer sur X réseaux sociaux bien à la mode.

Pourquoi donc on se retrouve avec des "composants" en informatique qui sont eux-même des usines à gaz ?

La question est mieux posée ?

[souviron34]

Je réfléchissais juste à la façon dont les concepteurs de composants pouvaient décider si une fonctionnalité était la bienvenue ou si elle était de trop.

Autrement dit : sans connaissance précise du produit final dans lequel le composant sera utilisé, comment définir les limites des fonctionnalités d'un composant ?
...

La question est mieux posée ?

Oui

Je comprend mieux ton message, alors...

Pourquoi donc on se retrouve avec des "composants" en informatique qui sont eux-même des usines à gaz ?

La question est mieux posée ?

Je suppose que c'est parce que les gens qui les font font un truc et le rende public / veulent le publiciser / vendre : c'est à la mode, ça fait parler de soi...

Mais dans la plupart des belles (et connues) biblothèques, les gens (en tous cas pour les anciennes biblothèques) étaient intelligents et avaient réfléchi au problème, et par conséquent avaient fait des trucs corrects sans usines à gaz : les sources du décodeur/encodeur de MPEG, ceux de ftp, ceux de la lib GIF ou JPEG, , la bibliothèque MINUIT de maths, celle de X11, celle de Motif, etc etc : les composants sont simples et prévoient tout ce qu'on peut en attendre - sans plus - comme interface et/ou paramètrage..

[I_believe_in_code]

C'est ce que m'a explique mon N+2 : tu fais le truc en 5 jours, et on n'en parle plus.

Je lui ai repondu que des N+2, j'en avais vu 5 en 3 ans, mais que par contre moi j'etais toujours la, et que je maintenais les codes que j'avais ecris depuis le debut, plus d'autres.

Il a visiblement compris que je ne lui ferai pas une merde en 5 jours, mais que je ferai un truc maintenable dans le temps que j'avais estime.

Ce logiciel, qui a donc pris plus de temps, n'a eu qu'un ou deux bugs mineurs en prod, jamais d'interruption de service, jamais d'operations de maintenance la nuit ou le week-end.

Tu crois vraiment que si je l'avais fait en 5 jours ca aurait ete pareil ? Non.

Ah ! Un témoignage de résistant ! Cela fait plaisir de voir qu'on peut encore utiliser son cerveau en 2012. C'est si ringard de bien faire son travail.

[pseudocode]

Partagez-vous le point de vue de William Edwards ?

Hum... Je dirais que ce n'est pas la faute du framework si le développeur code ou conçoit mal son application.

Cela dit, la démocratisation des librairies/frameworks et la prolifération des tutoriels/examples/helloword permet à n'importe quel développeur "junior" de pouvoir rapidement utiliser une technologie qu'il ne maitrise pas.

Je m'inclus volontiers dans ce cas, malgré mon age avancé . Ma curiosité me fait encore tester le dernier langage/outil/techno à la mode ou qui fait le buzz... A coups de tuto et de farfouillage sur les wiki, on arrive a faire une application fonctionnelle. Mais de là a penser que c'était le "meilleur" choix possible : non. Faut être réaliste, le bling-bling-buzzword est rarement le meilleur choix.

Pensez-vous que le choix de plusieurs outils récents pour développer un produit n’est pas le meilleur ?

Qui dit outils récents, dit aussi peu de retour sur les bonnes pratiques d'utilisation de l'outil. Une technologie ca prend du temps pour être mature. Et ca en prend tout autant pour en connaitre les usages, les limites et les dangers... Vous souvenez vous du bon vieux temps où les char*/strcpy et les requêtes SQL forgées à la main ne représentaient aucun risque de sécurité ?

Vous reconnaissez-vous dans sa définition d’un “développeur moderne” ? Et que lui répondriez-vous ?

A titre personnel, j'ai toujours plaisir a bidouiller les nouvelles technos. Mais à titre professionnel, je n'envisagerais jamais de jouer aux legos avec des briques technologiques que je ne maitrise pas et que je connais de l'avant-veille.