Discussion :

[christ_mallet]

Quelle est la différence réelle entre un "bidouilleur" et son contraire, c'est à dire un pro.
J'entends souvent traiter négativement les développeurs de bidouilleurs alors que le travail réalisé est souvent remarquable.

[Karuto]

lol pour moi un bidouilleur c un mek ki se rue sur son pc pour coder les truks ki lui passent par la tête alors qu'un pro c'est un mek ki developpe apres avoir fait une etude de besoins, une etude fonctionnelle et qui ne passe au codage qu'une fois l'architecture de son travail bien etablie.

bon serieusement du haut de ma toute petite experience d'etudiant et de stagiaire j'ai du dévellopper une bonne vingtaine de projet et meme en entreprise je suis jamais tombé dans un projet ou vraiment tout etait carré et tout défini a l'avance. bien sur en entreprise c plus strict et plus protocolaire mais l'esprit reste un peu celui de la bidouille

(sauf si tu te retrouves dans un dévelloppement long et deja bien entamé ou la tache est deja définie et ou il ne erste plus k'a finaliser

[Geronimo]

D'après moi,

La bidouille c'est aussi : tu tapes 3 lignes, tu compiles, tu regardes si ça marche, tu regardes ce qui manque, tu le rajoutes après...

Un pro écrit une bonne partie de son code bien proprement, le commente au fur et à mesure et enfin compile.

[Epictète]

On dit plus bidouille on dit extreme programming !!!

zetes pas à la mode les gars...

[christ_mallet]

Je pose cette question en faisant référence à ce que j'ai vu en entreprises, des gens qui se font traités de "bidouilleurs" alors qu'ils ont fabriqués des logiciels très valables, très compétitifs, mais qui ont travaillé un peu seuls.

La reproche me semble t'il provient seulement d'un manque de documentation. Est ce qu'un pro fabrique est un bibouilleur qui rédige une bonne documentation, la différence me paraît léger.

[debug]

y'a une autre différence.
Le pro prévoit tout les problèmes possibles avant même de faire sont code.
Le bidouilleur retouche son code quand il tombe sur le probleme à l'utilisation du soft !!

[ddams]

Je ne crois pas qu'un développeur VB soit un bidouilleur. Simplement, un bon programmeur doit avoir de la méthode et exploiter les outils à sa disposition (qu'il s'agisse de langages très permissifs comme VB ou le langages plus structurés comme Java).


Je rejoint tout à fait Karuto dans sa définition du bidouilleur !!

@+ddams

[Straahd]

IL y a plein de difference a mon avis entre le bidouilleur et le pro. Dans la programmation le soft final c'est pas le plus important, un soft sert a rien si un ou deux ans aprés personne ne peut de modifier. De meme en general les gens qu'on traite de bidouiller sont ceux qui utilise des moyens detourné pour arriver a leurs fin. Ca marche mais c'est pas forcement adaptable, c'est faire un truc qui marche dans certain cas , alors que l'on pourrai y mettre un truc generique.

En gros bidouiller en info c'est comme de la bidouiller dans n'importe quel autre domaine, le plus grand de tous etant Macgyver

[exxos]

Bidouilleur : machines a gaz (mais qui peut etre optimise)
Normal : code reexploitable
Pro: code reexploitable plus grosse optimisation

Codeur a posseder :code reexploitable +mega optimisation + commentatires limpides + repondant aux demandes + ponctuel + ... >>Inexistant

[knotty]

Solution a la bidouille: "peer reviews"

Des entretiens a 4 ou 5 pour revoir chaque revision de toutes les etapes d'un projet, depuis les "requirements", architecture, code, documentation.

Chaque ligne de code ou de texte, de commentaire ou de javadoc se doit d'etre "revue".

Sauf a faire ca, on est dans la bidouille. Si y a pas de suivi et de verif dans un projet, inevitablement, c'est de la bidouille.

Pas besoin d'etre un pro pour faire du travail de pro.
C'est ce qui se passe dans toutes les grosses boites, car c'est obligatoire.

[voila]

programmer de maniere "pro" c'est avoir une approche structurée d'un probleme, qui est généralement l'approche systemique : j'ai un gros probleme difficilement résolvable, je le divise en N petits problemes facilement résolvable. La programmation structuré rend la lecture du code simple et permet de rédiger une documentation simple d'acces.

La bidouille c'est de résoudre un probleme suivant la logique et l'humeur du developpeur à l'instant T, en clair compréhensible que par lui à cette instant. Il n'est pas sur qu'un bidouilleur puisse relire son propre code 1 an apres.

juste une info, ceux qui parle d'utilisateur dans la programmation "pro" n'ont rien compris puisque l'ihm ( son ergonomie ) est défini par l'analyse ( qui peut etre le developpeur mais c'est déconseillé ) et n'a rien avoir avec la programmation structurée.

Ah oui, les bidouilleurs c'est aussi ceux qui confondent tout et croivent tout savoir, veulent tout faire et fini par tout planter et hurler à la mort que c'est de la faute de windows ou du chien du voisin qui à pisser au meme moment sur la rue d'en face.

Enfin la programmation "pro" n'a rien avoir avec le langage ou le code en lui meme, certains diront que c'est "plus" pro de mettre i+=1 en C++ au lieu de i=i+1 ou i++, moi perso c'est pas à ca que je juge la qualité d'un code.

[DrQ]

Ben pour la définition je pense que celle Karuto est la plus adaptée.

Généralement le bidouilleurs essaie de faire marcher son système avec ses propres petites techniques. Comme 9/10, il n'y a que lui qui comprend le code, on dit qu'il est bidouilleur alors que ce n'est généralement pas le cas.

On colle le nom de bidouilleur à tout développeur qui pond un code qui semble bizarre pour le lecteur.

[b_free]

Le "pro" c'est la norme, le "bidouilleur" c'est tout le reste.

Le "pro" fourni un travail pro:
-documenté même mal
-code lisible et surtout compréhensible par le développeur moyen
-dans les temps ou avec une bonne excuse

Le "bidouilleur" est tout ce qui ne rentre pas dans la partie pro:
-l'innovation (incompréhensible par la moyenne)
-le code spaghetti (pour les mauvais)
-la complexité (incompréhensible par la moyenne)
-hors délai (pas dans la moyenne)

Le "pro" c'est la masse, le "bidouilleur" tout ce qui dépasse !!!

[MoineCopiste]

Solution a la bidouille: "peer reviews"

Des entretiens a 4 ou 5 pour revoir chaque revision de toutes les etapes d'un projet, depuis les "requirements", architecture, code, documentation.

Chaque ligne de code ou de texte, de commentaire ou de javadoc se doit d'etre "revue".

Sauf a faire ca, on est dans la bidouille. Si y a pas de suivi et de verif dans un projet, inevitablement, c'est de la bidouille.

Pas besoin d'etre un pro pour faire du travail de pro.
C'est ce qui se passe dans toutes les grosses boites, car c'est obligatoire.

Je tiens à signaler que ce qui suit n’est pas une agression !! Mais une simple constatation, et je me fais le porte-parole des “néo-bidouilleurs”! Merci de bien vouloir lire jusqu’au bout !!

Pour ma part un Bidouilleur est une personne qui, partant de rien et avec les “moyens du bord” veut créer, et arriver au moins, au même niveau que le Pro, tout en ayant pas pu avoir une formation de départ , pour X raison, mais qui est passionnée ! Un autodidacte, se frayant un passage au milieu de codes et de langages inconnus de lui, à la force des neuronnes, avec toutes les galères que cela implique !
Un Pro ( un certain pourcentage ) se prennent pour des Dieux, et jettent un regard de dépit sur les Bidouilleurs !! Si Si ! Je peux le prouver !! ( Heureusement il y a des Pro qui sont intelligents ) Ils ne font rien sans rien !
Pourquoi je dis cela ? Parce que, lorsque l’on discute avec des personnes qui veulent “débuter” dans la programmation, ( Surtout dans une tranche d’age 40 - 50ans, il n’y a pas d’age ?? ) Ils vous disent, et je l’ai entendu !! On m’a répondu :“à votre age , c’est plus la peine, et en plus vous ne connaissez pas l’anglais !!” Et certains ne prennent pas la peine de répondre aux questions de base !! Ils n’ont pas de temps à consacrer ? Parce que cela est non Lucratif ?? ha ha ! Je ris !!CHAMPOLLION connaissait les hiéroglyphes ??
Alors , les pseudo Pro soyez humble !! Et Rappelez vous vos début !!!
Merci à tous !! Et sans rancune !!

[Henry Cesbron Lavau]

Une question intéressante est
qu'est-ce qui différencie le développement incrémental de la bidouille ?

L'Extreme Programming préconise en effet le développement incrémental mais à plusieurs conditions :
- Ce que l'on veut, même les petites modifs, est vu avec le client final.
- Les lignes de test sont écrites avant les lignes opérationnelles.
- Le test est vérifié, pour la modif, puis pour l'ensemble du projet.
- Le produit reste livrable à tout moment.

[MarsuGL]

Extrait de "Le processus unifié de developpement logiciel" par Jacobson,Booch,rumbaugh
----------------------------------------------------------------------

"Ce que n'est pas une itération :

certains responsables pensent que l'expression 'itératif ou incrémental' est un charmant oeuphémisme pour 'bidouillage'. Ils craignent que les mots ne servent qu'a jeter un voile pudique sur le fait que les developpeurs ne savent pas ce qu'ils font. On peut concéder, dans la phase de création et meme au début de la phase d'élaboration, que cette crainte n'est pas totalement dénuée de fondement. Si par exemple les developpeurs n'ont pas résolus les risques majeurs ou significatifs, il faut alors reconnaitre que cette position se défend. S'ils n'ont pas encore démontrés la viabilité du concept sous-jascent ni établi une architecture de référence, la encore, cette affirmation est exacte. Si, enfin, ils n'ont pas encore déterminés de quelle façon implémenter les besoins décisifs, il faut a nouveau se rendre a l'évidence. Il est possible somme toute, qu'ils ne sachent pas ce qu'ils font.

Est-il alors judicieux de prétendre qu'ils savent tout de meme ce qu'ils font? De faire reposer un plan sur des informations insuffisantes ? De suivre un plan auquel on ne pourra se fier?
Bien sur que non.

A titre indicatif; insistons sur ce que n'est pas un cycle de vie itératif :
- ce n'est pas un bidouillage de fortune.
- ce n'est pas une attraction pour developpeurs.
- ce n'est pas un phénomene ne concernant que les developpeurs
- ce n'est pas une tentative infiniement renouvellée jusqu'a ce que les developpeurs tombent pas hazard sur quelquechose qui fonctionne.
- ce n'est pas un processus imprévisible
- ce n'est pas une excuse pour l'absence de plan et une gestion inexistante.

En fait, l'itération controlée est loin d'etre exécutée au hazard; elle est planifiée. C'est un outil qui permet aux responsables de maitriser le projet. Elle permet de réduire des les premiers stades du cycle de vie, les risques succeptibles de menacer la progression du developpement. a l'issue des itérations, les versions internes (..) ouvrent la voie aux retours des intervenants, qui permettent a leur tour, de ectifier tres tot l'orientation du projet. "

[christ_mallet]

Ok pour le développement des tests avant, mais est ce que celà ne porte que sur les exigences de type fonctionnels, comment tester la tenue à la charge.

Dans ma petite expérience professionnelle, je n'ai eu affaire qu'à des pro , mon sentiment étaient que quel que soit le plan d'assurance qualité,
- les développements étaient toujours en retard, sur des cycles plutôt longs alors qu'on ne cesse de me parler de système RAD ou OOD
- souvent mal documentés, ou décevant
- le code pas si lisible que çà, ou uniquement par le développeur
- généralement pas mal buggués.

Un an et demi de mise au point après livraison n'est pas du superflux.

[Henry Cesbron Lavau]

1° question : Les tests portent également sur la montée en charge et les performances.
Ils doivent inclure une génération automatique de jeux d'essais, dont on peut à la demande régler le volume.

2° question : les projets sont en retard parce que l'utilisateur ne peut savoir exactement ce qu'il veut avant d'avoir vu le soft. Pour sortir de ce cercle vicieux, autant l'associer de manière continue à l'évolution du produit : ce sera en retard par rapport à ce qu'il imaginait, mais au moins ce sera ce qu'il imaginait.

3° question : le fait d'écrire le code de test avant le code opérationnel produit de facto un exemple d'utilisation, permet souvent d'améliorer l'interface d'appels, et produit quelque chose qu'il suffirait de pousser à peine pour que cela devienne de la quasi documentation de maintenance.
De plus les bugs sont ainsi étroitement surveillés tout au long de l'évolution.

D'après mon expérience, cela prend environ 2 fois plus de temps de procéder ainsi..........seulement 2 fois, et pour obtenir un produit nickel!

[HRS]

je ne pense pas qu'il faille opposer "bidouilleur" à "pro"

Cependant, le "bidouilleur", s'il fait des programmes qui marchent, n'a
pas pas la préoccupation de transmettre son savoir. Son code est toujours
illisible; souvent à dessein. Même lui ne s'y retrouve pas quand il a
besoin, 6 mois après, de faire des modifications. il travaille solo et
perso. S'il démissionne ou est malade, ceux qui passent derrière lui
sont obligés de refaire intégralement son travail.

Par contre il est très utile pour défricher de nouveaux domaines. Ne
pas oublier que l'informatique a commencé avec les "bidouilleurs".

En fait, un bon gestionnaire peut se servir d'un "bidouilleur" comme
d'un cochon truffier; ce dernier cherche et trouve les truffes mais
il faut les récupérer avant qu'il ne les mange.

[charly]

dans tous les exemples que vous avez donner je me suis sentis ... bidouilleur .. pour moi un pro c est quelqu un capable avec n importe qu elle outils ( ou meme sans ) de faire un progs valabe ... apres tous a quoi sa avance si soon code et bien tape et clair .. c est lui qui le cree du moment qu il le comprends ? par contre le pro lui doit etre capable de contourner les problemes (seul) ... de recre des outils si il en a besoin ... bref qui peut se debrouiller seul et faire un travail correcte... j en suis loin tres loin ...