J'aime !!!
Je trouve grotesque de distribuer des trophées à un développeur qui fait de la merde !
Moi, je reprendrai l'idée en la modifiant un peu : détecter les immondices dans le code du développeur mais au lieu de le récompenser, il faudrait lui afficher un gros warning (et pourquoi pas envoyer un mail directement à son chef de projet s'il répète sa connerie plus de x fois)
Mes tutoriels
Avant de poster :
- F1
- FAQ
- Tutoriels
- Guide du développeur Delphi devant un problème
J'ai déjà vu des entreprises qui récompensaient certains développeurs qui font de la merde, et pas par des trophées virtuels...
Moi aussi je trouvais ça grotesque. Mais dans le monde de l'entreprise, le copinage vaut parfois mieux que la compétence.
(et ça ne sert à rien d'envoyer un mail à son chef de projet, il est dans le coup aussi... )
"On en a vu poser les armes avant de se tirer une balle dans le pied..."
-- pydévelop
Derniers articles:
(SQL Server) Introduction à la gestion des droits
(UML) Souplesse et modularité grâce aux Design Patterns
(UML) Le Pattern Etat
Autres articles...
Mais ce n'est pas parce que le programme compile qu'il va s'éxécuter correctement.
Pour prendre un exemple concret, tu place au requête SQL complètement abracabrantiesque dans un Query. La requête en question c'est du type chaîne de caractère. La compilation va passer comme une lettre à la poste parce que la propriété est renseignée avec une String mais lorsque la requête va être exécutée : Badaboom !
Mes tutoriels
Avant de poster :
- F1
- FAQ
- Tutoriels
- Guide du développeur Delphi devant un problème
Mais non !! Pas du tout !! Grâce à l'utilisation judicieuse d'un bloc "try...catch...finally", le programme pourra continuer à s'exécuter comme si de rien n'était.
Et par la suite, grâce à une recette opérée avec soin (au maximum 2h sur un projet de 120 jours, pas plus sinon on perd du temps), on pourra vérifier que le bouton "Enregistrer" de l'application fonctionne bien (le développeur aura pertinemment placé le message "Enregistrement effectué avec succès" dans la partie "finally").
Et pour peu que cette fonctionnalité soit dans une zone peu utilisée de l'application (par exemple, au niveau de la génération des rapports annuels), le développeur aura astucieusement le temps de se barrer avant que l'on ne découvre le problème (de toute façon, c'était un forfait et la garantie client est dépassée).
Et devinez qui se récupère l'appli derrière à débugguer ?
"tatatatatatatatataaa !! tata taaa !! tata taaa !! tatatata tataaa !! tata taaa !! tata taaa !!"
"On en a vu poser les armes avant de se tirer une balle dans le pied..."
-- pydévelop
Derniers articles:
(SQL Server) Introduction à la gestion des droits
(UML) Souplesse et modularité grâce aux Design Patterns
(UML) Le Pattern Etat
Autres articles...
Dans la catégorie "immondice" que la compilation ne detecte pas (mais qui cette fois ne gène en rien le déroulement du programme), il y a le type qui se dit très rigoureux et connaissant parfaitement le langage dans le lequel il programme et qui pourtant te fait un "if" suivi de pas moins de 22 "else if" derrière et tout ça pour quoi ? Pour dire que si le code est inférieur = 1, je fais ça, si le code=2, je fais ça,...
Pour la petite histoire, c'est ce même type qui est venu me faire chier l'autre jour parce que quand j'ai fait mon Merge avec SVN j'ai oublié de rajouter une tabulation devant mon dernier End !
J'ai vérifié ses if..else if à ralonge et effectivement, c'était super bien identé. Effectivement, je suis merde, je fais du code complètement pourri
Mes tutoriels
Avant de poster :
- F1
- FAQ
- Tutoriels
- Guide du développeur Delphi devant un problème
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager