IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

La qualité du code a-t-elle foutu le camp chez les programmeurs ?


Sujet :

Débats sur le développement - Le Best Of

  1. #61
    Nouveau membre du Club
    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    Avril 2007
    Messages
    24
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : Avril 2007
    Messages : 24
    Points : 27
    Points
    27
    Par défaut
    Je penses qu'on peut pas comparer les développeurs des deux époques ainsi la manière et méthodologie employées et cela pour plusieurs raisons dont le budget et le temp de réalisation des projets ont considérablement baissés, les besoins et les attentes des clients ont également changés.

    Pour moi la question important est : Qu'est ce que réellement un bon développeur d'un mouvais et au profit de qui ?!
    Est ce au profit de son entreprise et du client parce qu'il répond rapidement aux besoins fonctionnels ou au profit de l'application parce que elle bien développée ?

    Je penses qu'il sera difficile de généraliser la réponse, chaque projet a ses besoins et contraintes ainsi son budget.

  2. #62
    Futur Membre du Club
    Profil pro
    Inscrit en
    Novembre 2009
    Messages
    3
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2009
    Messages : 3
    Points : 5
    Points
    5
    Par défaut L'architecture est importante
    Lamport est peut être un vieux grigou (comme moi) mais il met en avant un problème réel aujourd'hui (probablement encouragé/accentué par les méthodes agiles dans un mode intégriste comme a celà été dit dans le forum.) Au delà de la qualité du code, se profile une évolution vers une ingénierie (quand il y en a) du logiciel
    sans un minimum de conception et d'architecture, sans plan global en fait.
    Je suis toujours surpris du nombre de projets dans lesquels des équipes importantes travaillent avec les post it de la méthode agile (le process de développement est documenté) et sans schéma sur la structure de ce qu'ils sont en train de faire (l'architecture et la conception ne sont pas documentées).

    Je partage la vision de Simon Brown.

    http://www.codingthearchitecture.com/

  3. #63
    Futur Membre du Club
    Profil pro
    Inscrit en
    Novembre 2009
    Messages
    3
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2009
    Messages : 3
    Points : 5
    Points
    5
    Par défaut
    Citation Envoyé par Marco46 Voir le message
    Un développeur professionnel travaille au sein d'une équipe et doit rendre compte à une hiérarchie qui doit elle-même rendre compte à ses clients.

    Et puis quid des tests unitaires et de l'intégration continue qui se mettent en place depuis quelques années ? Ces pratiques pénètrent de plus en plus les entreprises. Aujourd'hui les dernières techno web sont capables de faire de même ( AngularJS ). C'est pas une progression dans la qualité ça ?

    Grand respect pour ses créations mais on dirait plus un savant fou dans une tour d'ivoire qui juge la populace sans ne l'avoir jamais rencontrée.
    On peut très bien avoir un logiciel parfaitement testé et intégré avec du code affreux ( qui ne passe pas à l'échelle, qui ne gère pas tous les cas d'erreur, peu performant, pas maintenable, etc).

  4. #64
    Membre éprouvé Avatar de Simara1170
    Homme Profil pro
    Développeur Delphi
    Inscrit en
    Avril 2014
    Messages
    423
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Delphi
    Secteur : Enseignement

    Informations forums :
    Inscription : Avril 2014
    Messages : 423
    Points : 1 154
    Points
    1 154
    Par défaut
    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...
    Citation Envoyé par deuche
    Il y a encore à peine 150 ans, nous vivions encore comme il y a environ 2000 ans.

  5. #65
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par Simara1170 Voir le message
    J'entends parler de théorèmes de maths complexes, et je dois avouer que quelque part, ça me bloque...
    Les maths se développent pour résoudre des problèmes, les solutions peuvent être complexe.
    Cela dit, en France les maths suivent des programmes à vu très sélectives... Il existe beaucoup de math simple, implémentable et utile que l'on ne trouve pas dans les cours de math jusqu'à bac+2 ( pire jusqu'à bac+5 )...

    Citation Envoyé par Simara1170
    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...
    Non, les math ne sont pas des modèles mais plus des outils, là encore il faut se comprendre et donc parler la même "langue" donc connaitre vraiment comment appliquer.
    L'exemple d'openssl est clair des maths difficiles (courbes elliptiques, groupes, ... non accessible à tout le monde) et l'implémentation en C, un expert en C trouvera peut-être le bug mais ne comprendra rien au code

    Citation Envoyé par Simara1170
    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é...
    C'est en gros la méthode agile (dans l'esprit) sauf que dans la "vraie" il y a plusieurs personnes et donc des quelques règles.

    Citation Envoyé par RedGuff Voir le message
    La programmation agile (pas de planifications, changements continuels, pas de traces, déresponsabilisations de la hiérarchie, vues à très court terme uniquement...) a fortement baissé la qualité produite.
    On voit ci-dessus quelqu'un qui y arrive très bien

  6. #66
    Inactif  
    Homme Profil pro
    Analyste-Programmeur / Intégrateur ERP
    Inscrit en
    Mai 2013
    Messages
    2 511
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Analyste-Programmeur / Intégrateur ERP
    Secteur : Bâtiment

    Informations forums :
    Inscription : Mai 2013
    Messages : 2 511
    Points : 10 335
    Points
    10 335
    Par défaut
    Citation Envoyé par valkirys Voir le message

    On voit ci-dessus quelqu'un qui y arrive très bien
    Oui enfin, c'est toujours un peu plus facile de gérer un projet convenablement, quand c'est toi qui impose les délais, et que tu as le client a proximité ET qu'il a du temps de dispo à t'accorder, ce qui est rarement le cas...

    On a pas toujours la possibilité d'aller voir le client en disant "Houston on a un problème, ça va prendre 15 jours de plus"

  7. #67
    Membre éprouvé Avatar de Simara1170
    Homme Profil pro
    Développeur Delphi
    Inscrit en
    Avril 2014
    Messages
    423
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Delphi
    Secteur : Enseignement

    Informations forums :
    Inscription : Avril 2014
    Messages : 423
    Points : 1 154
    Points
    1 154
    Par défaut
    J'ai jamais dit que j'étais pas pas un privilégié, hein
    J'ai parfaitement conscience qu'il s'agît presque d'une utopie d'avoir de telles conditions de travail. Et c'est le problème, à mon sens, le modèle de dev' devrait tourner comme ça de manière standard...
    Citation Envoyé par deuche
    Il y a encore à peine 150 ans, nous vivions encore comme il y a environ 2000 ans.

  8. #68
    Inactif  
    Homme Profil pro
    Analyste-Programmeur / Intégrateur ERP
    Inscrit en
    Mai 2013
    Messages
    2 511
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Analyste-Programmeur / Intégrateur ERP
    Secteur : Bâtiment

    Informations forums :
    Inscription : Mai 2013
    Messages : 2 511
    Points : 10 335
    Points
    10 335
    Par défaut
    On est bien d'accord, tout les dev réveraient d'avoir un cdc complet et exhaustif, avec un délai de dev correspondant à la réalité du projet, et des interlocuteurs réactifs et disponibles etc etc

    Mais la on est un peu comme dans la pub de Gad "je rêve d'une banque..."


    Après heureusement qu'il y a quand des boites, comme la tienne apparement, où cela existe, sinon cela voudrait dire que les devs ne sont qu'une belle bande de maso

  9. #69
    Membre éprouvé Avatar de Simara1170
    Homme Profil pro
    Développeur Delphi
    Inscrit en
    Avril 2014
    Messages
    423
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Delphi
    Secteur : Enseignement

    Informations forums :
    Inscription : Avril 2014
    Messages : 423
    Points : 1 154
    Points
    1 154
    Par défaut
    Après réflexion, je me dit que ça doit être le cas de pas mal de monde en fait: je bosse dans une faculté, mais de taille réduite: c'est en gros une fac pour "adultes", pour ceux qui reprennent les études en règle générale. Donc on a 300 personnes, mais si on enlève les profs qui n'utilisent pas nos programmes (gestion interne de la "société"), on doit avoir 50 users à tout casser... On est 4 au SI, un orienté Hardware, un webmaster et deux dev Delphi... Donc on est dans un micro système, ce qui nous donne cette flexibilité...
    Le problème, c'est quand on tombe dans les projets pharaoniques, ou les problèmes de com', à cause du nombre d'intervenants deviennent majoritaires...

    Pourquoi sur ces projets n'appliquerions nous pas ce genre d'écosystèmes?
    Chaque équipe de dev' étant le fournisseurs d'une autre (par exemple les mecs qui taffent à créer une bibliothèques pour tracer des polygones, sont les fournisseurs de ceux qui développent le moteur graphique). On aurait une meilleure réactivité, et le code étant plus décomposé en modules unitaires, seraient plus facilement maintenable?
    (Qui n'a jamais hurlé en voyant une fonction faire un calcul ET gérer l'affichage de celui-ci?)
    Citation Envoyé par deuche
    Il y a encore à peine 150 ans, nous vivions encore comme il y a environ 2000 ans.

  10. #70
    Membre chevronné
    Avatar de Pelote2012
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Mars 2008
    Messages
    925
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Haute Vienne (Limousin)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2008
    Messages : 925
    Points : 1 839
    Points
    1 839
    Billets dans le blog
    2
    Par défaut
    En plus, mettre au clair le projet avant, n'est pas une perte de temps ... en général c'est un gain de temps, car de nombreux problèmes techniques sont mis en avant, ce qui facilite les choix à faire ...
    Si débugger est l'art d'enlever les bugs ... alors programmer est l'art de les créer

  11. #71
    Inactif  
    Homme Profil pro
    Analyste-Programmeur / Intégrateur ERP
    Inscrit en
    Mai 2013
    Messages
    2 511
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Analyste-Programmeur / Intégrateur ERP
    Secteur : Bâtiment

    Informations forums :
    Inscription : Mai 2013
    Messages : 2 511
    Points : 10 335
    Points
    10 335
    Par défaut
    Citation Envoyé par Simara1170 Voir le message
    Après réflexion, je me dit que ça doit être le cas de pas mal de monde en fait: je bosse dans une faculté, mais de taille réduite: c'est en gros une fac pour "adultes", pour ceux qui reprennent les études en règle générale. Donc on a 300 personnes, mais si on enlève les profs qui n'utilisent pas nos programmes (gestion interne de la "société"), on doit avoir 50 users à tout casser... On est 4 au SI, un orienté Hardware, un webmaster et deux dev Delphi... Donc on est dans un micro système, ce qui nous donne cette flexibilité...
    Le problème, c'est quand on tombe dans les projets pharaoniques, ou les problèmes de com', à cause du nombre d'intervenants deviennent majoritaires...

    Pourquoi sur ces projets n'appliquerions nous pas ce genre d'écosystèmes?
    Chaque équipe de dev' étant le fournisseurs d'une autre (par exemple les mecs qui taffent à créer une bibliothèques pour tracer des polygones, sont les fournisseurs de ceux qui développent le moteur graphique). On aurait une meilleure réactivité, et le code étant plus décomposé en modules unitaires, seraient plus facilement maintenable?
    (Qui n'a jamais hurlé en voyant une fonction faire un calcul ET gérer l'affichage de celui-ci?)

    Même dans des petites structures, les problèmes de com ou les délais improbables existent. Je suis dans une PME, et la plupart des responsables de service, même si ils ont conscience des améliorations et du gain de temps que peuvent leur apporter des dev, sont plus du genre "je voudrais un truc qui fasse X, Y, et Z stp car ça me ferait gagner sur ça , ça et ça", bon ok, puis pendant 1 semaine presque tous les jours "ah au fait si ça pouvais faire ça aussi, puis ça,... Et techniquement c'est possible de faire ça ?", et après faut quand même le recontacter de ton côté, car bien entendu, il faut que cela fasse tout ça, mais pas une fois on ne t'a dit comment cela devait se comporter lors de tel ou tel cas particulier.

    Mon responsable considérant que l'on est un service support, devant dire "Amen" à toutes les demandes des responsables des autres services métiers, sans se poser de question ni rien "exigé" (si je puis le dire ainsi) de leur part... Il m'a fallu pratiquement 2 ans et quelques projets que l'on a du faire, et reprendre et rereprendre, etc pour qu'il commence enfin à leurs demander un minimum de cdc écrit après une reflexion de leur part d'un côté, puis avec nous suite à une réunion par la suite, histoire qu'ils essaient de définir au mieux leurs besoins dès le départ, car en tant que responsable de service, certains sont plus archi-overbooké, et cela devient presque impossible d'avoir des infos rapidement en cas de blocage ou autres...


    Tout dev serait ok pour fonctionner comme il faut, la ou cela bloque c'est plus au niveau des responsables/commerciaux/etc etc qui vendent des délais sur des cdc incomplets sans faire attention et c'est aux devs de s'adapter.

    Tout projet n'a pas besoin d'être énorme pour qu'il y ait des problèmes, une mauvaise organisation, ou un commerciale qui vend des gens non-qualifiés en tant qu'expert pour un délai trop court car ce qui l'intérrèsse lui, c'est le nombre de clients finaux et le nombre de jours qu'il va leur vendre, peu importe les problèmes techniques derrière.

  12. #72
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Zirak, il me semble que vous avez un peoblème de gestion des priorités et du stock de tâches. Ca tombe bien, developpez vient de publier un article assez complet sur le sujet.

    Le point de ce long article que je retiens et qui semble coller à ta situation, c'est que quand on demande aux gens de choisir les priorités, soudain, plein de choses paraissent moins indispensables. Mettons qu'ils te demandent 15 tâches. Tu va associer un "cout"(peu importe l'unité) à chacune des tâches. Tu leur donne 15 cartes avec la tache et le cout associé. Et tu leur demande de trier(en prenant en compte le cout). Mettons qu'au bout d'une semaine, tu as fait 5 tâches; si tu leur demande si les 10 autres sont toujours utiles, tu risques d'avoir des surprises. Et beaucoup vont passer à l'as.
    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.

  13. #73
    Inactif  
    Homme Profil pro
    Analyste-Programmeur / Intégrateur ERP
    Inscrit en
    Mai 2013
    Messages
    2 511
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Analyste-Programmeur / Intégrateur ERP
    Secteur : Bâtiment

    Informations forums :
    Inscription : Mai 2013
    Messages : 2 511
    Points : 10 335
    Points
    10 335
    Par défaut
    Maintenant cela va mieux, ce n'est plus comme il y a encore un an ou deux, les responsables redigent leurs demandes, les découpent en sous-parties qu'ils priorisent d'eux-mêmes pour certains, voir même réalise eux-mêmes un "maquetage" d'écran quand ils sont motivés

    Mais la route fût longue !

    Et puis il faut dire que l'on est que 2 au SI dans ma boite, donc à force, j'ai quand même réussi à leur montrer que vu le nombre de demande de dev, si ils ne définissaient pas mieux leurs besoins et priorités, chaque reprise de dev que l'on était obligé de faire, ne faisait que répousser leurs autres demandes (bah oui j'ai que 2 mains moi ) et que donc au final, ils se pénalisaient sur le developpement en cours, dont la mise en prod était retardée du fait de devoir le reprendre plusieurs fois, et sur les développements futurs qui ne commenceraient forcement que plus tard.

  14. #74
    Invité
    Invité(e)
    Par défaut
    Moi je trouve que d'un côté il y a des gens qui sont très fort en math mais qui code de façon très sale. (Même si leur projet fonctionne)

    Et d'une autre côté il y a les gens comme moi c'est à dire ceux qui sont moins fort en math mais qui font du code source plus propre.

    J'ai vécu cela quand je travaillais sur un projet avec quelqu'un qui était super bon en math mais qui avait un code source en c++ qui ressemblait à du C. (Sont projet tourné mais j'avais du mal de m'y retrouvé dans sont code source. :/)

  15. #75
    Invité
    Invité(e)
    Par défaut
    Je ne suis pas totalement d'accord avec ce monsieur. Bien sur qu'il ne faut pas foncer tête baissée dans le code, moi même je réfléchis toujours à ce que je veux obtenir avant d'écrire du code, je fais mes petits schémas, mon mini cdc sur bloc note...et après je code en testant pour voir si j'obtiens bien ce que je veux et si le fonctionnel que j'attendais est bien respecté.
    Mais je ne couche pas ça sur papier en utilisant des maths pour le formaliser. A vouloir trop spécifier les choses on devient tellement étriqué qu'au moindre changement faut tout refaire.
    On peut coder proprement sans se farcir des kilomètres d'analyse, d'autant plus que c'est incompatible avec la productivité requise en entreprise. Parce que pendant qu'on analyse, on ne vend pas.

  16. #76
    Inactif  
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Mai 2013
    Messages
    114
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Haute Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Mai 2013
    Messages : 114
    Points : 93
    Points
    93
    Par défaut
    C'est une erreur selon moi de considérer, comme dirait Cabrel, qu'on "codait mieux avant".
    Ceci dit, moi qui suit pas mal autodidacte et me suis réorienté dans le développement professionnel sur le tard, je constate que les jeunes avec lesquels je bossent et qui sortent pour la plupart de grandes écoles spécialisées codent un peu comme moi je codais en 1989 en Basic sur Amstrad CPC : du procédural vite fait mal fait.

    J'ai 37 ans et je bosse pour une PME depuis l'année dernière qui refait son site (sorte de réseau social) parce que celui-ci a été développé à l'origine en externe par des gorets :
    - des fichiers php de plus de 4000 lignes immaintenables pour afficher un misérable résultat de requête sql
    - tout en procédural
    - zéro fonctions, quand besoin de faire 10 fois la même chose : 10 copier-coller à la suite
    - les array, connaissent pas, au retour d'une requete sql on pioche chaque colonne une par une, qu'on met dans une variables spécialement créée
    - PDO, connaissent pas, passer de PostgreSQL à MySQL a obligé à refaire tous les accès en bdd
    - un site avec sans arrêts des erreurs, "corrigés" avec des patches grossiers qui amenaient d'autres erreurs
    - une expérience utilisateur médiocre (lenteurs, pannes), et donc des rentrées d'argent nulles

    J'ai cru que le mec qui avait développé ça à l'origine était un ancien développeur qui en était resté à PHP 3. Quelle ne fut pas ma surprise quand j'ai découvert qu'il n'avait même pas 25 ans.

    Pour la refonte du site, j'ai commencé à redévelopper ça en PHP objet, un peu sur le modèle des entités dans Symfony, et avec PDO. Ca demandait un peu de préparation au début pour créer des objets, mais ensuite ça permettait de développer beaucoup plus vite. Et un stagiaire me disait qu'il appréciait ça parce que ça donnait beaucoup plus de clarté au code, qu'il n'y avait même pas besoin de commentaires. Ne parlons même pas de la stabilité, avec l'encapsulation les contrôles sont fait au niveau de chaque objet et ne sont plus perdus dans le code et tôt ou tard oubliés.
    Sauf que depuis peu, on a un chef de projet de 25 piges qui ne veut pas entendre parler de programmation objet et développe toute une partie du site sans réutiliser ce qui existe, ne veut bosser qu'avec du MySQL parce qu'il ne connait que ça (mais n'a jamais entendu parler de fonctions stockées, et ne sait pas faire un import/export en ligne de commande), pond des fonctions sans jamais un return pour exploiter leur résultat depuis une autre fonction ou même juste un booleen pour savoir si elles se sont bien déroulées...

    Mais comme il a une formation de chef de projet, le site s'adapte à ses directives... et commence à (re)devenir complètement bancal.
    On pourrait se dire que c'est pour gagner du temps, sauf qu'on en est déjà à plus de 2 semaines de retard de livraison, à force d'écrire du code non-réutilisable, des erreurs "patchées" avec des if, et une multitudes de variables dont on ne sait jamais ce qu'elles contiennent...

    Quand j'en parle autour de moi, on me dit que je suis naïf, que personne n'en a rien à faire de la qualité du code de nos jours et que ce sont les délai qui comptent... Sauf que dans le cas dont je viens de parler c'est justement le code de porc qui empêche de tenir des délais.
    On pourrait se dire que c'est fait exprès pour s'assurer plus de boulot et donc d'argent, sauf que la boite qui a fait le site en externe à la base n'est pas prête d'avoir de nouveaux clients vu la réputation qu'elle a depuis !
    On pourrait aussi se dire que leur code illisible leur permet d'être seul apte à assurer sa maintenance, mais ils ne sont même pas capables de trouver leurs propres bugs.

    Bref, je ne sais pas ce qu'ont les jeunes, ils sont de mieux en mieux instruits dans les écoles, ont d'excellents outils de dev et des IDE qui auto-complètent 75% du code à écrire, et pourtant ils font du code moisi qui met leurs collègues dans la merde et plombent les boites.

    Tout ça me donne envie de fuir le développement web en PHP, langage bien trop permissif. D'ailleurs mon chef de projet ne veut toujours pas croire que certains sites tournent avec Java...
    Ce qu'il lui manque, finalement, je crois bien que c'est un peu de curiosité.

  17. #77
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par Us and them Voir le message
    C'est une erreur selon moi de considérer, comme dirait Cabrel, qu'on "codait mieux avant".
    Ceci dit, moi qui suit pas mal autodidacte et me suis réorienté dans le développement professionnel sur le tard, je constate que les jeunes avec lesquels je bossent et qui sortent pour la plupart de grandes écoles spécialisées codent un peu comme moi je codais en 1989 en Basic sur Amstrad CPC : du procédural vite fait mal fait.
    Le procédural en soi n'est pas forcément mauvais. Mais pour qu'il soit maintenable, il a besoin d'avoir une structure adaptée au problème. Quand on rencontre(et c'est bien trop souvent le cas) du procédural fait ad hoc au fur et à mesure que tombent les specs sans jamais de reflexion sur l'architecture, oui, c'est une catastrophe.

    Citation Envoyé par Us and them Voir le message
    (.../...)J'ai cru que le mec qui avait développé ça à l'origine était un ancien développeur qui en était resté à PHP 3. Quelle ne fut pas ma surprise quand j'ai découvert qu'il n'avait même pas 25 ans.
    Ah ben oui, hein, faut pas croire que le pool génétique de l'humanité s'améliore(ou se dégrade, d'ailleurs) entre deux générations!

    Citation Envoyé par Us and them Voir le message
    Pour la refonte du site, j'ai commencé à redévelopper ça en PHP objet, un peu sur le modèle des entités dans Symfony, et avec PDO. Ca demandait un peu de préparation au début pour créer des objets, mais ensuite ça permettait de développer beaucoup plus vite. Et un stagiaire me disait qu'il appréciait ça parce que ça donnait beaucoup plus de clarté au code, qu'il n'y avait même pas besoin de commentaires. Ne parlons même pas de la stabilité, avec l'encapsulation les contrôles sont fait au niveau de chaque objet et ne sont plus perdus dans le code et tôt ou tard oubliés.
    Structurer son travail, c'est un conseil qu'on trouve un peu partout, en dessin, en architecture, en littérature, en sport..... Mais si tout le monde le donne, c'est que bien trop souvent on l'oublie.

    Citation Envoyé par Us and them Voir le message
    Sauf que depuis peu, on a un chef de projet de 25 piges qui ne veut pas entendre parler de programmation objet et développe toute une partie du site sans réutiliser ce qui existe, ne veut bosser qu'avec du MySQL parce qu'il ne connait que ça (mais n'a jamais entendu parler de fonctions stockées, et ne sait pas faire un import/export en ligne de commande), pond des fonctions sans jamais un return pour exploiter leur résultat depuis une autre fonction ou même juste un booleen pour savoir si elles se sont bien déroulées...
    il est chef ou développeur???

    Citation Envoyé par Us and them Voir le message
    Mais comme il a une formation de chef de projet, le site s'adapte à ses directives... et commence à (re)devenir complètement bancal.
    On pourrait se dire que c'est pour gagner du temps, sauf qu'on en est déjà à plus de 2 semaines de retard de livraison, à force d'écrire du code non-réutilisable, des erreurs "patchées" avec des if, et une multitudes de variables dont on ne sait jamais ce qu'elles contiennent...
    "formation de chef de projet". Donc ça n'est pas à lui de coder ou de choisir les patterns. C'est à lui de choisir les gens, les outils(genre le langage) et d'assigner les tâches, ainsi que de gérer le planning et les relations avec l'extérieur. C'est ce qu'on m'a appris en formation chef de projet(que je n'ai jamais appliqué, mais c'est pas grave). Il fait donc ce qui ne le concerne pas, et c'est donc un chef catastrophique.

    Citation Envoyé par Us and them Voir le message
    Quand j'en parle autour de moi, on me dit que je suis naïf, que personne n'en a rien à faire de la qualité du code de nos jours et que ce sont les délai qui comptent... Sauf que dans le cas dont je viens de parler c'est justement le code de porc qui empêche de tenir des délais.
    On pourrait se dire que c'est fait exprès pour s'assurer plus de boulot et donc d'argent, sauf que la boite qui a fait le site en externe à la base n'est pas prête d'avoir de nouveaux clients vu la réputation qu'elle a depuis !
    On pourrait aussi se dire que leur code illisible leur permet d'être seul apte à assurer sa maintenance, mais ils ne sont même pas capables de trouver leurs propres bugs.
    Pour juger un travail en point de croix, on regarde derrière - la partie qui sera invisible - si c'est propre. C'est un art ancien, et si les pratiquant(e)s en sont arrivé à cette pratique, c'est guidées par des siècles d'expérience. L'informatique est encore trop jeune pour avoir ce genre de maturité.

    Citation Envoyé par Us and them Voir le message
    Bref, je ne sais pas ce qu'ont les jeunes, ils sont de mieux en mieux instruits dans les écoles, ont d'excellents outils de dev et des IDE qui auto-complètent 75% du code à écrire, et pourtant ils font du code moisi qui met leurs collègues dans la merde et plombent les boites.
    Le problème n'est pas la formation. C'est la selection. 60% des gens n'ont aucun talent pour l'informatique, mais on les laisse librement se faire diplomer. Ca a toujours été vrai. Mais dans le temps, comme personne n'était formé, on essayait n'importe qui, et on gardait ceux qui y arrivaient. Il y avait beaucoup de femmes, d'ailleurs, pas loin de 40%. Aujourd'hui, on a structuré tout ça, on BAC+5ise à tout va, et n'importe quel gnou incapable de programmer mais qui a fait ses 5 ans peut prétendre appliquer des méthodes de programmation auquelles il ne comprend rien. Et surtout, on va le garder quand même parcequ'il est BAC+5, alors bon.....

    Citation Envoyé par Us and them Voir le message
    Tout ça me donne envie de fuir le développement web en PHP, langage bien trop permissif. D'ailleurs mon chef de projet ne veut toujours pas croire que certains sites tournent avec Java...
    Ce qu'il lui manque, finalement, je crois bien que c'est un peu de curiosité.
    Un peu????? Quand on en est à ce niveau de déni, c'est juste de l'enfermement. Du mantra. De la croyance dans le petit manuel. Ce genre de jocrisse est persuadé qu'il suffit de suivre le petit manuel pour tout réussir dans la vie - et que si ça ne marche pas, c'est qu'on a comploté contre lui. C'est ce qu'on obtient quand on envoie de jeunes gens 5 ans en camp de rééducationécole d'ingénieur ou on va leur enseigner 50,000 méthodes sans jamais leur dire que çe ne sont que des outils, à utiliser avec sagesse.

    Je cite Pmithrandir sur un autre fil :
    Citation Envoyé par pmithrandir
    Pour l'éducation supérieure, on s'amusait a comparer les système roumain et francais d'études.
    En France, on reste dans une classe et on apprend uniquement en cours, avec des profs en général à la page et pas mauvais.
    En Roumanie, le prof n'assure parfois même pas les cours(les assistants s'en charge très bien), ils sont à la bourre(je recrute des gens qui viennent d'être formé sur cobol) et en général il ressort que la qualité des cours est nulle. Les étudiants ont souvent un temps plein et assiste parfois a des cours, mais rare sont ceux qui assistent a tous les cours, voir même à la moitié.

    Malgré tout, ils produisent autant que les français quand on les met devant un ordi.
    En bref, le Roumain, il arrive sans idées préconçues, prêt à apprendre. Le Francais est pétri de certitudes sur la seule bonne manière de faire, et fermé au monde réel.

    Ma chance à moi, c'est que j'ai un diplôme en plasturgie. Je me demande si, en informatique de gestion, ça n'est pas plus adapté qu'un diplôme en info(qui me parait par contre inévitable pour faire du système). Comme je SAIS que je ne suis pas informaticien, je suis plus humble, et toujours prêt à me remettre en cause. Ce qui me permet de faire ce dont on a besoin, et pas un hypothétique design pattern surdimensionné de la mort qui tue inmaintenable. Attention : je n'ai rien contre les design pattern en soi : je fait juste caca sur leur élévation au rang d'indispensable. Rien n'est indispensable - juste savoir adapter son choix d'outil à la situation présente, et savoir prendre du recul pour avoir une vision globale du sujet.

    Dans le lien de Jeff Atwood que je donne, les auteurs de l'étude qu'ils citent parlent de récursion comme étant une compréhension fondamentale pour être programmeur. Je suis d'accord. Pourtant, j'ai du utiliser 2 récursions en 14 ans de carrière, et j'aurais certainement pu faire sans. Mais la récursion oblige à penser à 2 niveaux différents en même temps. Ce qui est l'essence de la programmation : on s'acharne sur un algorithme local, sans jamais oublier à quoi il doit servir au niveau global.

    Tes jeunots, je suis surs qu'ils sont incapables de faire une récursion. C'est pour ça qu'ils sont incapables de faire un système d'information cohérent. Ils ne savent pas zoomer entre le détail et la vue globale, entre l'implémentation et l'architecture(qui n'a pas besoin d'être astronautique, mais il en faut quand même une). Ils ne savent pas se donner une cohérence, un style. et c'est catastrophique.
    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.

  18. #78
    Inactif  
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Mai 2013
    Messages
    114
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Haute Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Mai 2013
    Messages : 114
    Points : 93
    Points
    93
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    Le procédural en soi n'est pas forcément mauvais. Mais pour qu'il soit maintenable, il a besoin d'avoir une structure adaptée au problème. Quand on rencontre(et c'est bien trop souvent le cas) du procédural fait ad hoc au fur et à mesure que tombent les specs sans jamais de reflexion sur l'architecture, oui, c'est une catastrophe.
    On est dans le cas de la catastrophe, là.
    Et encore, je n'ai même pas évoqué les noms de fichiers sans rapport avec le contenu, et les @ de partout pour masquer les erreurs.

    Citation Envoyé par el_slapper Voir le message
    il est chef ou développeur???
    "formation de chef de projet". Donc ça n'est pas à lui de coder ou de choisir les patterns. C'est à lui de choisir les gens, les outils(genre le langage) et d'assigner les tâches, ainsi que de gérer le planning et les relations avec l'extérieur. C'est ce qu'on m'a appris en formation chef de projet(que je n'ai jamais appliqué, mais c'est pas grave). Il fait donc ce qui ne le concerne pas, et c'est donc un chef catastrophique.
    Il est développeur mais de formation "supérieure" à un bête ouvrier du code comme moi, ne m'en demande pas plus, j'en sais juste ce qu'il m'en a dit, que sa formation lui avait appris à gérer un projet et une équipe.
    Au niveau équipe, il veut que tout passe par lui, résultat les bugs signalés ou ajouts de fonctionnalités demandées par les commerciaux/marketeux et auparavant corrigés/ajoutés en 5mn restent en standby plusieurs jours/semaines. Pour le travail d'équipe, le stagiaire et moi lui avons suggéré qu'on bosse avec un outil collaboratif comme SVN ou Git, mais comme il ne connait pas (et ne veut pas connaitre, c'est pire) on se retrouve à bosser avec Dropbox et donc des écrasements de fichiers/conflits en permanence. Et comme il est également contre toute sauvegarde (ce qui ne m'empêche pas d'en faire pour moi), il a vu plusieurs fois le fruit d'une journée de son travail disparaitre et dû le refaire de zéro. Encore un bon point pour le respect des délais...
    Et évidemment, quand un commercial vient me voir parce qu'un petit bug de rien du tout empêche d'ajouter des clients depuis 1 mois, qu'on attend le feu vert pour s'en occuper depuis, et que je passe outre et corrige ça en 2mn, je me fais avoiner pour "agir comme si j'étais tout seul".

    Le mec fout du texte en français en dur dans ses interfaces utilisateur (copié-collé d'autres de ses projets), et après s'étonne que les traductions mettent 3 plombes à venir, forcément faut passer derrière remplacer tout ça par des variables, et aller emm... sans arrêt la seule personne capable de faire les traductions dans 5 langues mais qui n'a pas que ça à foutre.
    Il faudrait communiquer le moindre de nos agissement sur un fichier dont il ignore l'existance quand lui plante la page d'accueil du site pendant 1h pour une modif sans avoir prévenu personne. Génial.

    Citation Envoyé par el_slapper Voir le message
    Le problème n'est pas la formation. C'est la selection. 60% des gens n'ont aucun talent pour l'informatique, mais on les laisse librement se faire diplomer. Ca a toujours été vrai. Mais dans le temps, comme personne n'était formé, on essayait n'importe qui, et on gardait ceux qui y arrivaient. Il y avait beaucoup de femmes, d'ailleurs, pas loin de 40%. Aujourd'hui, on a structuré tout ça, on BAC+5ise à tout va, et n'importe quel gnou incapable de programmer mais qui a fait ses 5 ans peut prétendre appliquer des méthodes de programmation auquelles il ne comprend rien. Et surtout, on va le garder quand même parcequ'il est BAC+5, alors bon.....
    Je confirme. J'ai roulé ma bosse dans pas mal de secteurs (btp,restauration,usine,logistique) avant de pouvoir me réorienter suite à une formation professionnalisante et surtout énormément de travail personnel à la maison, et quel que soit le milieu j'ai toujours pris plaisir à apprendre de nouvelles choses. C'est pas du tout le cas des jeunes diplomés que je vois (je ne généralise pas), pour qui tout ce qu'ils ne connaissent pas est "nul" (je cite: Java, PostgreSQL, Eclipse, Netbeans, Linux, la POO, la ligne de commande, Git, SVN).
    Le problème aussi maintenant, c'est que le métier marche quasi uniquement sur les relations, on préfère bien souvent embaucher le "bon copain" ou le "fils de" qui "s'y connait en informatique" plutôt que donner sa chance à un inconnu hormis pour un stage, et encore.. Aussi, on veut des développeurs avec la fibre (voire la formation) commerciale, parce qu'on préfère des grandes gueules qui vont promettre un produit livré dans 2 semaines et le livreront en 5 plutôt que quelqu'un qui va dire directement qu'il faudra 5 semaines.

    Je vais éviter de parler de tout les jeunes qui se lancent dans le dev juste parce qu'ils adorent les jeux-vidéos, parce que je risque de m'énerver...

  19. #79
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    8 352
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2006
    Messages : 8 352
    Points : 20 359
    Points
    20 359
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    Foutaises, foutaises et foutaises.
    avant de faire des jugements à l'emporte-pièce on lit bien ce qui est écrit.
    La majorité des intervenants n'ont rien compris à ce texte de ce consultant de Microsoft
    Il affirme qu'une majorité de programmeurs se lancent dans l'écriture du code sans poser sur papier les bases de tout projet informatique.

    Je m'échine à écrire qu'on peut faire du très bon code propre et bien construit pour un projet informatique mais que l'architecture du projet peut être bancale ce qui donne un projet foireux voué à l'échec.
    C'est ce qu'essaie d'expliquer cette personne de Microsoft
    Je viens de quitter un projet de migration de VB6 vers Vb.net , le projet .NET n'a aucune architecture ,tout est à jeter car pour maintenir tout ce bazar et corriger les bugs par la suite bonjour

    Citation Envoyé par Paul TOTH Voir le message
    non je ne suis pas tout à fait d'accord.
    1) des programmeurs avec deux mains gauches il y en a toujours eut.
    un programmeur avec une main droite et une main gauche et qui a fait Ecole Polytechnique ça ne suffit pas à faire un bon projet.
    Pour reprendre l'analogie avec l'architecte, si tu as de bons maçons ,électriciens, plombiers et confirmés mais un mauvais architecte ta maison ou le batîment que tu veux construire sera raté.

    Citation Envoyé par Cedric Chevalier Voir le message
    Cependant, alors que la logique voudrait aussi que la qualité du code s’améliore avec le temps, c’est l’inverse qui se produit. Qu'est-ce qui peut expliquer ce phénomène ?
    difficile d'améliorer la qualité du code ; les projets informatiques deviennent rapidement des usines à gaz parce que les "décideurs" veulent rajouter des tonnes de fonctionnalités c'est ce qui se passe.
    Donc pour un projet informatique ça fait des tas d'écrans et des tas de traitements derrière donc ça multiplie les lignes de code.
    Sans une bonne architecture minimale et sans spécifications minimales ce qu'explique Leslie Lamport le projet va à l'échec ou nécessitera une maintenance importante ce qui coûte cher à l'entreprise.

    Citation Envoyé par e-ric Voir le message
    la complexification croissante des EDI qui en apportant du confort à des développeurs confirmés ne sont plus à la portée du premier venu. Il n y a qu'à comparer les EDI actuels et celui de TurboPascal 4.0.
    tu as raison mais pas seulement les EDI !!
    Aussi les frameworks ,tous les outils disponibles pour construire un projet informatique
    La faute aux éditeurs d'outils de développement , de frameworks qui complexifient volontairement les choses.
    Tout cela c'est fait exprès par les éditeurs qui veulent verrouiller les choix technologiques effectués bref que ton projet dépende d'une ou plusieurs techs en particulier.
    Or résultat des courses ça fait des usines-à-gaz ingérables, trop de temps investi dans la maitrise de ces technos et frameworks et pendant ce temps-là on perd de vue l'essence même des aspects métiers.

    Citation Envoyé par el_slapper Voir le message
    "formation de chef de projet". Donc ça n'est pas à lui de coder ou de choisir les patterns. C'est à lui de choisir les gens, les outils(genre le langage) et d'assigner les tâches, ainsi que de gérer le planning et les relations avec l'extérieur. C'est ce qu'on m'a appris en formation chef de projet(que je n'ai jamais appliqué, mais c'est pas grave). Il fait donc ce qui ne le concerne pas, et c'est donc un chef catastrophique.
    là ce que tu écris c'est une personne qui ne sert strictement à rien sauf à faire du présentéisme...
    une personne qui gére des plannings et choisir les gens c'est une personne qui est bon pour le décor...

  20. #80
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par Us and them Voir le message
    Sauf que depuis peu, on a un chef de projet de 25 piges qui ne veut pas entendre parler de programmation objet et développe toute une partie du site sans réutiliser ce qui existe, ne veut bosser qu'avec du MySQL parce qu'il ne connait que ça (mais n'a jamais entendu parler de fonctions stockées, et ne sait pas faire un import/export en ligne de commande), pond des fonctions sans jamais un return pour exploiter leur résultat depuis une autre fonction ou même juste un booleen pour savoir si elles se sont bien déroulées...
    Cette personne n'est pas compétente, il sera viré un jour ou la boite coulera ( j'en ai eu un comme ça, le patron pas trop aveugle l'a viré au bout de quatre mois mais on lui a forcé la main).

    Citation Envoyé par Us and them
    Bref, je ne sais pas ce qu'ont les jeunes, ils sont de mieux en mieux instruits dans les écoles, ont d'excellents outils de dev et des IDE qui auto-complètent 75% du code à écrire, et pourtant ils font du code moisi qui met leurs collègues dans la merde et plombent les boites.
    Ridicule, par exemple en terminal S la géométrie a ( presque ) disparu depuis la dernière réforme, le niveau baisse de plus en plus en premier cycle universitaire et se n'est pas un Ide qui va changer quelque chose.
    Eh oui il faut du temps pour être efficace : plusieurs années encore faut-il quelles soient correctement remplies.

    Citation Envoyé par Us and them
    Tout ça me donne envie de fuir le développement web en PHP, langage bien trop permissif. D'ailleurs mon chef de projet ne veut toujours pas croire que certains sites tournent avec Java...
    Ce qu'il lui manque, finalement, je crois bien que c'est un peu de curiosité.
    Le langage n'y est pas pour grand chose de toute façon le web en france passe par le PHP

    Citation Envoyé par el_slapper Voir le message
    Le procédural en soi n'est pas forcément mauvais. Mais pour qu'il soit maintenable, il a besoin d'avoir une structure adaptée au problème. Quand on rencontre(et c'est bien trop souvent le cas) du procédural fait ad hoc au fur et à mesure que tombent les specs sans jamais de reflexion sur l'architecture, oui, c'est une catastrophe.
    Zut j'aurais dit la même chose pour l'objet...

    Citation Envoyé par el_slapper
    il est chef ou développeur???
    Ni l'un ni l'autre.

    Citation Envoyé par el_slapper
    Pour juger un travail en point de croix, on regarde derrière - la partie qui sera invisible - si c'est propre. C'est un art ancien, et si les pratiquant(e)s en sont arrivé à cette pratique, c'est guidées par des siècles d'expérience. L'informatique est encore trop jeune pour avoir ce genre de maturité.
    Ouais je crois que le "vite fait mal fait" est la seule règle dans le web qui soit bien identifiable de nos jours.

    Citation Envoyé par el_slapper
    Mais dans le temps, comme personne n'était formé, on essayait n'importe qui, et on gardait ceux qui y arrivaient. Il y avait beaucoup de femmes, d'ailleurs, pas loin de 40%. Aujourd'hui, on a structuré tout ça, on BAC+5ise à tout va, et n'importe quel gnou incapable de programmer mais qui a fait ses 5 ans peut prétendre appliquer des méthodes de programmation auquelles il ne comprend rien. Et surtout, on va le garder quand même parcequ'il est BAC+5, alors bon.....
    .. et ça nous coûte un bras en impôts!

    Citation Envoyé par el_slapper
    l'étude qu'ils citent parlent de récursion comme étant une compréhension fondamentale pour être programmeur. Je suis d'accord. Pourtant, j'ai du utiliser 2 récursions en 14 ans de carrière, et j'aurais certainement pu faire sans. Mais la récursion oblige à penser à 2 niveaux différents en même temps. Ce qui est l'essence de la programmation : on s'acharne sur un algorithme local, sans jamais oublier à quoi il doit servir au niveau global
    Pouvez-vous développer un peu?

    Citation Envoyé par Us and them Voir le message
    Il est développeur mais de formation "supérieure" à un bête ouvrier du code comme moi, ne m'en demande pas plus, j'en sais juste ce qu'il m'en a dit, que sa formation lui avait appris à gérer un projet et une équipe.
    Au niveau équipe, il veut que tout passe par lui, résultat les bugs signalés ou ajouts de fonctionnalités demandées par les commerciaux/marketeux et auparavant corrigés/ajoutés en 5mn restent en standby plusieurs jours/semaines. Pour le travail d'équipe, le stagiaire et moi lui avons suggéré qu'on bosse avec un outil collaboratif comme SVN ou Git, mais comme il ne connait pas (et ne veut pas connaitre, c'est pire) on se retrouve à bosser avec Dropbox et donc des écrasements de fichiers/conflits en permanence. Et comme il est également contre toute sauvegarde (ce qui ne m'empêche pas d'en faire pour moi), il a vu plusieurs fois le fruit d'une journée de son travail disparaitre et dû le refaire de zéro. Encore un bon point pour le respect des délais...
    Et évidemment, quand un commercial vient me voir parce qu'un petit bug de rien du tout empêche d'ajouter des clients depuis 1 mois, qu'on attend le feu vert pour s'en occuper depuis, et que je passe outre et corrige ça en 2mn, je me fais avoiner pour "agir comme si j'étais tout seul".

    Le mec fout du texte en français en dur dans ses interfaces utilisateur (copié-collé d'autres de ses projets), et après s'étonne que les traductions mettent 3 plombes à venir, forcément faut passer derrière remplacer tout ça par des variables, et aller emm... sans arrêt la seule personne capable de faire les traductions dans 5 langues mais qui n'a pas que ça à foutre.
    Il faudrait communiquer le moindre de nos agissement sur un fichier dont il ignore l'existance quand lui plante la page d'accueil du site pendant 1h pour une modif sans avoir prévenu personne. Génial.
    Rien ne vous empêche d'utiliser Git avec votre stagiaire...
    Il ne faut jamais doubler sa hiérarchie !
    Il est nul, ne cherchez pas à sauver sa tête

    Citation Envoyé par Us and them
    Je confirme. J'ai roulé ma bosse dans pas mal de secteurs (btp,restauration,usine,logistique) avant de pouvoir me réorienter suite à une formation professionnalisante et surtout énormément de travail personnel à la maison, et quel que soit le milieu j'ai toujours pris plaisir à apprendre de nouvelles choses. C'est pas du tout le cas des jeunes diplomés que je vois (je ne généralise pas), pour qui tout ce qu'ils ne connaissent pas est "nul" (je cite: Java, PostgreSQL, Eclipse, Netbeans, Linux, la POO, la ligne de commande, Git, SVN).
    Nouvelle phase de la formation : apprendre à changer de boite !!!
    Il existe de bons développeurs avec lesquels vous apprendrez beaucoup plus, vous devez chercher ces gens.
    Tans pis pour cette boite elle a fait un mauvais choix, qu'elle coule mais ne coulez pas avec, en informatique fasse à ce genre de situation il faut se blinder.

    Citation Envoyé par Us and them
    Le problème aussi maintenant, c'est que le métier marche quasi uniquement sur les relations, on préfère bien souvent embaucher le "bon copain" ou le "fils de" qui "s'y connait en informatique" plutôt que donner sa chance à un inconnu hormis pour un stage, et encore..
    Hélas, je l'ai remarqué aussi...

    Citation Envoyé par Us and them
    Je vais éviter de parler de tout les jeunes qui se lancent dans le dev juste parce qu'ils adorent les jeux-vidéos, parce que je risque de m'énerver...
    Non, il n'y a pas que le web il y a Qt, iOS, C++ ... donc on peut faire autre chose que du mauvais PHP/jquery sur un site foutu et même faire du bon développement web, j'ai vu des boites qui cherchaient désespérément de bon dev PHP...
    Dernière modification par Invité ; 14/05/2014 à 16h21.

Discussions similaires

  1. La qualité du code a-t-elle foutu le camp chez les programmeurs ?
    Par Cedric Chevalier dans le forum Actualités
    Réponses: 72
    Dernier message: 29/04/2014, 12h51
  2. Code ok sur mon PC mais pas chez les autres ?
    Par catherineFR27 dans le forum Général VBA
    Réponses: 6
    Dernier message: 04/06/2007, 21h29
  3. [Visual Web] visual web et qualité du code
    Par robert_trudel dans le forum NetBeans
    Réponses: 4
    Dernier message: 11/12/2006, 13h11
  4. qualité du code
    Par clementphp dans le forum Langage
    Réponses: 6
    Dernier message: 10/07/2006, 15h22

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo