Le point de vue statistique (en temps de travail) :
Le bidouilleur :
0 % d'analyse
0 % de spécification
30 % de codage
0 % de test
70 % de deboguage
Le pro :
30 % d'analyse
40 % de spécification
20 % de codage
10 % de tests
0 % de déboguage
A +
Le point de vue statistique (en temps de travail) :
Le bidouilleur :
0 % d'analyse
0 % de spécification
30 % de codage
0 % de test
70 % de deboguage
Le pro :
30 % d'analyse
40 % de spécification
20 % de codage
10 % de tests
0 % de déboguage
A +
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
* * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *
: Pq faire des tests alors? (si y a pas de déboguage)... Pour faire gonfler le prix du logiciel?Envoyé par SQLpro
j'y avait pas pensé J'ai hâte de devenir un pro plus de debugger, plus de unit testing, plus de system.out.println,...Envoyé par Florian
un pro est donc un type parfait ( puisqu'il fait pas de debug ) et qui livre un produit sans test ( ou presque, à 10% .... ) ????Le pro :
30 % d'analyse
40 % de spécification
20 % de codage
10 % de tests
0 % de déboguage
mon dieu, j'espere que je monterais jamais dans vos avions si un jour vous deviez en réaliser un.
Le test est certainement l'étape la plus importante d'un projet puisqu'apres il y a l'utilisateur. Il a un droit de veto sur un produit que les autres personnes du projet n'ont pas aussi facilement. Le test est surement la partie la plus longue apres le developpement puisqu'il doit valider TOUT le travail fait en amont.
donc pro ou pas, on fait des tests
pro ou pas on fait du debug parce qu'on est pas parfait et qu'on fait des erreur
pour Epictete
je pense pas que la qualité d'un travail se juge sur l'outil. On peut faire n'importe quoi quelque soit l'outil. Tu as une vision bien reducteur.Je voi que tu persistes à vouloir prouver qu'on peut etre Pro et utiliser VB, c'est sans doute vrai, mais enfin soyons réaliste, les salaires des développeurs Java sont environ du double ou triple des développeurs VB, alors un pro, il va faire quoi a votre avis, du VB ou du java ?
je fais pas de VB mais je trouve ca limite insultant. Je pense pas qu'on puisse qualifié une personne qui a fait du VB pendant 10 ans d' "amateur autodidacte"Peut etre que lui se sent un "Pro" par rapport à la majorité des utilisateurs VB, qui sont principalement des amateurs autodidactes...
voila
Salut !
à propos de VB :
VB est un langage pour les utilisateurs. Ca n'en fait pas un mauvais lanagage, ni un langage pour débutant. C'est un langage pour utilisateur, qui a le mérite d'être super bien intégré dans Access, Word, Excel. (c'est un énorme atout du pack office à mon avis)
Maintenant c'est sûr que c'est pas facile de faire du code propre (professionnel) avec... VB est intuitif (bon pour l'utilisateur) mais pas très structuré (pas bon pour le développeur). Donc, passer sa vie à développer avec, n'est pas une approche très "pro".
Mais désormais tout ça c'est fini gràce à VB.Net ! VB.Net est moins orienté utilisateur que VB. Mais il est devenu un bon langage structuré.
Thomas
Salut,
par expérience, il y a effectivement plusieurs catégories de développeurs avec leur avantage et leur défaut, mais surtout ce qui prime chez un développeur c'est sa volonté et son expérience.
Le bidouilleur est souvent celui qui finit par débloquer le projet géré par des pros mais qui se perdent dans leur schéma UML, leur cahier de spécs. Il sait lire rapidement du code (même mauvais) et finir par en faire quelque chose.
Par contre, si un projet doit être géré, concerne plusieurs intervenants, doit avoir une vie après et fournir un résultat soumis à des contraintes, il vaut mieux être "Pro" (gestion de projet, organisation du code, documentation...)
Si un projet est light, doit se faire dans un lapse de temps court (pour hier , s'orienter vers des manips pas très recommandables (elles ne passent pas dans un schéma UML , le bidouilleur est souvent LA solution.
Sinon, un bon développeur et bien c'est... les deux!! Et il doit profiter de l'expérience acquise pour faire profiter chacun des types de dév. Mais cela s'acquiere dans le temps (ou la nuit ...
Rhodan
En fait c'est pas 0% de déboguage, mais 0.4 %, donc ça ne se voit pas ici .Envoyé par voila
C'est une répartition en temps.Envoyé par voila
Ça veut pas dire qu'on en fait peu, ça veut dire qu'on n'y gaspille pas de temps.
Car les routines de test ont été écrites lors du codage.
De toutes façon ces chiffres sont respectivement une caricature et un idéal.
Un menuisier avec une scie rouillée, un ciseau usé, un marteau cassé, il peut faire du bon travail ?Envoyé par voila
Pt'et ben qu'oui, pt'et ben qu'non.Envoyé par voila
Pour un terrassement d'autoroute, je préfères une pelleteuse.
Pour la bordure d'un parterre de fleurs, je préfères une binette.
Si il s'agit de mener des projets d'envergure, je trouve que VB6 manque trop de concepts puissants et efficaces.
J'ai voulu rajouter une propriété à un bouton radio.
Impossible de dériver, il faut l'incorporer et mapper toutes les propriétés.
J'ai voulu réutiliser ce contrôle dans un autre projet.
Impossible, VB a mis le nom du projet initial dedans. Pourquoi ? Mystère.
:-/
"J'ai toujours rêvé d'un ordinateur qui soit aussi facile à utiliser qu'un téléphone. Mon rêve s'est réalisé : je ne sais plus comment utiliser mon téléphone."-Bjarne Stroustrup
www.stroustrup.com
De toute façon le langage utilisé ne différencie pas un bidouilleur d'un pro.
Moi qui ait été longtemps un énorme bidouilleur, cela m'a passé lorsqu'il a fallut maintenir les aplications que j'ai écrites.
Considérer VB comme un outil de bidouilleur, c'est juger l'outil plutot que l'utilisateur
Cependant l'outil jour un role, c'est plus façile de développer comme un Pro avec un :
-> Outil de conception UML
-> Langage Objet : Java, C++, Pascal Objet, ...
-> Des composants objets métiers (certifiés/testés/documentés)
-> L'extreme programming pour faciliter le déboguage
que de pisser du code en basic n'importe comment...
Bien sur tu peux prendre VB et installer plusieurs addons, ou prendre JBuilder 7 / Delphi 7 (tout est déjà inclus ou presque).
-> Consultez les cours et tutoriels
-> Consultez la F.A.Q du forum que vous utilisez
-> Lisez les règles du forum
évidemment.
Je ne voulais pas dire dans mon précédent post que tous les outils sont équivalents, mais juste que l'on choisi pas toujours ses outils.
Et juger quelqu'un en fonction de l'outil est un peu légèr.
Attention à ne pas confondre unit testing avec extreme programming. Le but essentiel de l'extreme programming c'est de faciliter le developpement dans un environment qui change continuellement (embrace change)...
oui enfin certe cependant parfois les developpeurs ont aussi le droit à la parole, et UML c'est déjà largement bien reconu. Reste à mieux faire connaitre MDA et l'extreme Programming...mais juste que l'on choisi pas toujours ses outils.
Oui fin certe tous les cas sont possibles, cependant il y à de nombreux postes de developpeurs Java/UML , C++, Delphi, etc... à pourvoir, alors tous le monde est libre d'évoluer comme il veux...Et juger quelqu'un en fonction de l'outil est un peu légèr.
Je rappelle que en moyenne le salaire moyen entre un développeur VB et un développeur Java/UML ca va du simple au double, alors il y à bien une raison non ?
-> Consultez les cours et tutoriels
-> Consultez la F.A.Q du forum que vous utilisez
-> Lisez les règles du forum
Hi
Je vais *essayer* d'apporter ma modeste contribution sur ce léger problème de "terminologie" (pour mon premier post dans ce forum) :p
Je pense que les qualificatifs que l'on peut attribuer à un developpeur ne sont pas d'ordre exclusif. On peut être bidouilleur et/ou "pro", ou aucun des deux ... Dans tous les cas, l'un comme l'autre ne devrait pas adopter un sens forcément péjoratif.
Etre développeur pro, c'est avant tout une question de communication. Il faut être capable d'expliquer tout ce que l'on fait, des choix globaux jusqu'à la moindre ligne de code. C'est pas si compliqué, mais c'est déja énorme. Lorsqu'on est même pas capable de s'auto-expliquer (à haute voix, c'est important) ce que l'on a fait, on peut être sur de ne pas être pro. Ensuite, viennent les commentaires dans le code, les docs de conception, etc, etc qui matérialisent dans le projet l'attitude qu'à eut le développeur lors de sa conception ... ce qui désolidarise le créateur de sa création en lui transmettant ce caractère "pro".
Et on attribue aussi au pro cette aptitude à tout préparer plus ou moins minutieusement ... En résumé, le pro:
- rationnalise tout ce qu'il fait
- matérialise ses raisonnements
- est proactif
Pour ce qui est du bidouilleur, le sens est un peu trop multiple et vaste. On pourrait le considérer comme un Mac Gyver de l'informatique, capable de réagir avec les moyens du bord face à toute situation ... Mais il serait aussi le "défricheur" qui résoud un probléme au feeling, en plongeant dedans. Résumons tout simplement à:
- débrouillard
- réactif
- intuitif
Dans les deux cas, ce ne sont certainement pas des défauts, mais c'est sur qu'en les empêchant de cohabité par l'exclusivité, la carence de l'un représente les défauts de l'autre.
Personnellement, je considére que si l'on veut faire de l'informatique son métier, être pro est indispensable, et être bidouilleur est un immense avantage, tant que ces deux aptitudes coopérent en harmonie.
-------------
Un ptit détail en passant (rapport à quelques posts):
L'extreme programming n'a d'extreme que le nom. Ses deux principales caractéristiques, sans entrer dans les détails, sont:
- Travail en binome, avec roulements réguliers
- Pour chaque "module", écriture des tests avant même le codage du "module"
Et c'est une méthode qui a largement fait ses preuves d'efficacité.
J'ai effacé quelques messages inutiles...
Plutot que de revenir dans le débat VB versus Delphi, débat déjà fais 10 fois, pour redire ce qui à déjà été dis de nombreuses fois sur ce meme forum, commencez par bien lire ce qui à déà été écris, et ne postez que pour apporter des éléments nouveaux.
Exemple de sujets intéréssants : UML, MDA, Extreme programing, la conception et les tests en général, les doc, la gestion des versions, etc...
Evitez d'intervenir pour poster un stupide troll de 2 lignes sans aucun contenu technique...
Merci
Ne pas me contacter pour le forum et je ne répondrai à aucune question technique. Pour contacter les différents services du club (publications, partenariats, publicité, ...) : Contacts
15 000 offres d'emploi développeurs et informatique
Cours et tutoriels développeurs et informatique
Les FAQ's & Les Livres
Codes sources
Téléchargements
Hop hop hop, j'apporte à ma petite contribution en vous expliquant ma vision du "développeur pro" et du "bidouilleur" :
Le "développeur pro" commence pour moi par effectuer une analyse fonctionnelle et conceptuelle, en recensant tout d'abord les concepts, et en mettant en place un modèle conceptuel de (souvent avec les principes de la méthode Merise). Ce MCD permet de donner 1 représentation des liaisons pouvant exister entre les différents concepts. Vient ensuite unephase de recencsement des taches à réaliser (manuelles ou informatisées) et des événements qui les déclenchent. Il faut préciser tout traitement d'un modèle organisationnel, expliquer le sprincipes et l'organisation. Cette phase permet au développeur de bien cadrer le projet, de soulever les problèmes possibles et de les résoudre en pesant entre autres au soucis de dépendances et des contraintes (intégrité, etc...). Si cette analyse est en accord avec le cahier des charges (dans le cadre d'un projet à réaliser), le développeur peut donc commencer la phase dite de codage avec là encore divers principes à observer je pense :
il est tout d'abord nécessaire de découper chaque problème en sous-problèmes simples à résoudre afin de clarifier le raisonnement pour qu'il soit plus sûr. Chaque algorithme doit être autant que possible universel, c'est à dire qu'il sera écrit une seule fois et réutilisée par la suite lorsque ce sera nécessaire (sans pour autant qu'il soit nécessaire de le modifier). Il faut aussi essayer au maximum de définir des types (ou classes) avec leurs attributs et méthodes spécifiques (analogie avec les langages orientés objets mais cela est aussi réalisable dans bon nombre de langages fonctionnels et procéduraux). Une fois un objet et ses services définis, il sera mis de côté et pourra être réutilisé à tout moment.
Le code quant à lui doit être aéré, commenté au niveau des points non triviaux, et chaque algorithme doit être précédé d'une courte analyse (en générale entrées, sorties, stratégie, var intermédiaires). Ce dernier point me semble essentiel pour assurer la "survie" d'un programmeà long terme, afin de pouvoir aisément le modifier plusieurs années après l'avoir écrit (ou bien qu'un collègue puisse le comprendre et le modifier facilement). Le respect de ces méthodes (que j'effectue) permet de réduire pratiquement à néant la phase de déboggage, et de prévenir afin d'éviter les mauvaises surprises ou les erreurs de conceptions. Le programmee st ainsi bien souvent plus optimisé et nettement plus propre.
Pour ce qui est du "bidouilleur", je dirai qu'il se jette corps et âme dans la partie codage directement sans effectuer une étude préalable. Cela présente divers inconvénients, et il arrive assez souvent que le "bidouilleur" soit confronté à des erreurs de conception durant la réalisation du programme.... De plus je dirai que le code du "bidouilleur" est moins unviersel, plus difficile à réutiliser et adapter.
Pour conclure je pense que tout programme écrit par un "bidouilleur" peut aussi bien marcher qu'un programme similaire écrits par un professionnel, le "bidouilleur" a toutefois très souvent un programme plus lent, beaucoup moins propre et très ciblé. Il est très rare qu'il puisse utiliser des algorithmes écrits pour résoudre d'autres problèmes, et le code puisse être repris par une personne autre que celle qui l'a écrit !
Je pense qu'on peut etre les deux, en fonction de l'objectif, du temps alloue, de l'outils fourni, ...
Comme je maitrise assez bien VC++, j'espere avoir un attitude plutot professionnelle quand je l'utilise. Par contre si je devais developper en Java, j'arriverai surement a me debrouiller, ayant des connaissances non negligeables de programmation object, mais il y aurait sans doute une bonne part de bidouille pour assembler correctement les morceaux. Donc dans ce cas ca depend de l'outil.
Dernierement, j'ai travaille sur un projet assez important. J'espere que le programme a ete developpe de facon assez professionnelle. En attendant une prochaine version, un client a demande un ajut sur le programme. Comme c'est quelque chose de temporaire qui ne devrait pas etre reconduit dans les futures versions, et que c'est vraiment urgent, j'ai ajoute rapidement le code necessaire sans specialement reflechir a sa reutilisabilite ou a une quelconque flexibilite. J'ai juste ajoute ces quelques lignes comme une sorte de bidouille. Mais meme en faisant cela j'ai essaye de garder une attitude professionnelle.
Quand je programme de facon personnelle pour moi, je fait parfois des test de programme pour essayer d'optimiser ou de decouvrir de nouvelles choses. Ces programmes s'apparente plutot a de la bidouille.
Le cote professionnel est je pense une attitude.
La premiere chose est en general de prendre conscience que le code qu'on produit est cense etre un jour utilise/modifie/debugge par quelqu'un d'autre. Le but est donc qu'il soit aussi lisible que possible. Pour cela il faut garder une structure de programmation identique tout au long du programme, bien commenter chaque fonction et l'essentiel des algorithmes, ...
Une autre chose a faire est de fournir un code aussi "sur" que possible. Cela exige de realise des tests. En fonction des delais et de la complexite, le niveau de test peut largement varier, mais un minimum de tests est necessaire, quelque chose de plus que de simplement lancer l'application et l'utiliser jusqu'a ce que ca plante.
Il est ensuite necessaire de reflechir a ce que l'on fait avant de le faire. En fonction de la tache, un conception approfondie n'est pas toujours necessaire, mais il reste indispensable malgres tout de penser a ce que l'on va faire avant de commencer.
Pour repondre a quelques remarques que j'ai lues:
A moins d'avoir un environnement de programmation extrement strict (temps reel, application mettant les vies en jeux, ...) qui demande un niveau de conception extrememnt pousse, le debuggage, meme dans un milieu professionnel, est largement au-dessus de 0,4%.
Le langage n'a rien a voir avec le fait d'etre un bidouilleur ou un professionnel. Je connait plus de bidouilleurs en C++ qu'en VB. Cela est du a la complexite de C++ qui le rends difficile a maitriser, et pqrce quune fois maitrise (jusqu'a un certain niveau) on peut faire bien plus de choses avec. Si VB est bien plus facile a maitriser, bien l'utiliser demande un attitude professionnelle autant que l'utilisation de C++.
Le salaire n'a rien a voir avec le fait d'etre un pro ou non. Les experts C++ sont probablement bien mieux payes que les experts VB, mais un debutant C++ n'est guere plus paye qu'un debutant VB. Et ce n'est pas parce qu'un macon est moins bien paye qu'un plombier qu'il est moins professionel.
J'ai eu un collegue bidouilleur qui avait une attitude absoluement non professionnelle. Il avait surement des connaissances techniques assez poussees (et superieures aux miennes). J'ai a peu pres toujours fini mes taches dans les temps, le plupart des autres aussi, il n'a jamais fini dans les temps, et c'est de sa partie que sortaient les plus de bugs. Et meme losque son code etait bon, il arrivait souvent qu'il ne corresponde pas a ce qui etait demande, qu'il oublie des cas, ... Et quand il avait des problemes, ce n'est qu'en lui posant des question qu'on finissait pas le savoir. Il n'est jamais venu le dire de lui meme.
En gros, pour travailler dans le milieu professionnel, peu importe qu'on soit bidouilleur ou non, il faut avant tout une attitude professionnelle.
Si la connaissance peut créer des problemes, ce n'est pas par l'ignorance que l'on peut les résoudre.
-- Isaac Asimov
Voilà, après avoir l'intégralité de ce forum, je ne sais plus si je suis un "pro" ou un "bidouilleur" !!!
1-Je programme pour mon plaisir personnel, sans en tirer le moindre revenu. (bidouilleur?)
2-Déjà 20 ans de programmation (basic, assembleur, pascal, c objet(NeXTstep), visual basic (enfin non j'ai pas réussi), java+webobject (mac)) (pro?)
3-Quand je développe, je sais quel but je veux atteindre, je ne fait pas d'analyse globale du projet, juste des notes globales. (bidouilleur?)
4-A chaque sous programme écrit, je le teste dans toutes ses possibilités normales, et anormales, il n'y a en général pas de bugs à la sortie (pro?)
5-Depuis plus de 10 ans, je programme en C objet (NeXTstep) et maintenant java alors que je n'ai rien réussi à programmer en VB entre les deux. (pro?)
6-Mes sources sont peu documentés, juste un commentaire global en début de chaque chapitre. (Bidouilleur?)
A mon actif (3 logiciels de facturation spécifiques utilisés en interne (1 en basic, 1 en assembleur, 1 en C objet qui fonctionne encore depuis 10 ans), 1 mur de briques en assembleur sur un pocket PC1500, 1 logiciel de généalogie canine (C objet, en cours de réécriture en webobject), 1 logiciel de calcul de ressorts (http://ressort.dyndns.org:4210) en webobject.
En bref, je pense que le débat est un faux débat. Que celui qui n'a jamais eu de bug dans l'un de ses programmes me jette la première pierre. Quel que soit le programmeur, il y a toujours des bugs lors de l'écriture d'un programmes (malheureusement) que l'on soit pro ou bidouilleur. Il n'empeche également que l'écriture "propre" facilite la maintenance, et que la programmation objet facilite la réutilisation de librairies.
Bonne programmation à tous
un "bidouilleur"
mac pro bi-quad néhalem (2009) (16 proc et 8Go me MeV)
Programmation : HTML - Javascript - PHP - AJAX - CSS : niveau amateur pour l'ensemble.
"Pro" : ce que tout le monde voudrait être, et - soyons sincères - ce que la plupart d'entre nous, espèrent tout de même être un petit peu !
"Bidouilleur" : terme méprisant utilisé par certains pour dévaloriser d'autres personnes.
Comment savoir, finalement ? C'est assez simple : il suffit de demander l'avis aux utilisateurs. Et à budget égal, temps disponible égal, le pro - quelque soit sa méthode de travail et peut-être même son outil de travail - finalement, fera toujours la différence.
Le programme correspond-il aux souhaits des utilisateurs ? Ont-ils seulement étés consultés ? Le programme est-il facile à utiliser, même par un débutant ? ...sinon, une formation est-elle prévue ? Intègre-t-il un système d'aide, ou tout au-moins la documentation minimale de base, même sous forme papier ? Le programme fait-il quelque chose de clair ou génère-t-il une mayonnaise interne incompréhensible ? Est-il agréable à utiliser ? A-t-il une interface conviviale et moderne, qui valorise celui qui s'en sert ? Ne doit-on pas attendre trop longtemps devant l'écran ? Ne se plante - t -il pas "trop" souvent ? Faut-il toujours et sans cesse lui donner les mêmes longues séries d'instructions car il est incapable de les mémoriser ? Faut-il souvent aller chercher ces mêmes instructions dans des tas de sous-menus et dialogues d'options incompréhensibles également qu'on ne retrouve qu'après un angoissant quart d'heure ? etc.
La mention "Pro", ne peut être décernée que par l'utilisateur.
Philippe
j'ai lu récemment que ~ 90% du coût d'un logiciel était dans sa maintenance et sà mise à jour.
bien sûr, il y'a des "gros logiciels" tel que office, avec lesquels on peut de suite faire beaucoup (dont la plupart des fonctions ne nous sont d'aucune utilité).
un bon programmeur et celui qui développe en fonction du client, qui peut même aller jusqu'a créer le besoins, qui satisfait ce besoins, qui respecte les délais, et qui structure (organigrame, structograme, listing) sur papier avant d'aller chier son code sur l'ordi ...
on dit que le bidouilleur fait de la programmation spaghetti ou plus communément "chie du code" et le bon programmeur "pond du code"...
"L'homme est poussé par le besoin de savoir"
J. Robert Oppenheimer (1904 - 1967)
Un peu dur ici meme étant sur delphi et avant sous prologueEnvoyé par Maurice
il faut avoir un respect pour tous les informaticiens
qu'l que soit leur langage.
Car je suis sur qu'il existe des developpeurs en vb qui gagne plus que
vous !!! 8)
sans rancune
michel
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