Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 4 sur 8 PremièrePremière 12345678 DernièreDernière
Affichage des résultats 61 à 80 sur 157
  1. #61
    Invité régulier
    Inscrit en
    mars 2012
    Messages
    1
    Détails du profil
    Informations forums :
    Inscription : mars 2012
    Messages : 1
    Points : 5
    Points
    5

    Par défaut Pas d'accord

    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...

  2. #62
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 183
    Détails du profil
    Informations personnelles :
    Âge : 57

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 183
    Points : 14 353
    Points
    14 353

    Par défaut

    Bonjour

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

    Citation Envoyé par JeanDeJean Voir le message
    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é..
    "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

  3. #63
    Membre habitué
    Profil pro
    Inscrit en
    avril 2011
    Messages
    81
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2011
    Messages : 81
    Points : 146
    Points
    146

    Par défaut

    Citation Envoyé par JeanDeJean Voir le message
    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.

  4. #64
    Invité de passage
    Homme Profil pro
    Étudiant
    Inscrit en
    mars 2012
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2012
    Messages : 1
    Points : 1
    Points
    1

    Par défaut

    É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". =)

  5. #65
    Expert Confirmé
    Avatar de MiaowZedong
    Grand Timonier des Chats
    Inscrit en
    décembre 2011
    Messages
    681
    Détails du profil
    Informations professionnelles :
    Activité : Grand Timonier des Chats

    Informations forums :
    Inscription : décembre 2011
    Messages : 681
    Points : 2 633
    Points
    2 633

    Par défaut

    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.

  6. #66
    Membre éprouvé
    Avatar de teddyalbina
    Homme Profil pro
    Développeur .Net,C++
    Inscrit en
    janvier 2008
    Messages
    466
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .Net,C++

    Informations forums :
    Inscription : janvier 2008
    Messages : 466
    Points : 431
    Points
    431

    Par défaut

    Citation Envoyé par professeur shadoko Voir le message
    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.
    Viva la viva... en el chorizo de la corida de leon.... (cette phrase n'a aucun sens je sais )

  7. #67
    Membre Expert

    Homme Profil pro Gilles Vino
    Software Developer
    Inscrit en
    mars 2008
    Messages
    1 474
    Détails du profil
    Informations personnelles :
    Nom : Homme Gilles Vino
    Localisation : Royaume-Uni

    Informations professionnelles :
    Activité : Software Developer

    Informations forums :
    Inscription : mars 2008
    Messages : 1 474
    Points : 2 372
    Points
    2 372

    Par défaut

    Citation Envoyé par teddyalbina Voir le message
    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

    Citation Envoyé par teddyalbina Voir le message
    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!

  8. #68
    Membre éprouvé
    Avatar de teddyalbina
    Homme Profil pro
    Développeur .Net,C++
    Inscrit en
    janvier 2008
    Messages
    466
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .Net,C++

    Informations forums :
    Inscription : janvier 2008
    Messages : 466
    Points : 431
    Points
    431

    Par défaut

    Citation Envoyé par alex_vino Voir le message
    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.
    Viva la viva... en el chorizo de la corida de leon.... (cette phrase n'a aucun sens je sais )

  9. #69
    Membre habitué
    Profil pro
    Inscrit en
    avril 2011
    Messages
    81
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2011
    Messages : 81
    Points : 146
    Points
    146

    Par défaut

    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.

  10. #70
    Expert Confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2008
    Messages
    1 163
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2008
    Messages : 1 163
    Points : 2 612
    Points
    2 612

    Par défaut

    Citation Envoyé par zelegolas2 Voir le message
    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

  11. #71
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    282
    Détails du profil
    Informations forums :
    Inscription : janvier 2011
    Messages : 282
    Points : 833
    Points
    833

    Par défaut

    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...

  12. #72
    Membre Expert Avatar de davcha
    Profil pro
    Inscrit en
    avril 2004
    Messages
    1 257
    Détails du profil
    Informations personnelles :
    Âge : 33
    Localisation : France

    Informations forums :
    Inscription : avril 2004
    Messages : 1 257
    Points : 1 399
    Points
    1 399

    Par défaut

    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... ?

  13. #73
    Expert Confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2008
    Messages
    1 163
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2008
    Messages : 1 163
    Points : 2 612
    Points
    2 612

    Par défaut

    Citation Envoyé par davcha Voir le message
    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, ...

  14. #74
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 183
    Détails du profil
    Informations personnelles :
    Âge : 57

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 183
    Points : 14 353
    Points
    14 353

    Par défaut

    Citation Envoyé par davcha Voir le message
    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...
    "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

  15. #75
    Expert Confirmé Sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    3 151
    Détails du profil
    Informations personnelles :
    Localisation : France, Val d'Oise (Île de France)

    Informations forums :
    Inscription : décembre 2007
    Messages : 3 151
    Points : 10 330
    Points
    10 330

    Par défaut

    Citation Envoyé par souviron34 Voir le message
    (.../...)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.
    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.

  16. #76
    Modérateur
    Avatar de gangsoleil
    Profil pro
    R&D en systemes informatiques bas niveau Unix/Linux
    Inscrit en
    mai 2004
    Messages
    8 627
    Détails du profil
    Informations personnelles :
    Âge : 34
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : R&D en systemes informatiques bas niveau Unix/Linux

    Informations forums :
    Inscription : mai 2004
    Messages : 8 627
    Points : 23 999
    Points
    23 999

    Par défaut

    Citation Envoyé par PomFritz Voir le message
    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.
    Modérateur "C", "Informatique Générale & Hardware" et "Unix"
    Les règles du forum

  17. #77
    Membre Expert Avatar de davcha
    Profil pro
    Inscrit en
    avril 2004
    Messages
    1 257
    Détails du profil
    Informations personnelles :
    Âge : 33
    Localisation : France

    Informations forums :
    Inscription : avril 2004
    Messages : 1 257
    Points : 1 399
    Points
    1 399

    Par défaut

    Citation Envoyé par souviron34 Voir le message


    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 ?

  18. #78
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 183
    Détails du profil
    Informations personnelles :
    Âge : 57

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 183
    Points : 14 353
    Points
    14 353

    Par défaut

    Citation Envoyé par davcha Voir le message
    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...

    Citation Envoyé par davcha Voir le message
    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..
    "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

  19. #79
    Membre Expert Avatar de I_believe_in_code
    Inscrit en
    décembre 2008
    Messages
    220
    Détails du profil
    Informations personnelles :
    Âge : 37

    Informations forums :
    Inscription : décembre 2008
    Messages : 220
    Points : 1 024
    Points
    1 024

    Par défaut

    Citation Envoyé par gangsoleil Voir le message
    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.

  20. #80
    Rédacteur/Modérateur
    Avatar de pseudocode
    Homme Profil pro Xavier Philippeau
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    9 960
    Détails du profil
    Informations personnelles :
    Nom : Homme Xavier Philippeau
    Âge : 41
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 9 960
    Points : 15 759
    Points
    15 759

    Par défaut

    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.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •