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
lol, c'est particulièrement vrai en phase de maintenance, quand le programme est arrivé à un certain stade d'évolution et que le code devient "spaguetti".Les mauvais quant à eux passent ces 80 à 90% de temps à debugger leur code en faisant des essais au hasard puis en regardant si cela fonctionne.
C'est de toute manière pas possible à part dans le monde magique des développeurs sans boss , sans deadline et sans contrainte.Envoyé par Tinmar88
Quand un client te commande un soft , si à la première réunion tu viens avec des diagrammes UML, des diagrammes de class à la place d'une jolie interface pour qu'il puisse faire clic clic tu te fais déchirer (enfin c'est comme ça que ça marche chez moi) alors que pourtant tu auras fait nettement plus de taf en faisant de la conception que de l'IHM.
Chez nous c'est en partie pour ça que la conception , la documentation et tout ses truc invisibles mais pourtant indispensable sont trop souvent remis à plus tard voire à jamais
Ce qui est dommage, c'est qu'on a pas vraiement le définition de mauvais dévéloppeur.
Parce que maintenant, quand je regarde en arrière, je trouve que j'ai été un mauvais développeur et c'est normal, je débutais.
Effectivement, par contre, un développeur qui fonce dans le tas est un développeur pressé et qui manque de recul (mauvais développeur non, car qui chez lui n'a pas foncé pour faire un code vite fait pour se dépanner, sans réfléchir).
Plus un code et réfléchi, plus il a des chances d'être bien. Mais, bon, il y a un moment ou il faut y aller, car 15 jours de réflexion pour 3 lignes de code ça coûte cher.
Sinon, je m'y retrouve dans ce qu'il dit et de ce que je vois autour de moi.
Si peu ? La chance
J'ai remarqué qu'un bon programmeur fait des IHM très laides aussi
Me voila rassuré, je suis pas si mauvais alorsJ'ai remarqué qu'un bon programmeur fait des IHM très laides aussi
Totalement !
Je ne suis pas aussi fou que je le pensais.
La phrase suivante n'a pas été reprise du blog original :
Dommage“A great lathe operator commands several times the wage of an average lathe operator, but a great writer of software code is worth 10,000 times the price of an average software writer.” –Bill Gates
Je doute un peu du fait que ce Bill paie certains programmeurs 10,000 fois plus que d'autres.
Je ne doute pourtant pas que certains soient payés 10,000 fois plus que d'autres, dans sa boite.
Moralité ?
Fier d'être un mauvais programmeur
Un bon programmeur ça ne doit pas exister. Car cherchant continuellement à progresser il se retrouve en permanence en situation d'incompétence.
Un programmeur qui pense être bon et en fait mauvais.
Je ne sais pas si je suis un bon programmeur (en tout cas j'aime ce que je fais), mais je pense être un bon père de famille donc quand je suis à la maison je ne pense pas au boulot et inversement.
Il me semble exact que l'on passe 2/3 de son temps au design ou à la convivialité, 'selon le nom que l'on préfère).
Nous ne sommes finalement qu'au service de l'utilisateur final et aussi ..... aux autres programmeurs qui doivent maintenir nos applications.
Bonjour,
Moi je développe en COBOL et en UFO, et pour ma part. Généralement quand j'ai un truc a développer j'ai déjà une spécification fonctionnelle et technique, qui oriente le programmeur. Donc le programmeur n'a pas a ce poser des milliards de question existentielle comment il va faire ses Algo, ils sont déjà pré-maché. Tout ce qu'il a faire c'est écrire du code qui soit lisible maintenable par n'importe quel développeur (avec un minimum de commentaires) et qui s'intègre dans l'existant. Pour ce qui est de la ré-utilisabilté sur le projet c'est quasiment nul, faute au langage , et la création de sous programmes n'est utilisé avec l'accord du client que dans des cas particulier. Après je code bien des parties qui réutilisable dans d'autres programmes, pas de librairies, merci le copier coller.
Les programmes sont donc des monolithes de code. Ensuite il faut se créer les cas de tests dans les bases, "bidouiller" les tables BD2 pour tester tous les cas triturer son code, car aucun outil n'a été développer pour.
Pour ce qui est de l'ergonomie, sur un mainframe, il y a pas des masse a faire.
Généralement, je n'ai pas le temps matériel de peaufiner mon code, de chercher excellence, le temps de lire la spec de comprendre, de regarder l'existant de mettre son code sans tout casser, de créer ses cas de test de tester, pour que cela fasse ce qui écrit.
Pour autant, je ne pense pas être mauvais développeur, ni la prétention d'être un bon, mais j'essaye de faire ce qui est demandé au mieux. Et je veux bien réfléchir a du code dans ma salle de bain, mais a la fin je n'aurai rien en retour de la part de mon employeur, j'ai passé des nuits a pas dormir a me réveiller en pensant a du code au bug j'avais, a comment faire simple lisible et fonctionnel, et correspondant au besoin.
Je demande a travailler sur de la nouvelle techno, a faire de l'embarqué, mais rien, alors je ne vois pas pourquoi je continuerai de me prendre la tête a faire une technologie que je n'aime pas, et dont mon travail n'est pas reconnu.
Je suis toujours dubitatif devant la notion de bon et mauvais programmeur (ou quoique ce soit d'autre). Car c'est sauf cas flagrant toujours difficile à juger. Quand je parle de cas flagrant j'ai en tête l'exemple d'un ex collègue qui a pondu 2 lignes de codes en 6 mois de travail et en plus ça ne fonctionnait pas.
J'ai eu aussi le cas lors de mon stage de fin d'étude d'un étudiant de ma promo qui faisait son stage dans la même entreprise que moi qui passait 100% de son temps à me poser des questions et qui me demandais quasiment de faire son boulotÇa n'a pas duré longtemps mon chef de stage est intervenu assez brutalement ensuite j'a été tranquille.
Ceci dit il y a quelques bonnes vérités ici telle que:
- Bien réfléchir à ce qu'on veut faire et à la manière de le faire avant de se lancer dans le code
- Ne pas réinventer la poudre surtout pour des fonctions qui ont été étudiées en long et en large comme les tris ou les algo de recherche dans des listes.
En gros être méthodique
Mais pour moi le "bon" programmeur est celui qui connaît bien son langage de programmation et surtout son environnement et comment fonctionne son OS.
Réinventer la roue
Réinventer la roue, refaire un existant à sa propre sauce, c'est tellement jouissif!
Problème : ça n'apporte rien à l'utilisateur. Le développeur qui fait ça est donc un mauvais développeur. En tout cas c'est ce qui sera retenu.
Bah, il suffit de lire le manifeste agile, qui permet de répondre à ces assertions. Il a au moins le mérite de parler du projet, et pas seulement du développeur, qui n'en est qu'un maillon. Et de là à classer les développeurs entre très bons (forcément moi)...
http://agilemanifesto.org/
Soyons souples pensons agile
Oui j'ai vu une présentation sur cette manière de travailler qui est assez originale et plutôt intéressante. Par contre ça va actuellement à l'encontre de toutes les doctrines managériales actuellesBah, il suffit de lire le manifeste agile, qui permet de répondre à ces assertions. Il a au moins le mérite de parler du projet, et pas seulement du développeur, qui n'en est qu'un maillon. Et de là à classer les développeurs entre très bons (forcément moi. Maintenant il faut voir ce que ça va donner dans le futur mais ça a le mérite de responsabiliser chacun. J'aime bien aussi le petit coté pervers de cette méthode où chacun se met sa propre pression
Il faut croire que non étant donné le nombre d'adeptes.
ça me rappelle qu'il y a deux gros boulets dans la boîte ou je suis.
Pour l'anecdote. Je regardais le travail d'une autre équipe de Dev. sur un source commun et là je remarque que l'un des développeur à livré une fonction identique au LeftStr de Delphi. En fait, la seule chose qui changeait était les nom des variables sinon c'était rigoureusement la même. J'envoie donc un mail à cette personne en mettant les forme afin de ne pas le contrarier pour lui dire que la fonction qu'il avait codé était déjà native à Delphi. Il me répond que ce n'est pas lui qui avait codé cette fonction, mais qu'il s'était contenté de déplacer cette fonction du source d'un autre collègue parce que l'unité où elle se trouvait avait de l'IHM et que son plugin ne compilait plus.
ça fait donc deux boulets, un qui s'amuse à recoder les fonctions de bases incluses dans delphi et un autre qui l'utilise dans plusieurs de ces sources en ajoutant pour l'occasion des tonnes de uses inutiles !
Mes tutoriels
Avant de poster :
- F1
- FAQ
- Tutoriels
- Guide du développeur Delphi devant un problème
Cette anecdote est un cas d'école, non pas pour stigmatiser l'incompétence d'un tel ou un tel, mais parce qu'elle témoigne d'une organisation particulièrement défaillante, sans aucun processus de contrôle.
Ce type d'erreur n'aurait en effet pas pu se produire si les projets avaient mis en place des relectures croisées et des revues de design. Vous êtes loin du CMMI2 dans ta boîte.
Et faut pas venir me dire "on peut pas faire ça, on nous pousse au cul et on n'a pas le temps". Car l'effort de qualité qu'on ne fait pas pendant les dev, on le paye puissance 10 sur les dernières fonctionnalités, les intégrations, et surtout en alpha tests avec une déferlante de bugs, qui de surcroît deviennent au fur et à mesure de plus en plus compliqués à corriger. Vous avez sans doute tous pu constater que c'est là que les plus gros retards sont pris.
Soit dit en passant, l'erreur initiale la plus grave n'est pas la duplication de fonction native, mais sa dépendance par rapport à un module de présentation.
Les bons programmeurs...
... sont probablement ceux qui se refusent à l'affirmer haut et fort ?
Tout-à-fait vrai (le texte en début de fil).
Vrai aussi que ça paraît incohérent de conseiller d'être prêt à réécrire constamment son code, après avoir consenti des efforts pour qu'il s'adapte partout.
Après qu'on ait dit "it is not a bug, it is by design", on ne va pas se gêner pour dire qu'il peut être bon d'adapter un code, sans pour autant que ça oblige à tout réécrire. D'ailleurs en faisant ça on doit être attentif à rester compatible avec les appels existants. Si je ne m'abuse Developpez a écrit une chronique là-dessus l'année dernière.
En étant attentif à écrire du code réutilisable et à le répertorier de façon à le retrouver, on élimine une bonne partie des causes d'échec. Ensuite, on ne se débarrasse pas des causes inhérentes au client, entre celui qui vous impose une méthode d'évaluation ultra-lourde reposant sur des indices impossibles à obtenir et qui ainsi vous empêche de travailler, celui qui n'a pas l'aval de sa hiérarchie et qui se fait taper sur les doigts à la fin du projet, n'ayant pas anticipé des changements dans l'énoncé du problème ...
Alors prendre de la hauteur, perte de temps ?
Il y a peu j'aurais pu engager une mise en cause sur la question, mais en ce moment, le marché de l'emploi étant ce qu'il est, je suis avec quelqu'un qui envisage sans sourciller de charger dix fichiers qui vont mettre deux heures à se charger et tout planter au moindre incident réseau, pour des informations dont seul le dernier dixième évolue, plutôt que de mettre sur pied un mode de mémorisation, et ça juste pour économiser une demi-journée de développement au début. Alors forcément, on gagne sa vie comme en Inde.
Répondre avec citation
Partager