Discussion :

[Righetto Dominique]

Bonjour,
Je pense que ce n'est pas le langage qui détermine le professionnalisme d'un dévelopeur mais plutôt sa façon d'aborder un projet, c'est à dire s'il analyse bien les besoins clients et les technologies choisies pour la réalisation de ces besoins, ou alors s'il se jette sur le PC pour produire un produit qui certe peut convenir au client mais coté maintenance et reprise du code par autre développeurs est trés difficile,
De plus l'analyse pré-développemnt est important car elle permet de prévoir les montée en charges, les évolutions possibles, les technologies les mieux adaptées,.....
Enfin ce n'est que mon avis

[michelmoulery]

tout a fais il faut etre bon analyste mais aussi un bon developpeur
un bon testeur , que le programme soit extensible dans le temps

SI une personne fait un super cahier des charges , une communication parfaite avec ses clients et qu'en il commence la programmation ca coince !!!

il faut les 2 ( bon cahier de charges + bonne programmation)
allez au revoir

Bonjour,
Je pense que ce n'est pas le langage qui détermine le professionnalisme d'un dévelopeur mais plutôt sa façon d'aborder un projet, c'est à dire s'il analyse bien les besoins clients et les technologies choisies pour la réalisation de ces besoins, ou alors s'il se jette sur le PC pour produire un produit qui certe peut convenir au client mais coté maintenance et reprise du code par autre développeurs est trés difficile,
De plus l'analyse pré-développemnt est important car elle permet de prévoir les montée en charges, les évolutions possibles, les technologies les mieux adaptées,.....
Enfin ce n'est que mon avis

[Ludolitaliano]

Bonjour à toutes et à tous.
En plus de tout ce qui a été dit et qui est très juste, je pense que c'est surtout au niveau de la maintenance du dév que la différence se fait.

Quand on doit faire évoluer une application bidouillée, il est plus facile de tout recommencer (ou presque). Quand on reprend du code de pro, c'est facile, clair et on préfère ajouter plustôt que de tout recommencer.

[dev03]

Pour moi, un pro, c’est quelqu’un qui se réalise à partir du travail qu’il produit.
Qui sait que les programmes qu’il réalise ne sont pas pour lui-même mais pour les autres.
C’est celui qui termine ce qu’il a commencé.

Le résultat peut se quantifier en €, en « points de notoriété », en nombres de licences distribuées.
Le top étant d’avoir le meilleur score partout.

En effet, rien de plus jouissif pour un développeur, que d’avoir du succès, gagner de l’argent et générer du business.
Pour ne pas oublier les gens qui font du gratuit, le fait qu’un programme soit utilisé massivement apporte de grandes satisfactions.

En fait, les réalisations objectives laissent peu de place à la bidouille.
Sinon, on ne réussit pas.

[Traroth]

C'est essentiellement une question de méthode, au sens large :

Quand un "bidouilleur" developpe, il cherche à obtenir un programme qui, empiriquement, semble fonctionner. Pour obtenir ce resultat, il code jusqu'à que ça marche, en gros
Un "pro" va suivre une methode à tous les niveaux de son travail : definir de manière fine le resultat à obtenir (le plus souvent avec un client ou en tout cas quelqu'un qui "sait" quel est le resultat à obtenir). Ensuite, il va planifier le developpement, de manière à respecter un délai et un coût. Puis, il va réaliser, en suivant là aussi une methode (des regles, quoi), afin que le code ne soit pas suelement fonctionnel, mais maintenable (ajout de fonctionnalité), réutilisable (qu'on puisse utiliser des "morceaux" dans d'autres projets), robuste, sûr, fiable, optimisé, etc. On parle pas de qualité, là ? Si, c'est bien ça. Il cherche à obtenir un résultat de qualité. De meme, pour verifier cette qualité, il va utiliser une procédure de test prédefinie, qui va lui permettre d'etre sur de la qualité de sa réalisation, en particulier que les fonctionnalités critiques de son programme sont pleinement operationnelles, ainsi que d'autres controles, comme les audits de code par exemple, qui permettent de savoir si le code respecte les normes pré-etablies (rappellez-vous : maintenabilité, réutilisabilité).
Toutefois, UN pro seul ne s'occupe en général que d'un morceau de ce travail, qui est generalement devolu à une equipe, mais son travail s'inscrit necessairement dans cette optique (un peu idéalisée, peut-etre )

[skapull]

je suis plus ou moins d'accord avec ce qui c dit, mais pour moi il y à un gros pb à être "pro"(faire du developpement avant de programmer), c qu'il faut connaitre parfaitement les possibilités, limites, du langage utilisé. Et c très dur. Donc on fait un beau projet trés joli sur le papier, et ,oh! surprise, on peut pas le programmer, ou alors on peut le faire mais ça implique ceci et cela; et souvent, on se retrouve à ne pas suivre du tout ce qui à été defini durant la phase developpement, qui constitue dans ce genre de situations une pure perte de temps. Donc pour moi, il vaut mieux melanger les 2, ne pas faire d'abord du pur theorique puis du pur technique, il vaut mieux verifier au fur et à mesure si ce que l'on veut faire est faisable, pour eviter des deceptions et des grosses pertes de temps.
Enfin bon je ne programme que depuis 1 an, et je pretends être generaliste, peut être aurais-je un avis différent quand je serais plus experimenté et spécialisé.

[progfou2]

Bon, pour moi, il faut être pro et extreme programmeur !
En effet, on ne peut pas tout prévoir sur papier. Mais la théorie est essentielle !!!
Il faut donc commencer en pro, et, en cas de problèmes, devenir un peu plus bidouilleur !
Oualà !

[Nicolas Gallerand]

En résumé, chacun de nous est un pro, les bidouilleurs c'est les zôtres!

Pour moi, la différence essentielle est l'approche des problèmes : un débutant (ou bidouilleur) se concentre sur le code et les algorithmes alors qu'un pro (expérimenté donc) réfléchi d'abord sur l'architecture du logiciel.
Mais il est possible d'être un professionnel de la programmation et de faire du code complètement non maintenable, c'est une question d'état d'esprit.
Et puis pourquoi faire des objets alors qu'on peut se contenter de fonctions sans paramètres et déclarer toutes les variables globales...

[Denis69]

Mais il est possible d'être un professionnel de la programmation et de faire du code complètement non maintenable, c'est une question d'état d'esprit.

DSL, mais j'ai déjà du faire ça, mais c'était dû au temps qui m'avait été donné pour un projet !!
En général, j'essaie de faire propre, mais sur ce coup-là, j'ai du y aller au feeling, le plus vite possible... Résultat, une usine à gaz, mais qui tournait ...

PS : je plains le type qui m'a suucédé et qui doit maintenir cette M***E totale..

[dante2002]

Clair,d'ailleurs il est interressant de constater que de tous les programmes où j'ai du passer derrière quelqu'un c'était les programmes écrits par des non informaticiens de formation (cad des comptables, des chimistes,etc) qui programmait en vb qui commentait le mieux et le plus leur source...

Le fait qu'il n'avait pas fait d'études d'info faisait qu'il produisait des programmes simples,clair et avec une structure cohérente.
Pour l'optimisation on repassera (multiples accès aux base de donnés, plein de boucle for,etc) mais personnelement je pense que dans les applications de gestion ce n'est pas le plus important (au contraire des jeux ou du graphisme par exemple).

A l'autre extrème, quand j'ai du passer derrière un ami à moi (qui est BEAUCOUP plus fort que moi en programmation) alors là j'ai galéré, pas de commentaire, tous les raccourcies d'écriture possibles et imaginables (pour les simples style i++ ça va mais certaines sont vraiment tiré par les cheveux).

Personnelement je ne suis pas un 'PRO' , par exemple la phase d'analyse ne vient pas naturellement (en tout cas pas pour un petit projet), mais en général je commente mes codes pour me retrouver et par espect pour mes successeurs...

[Elrond]

Clair,d'ailleurs il est interressant de constater que de tous les programmes où j'ai du passer derrière quelqu'un c'était les programmes écrits par des non informaticiens de formation (cad des comptables, des chimistes,etc) qui programmait en vb qui commentait le mieux et le plus leur source...

Ca depends toujours. Certains informaticiens de profession commentent pas mal leurs sources egalements. Apres le tout est de trouver une juste mesure. Ce qui peut paraitre insuffisant pour certains peut paraitre trop lourd pour d'autres.

J'ai deja vu des programmes ou chaque ligne de code etait commentee. Du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
//Incrementer i
i++;

C'est ce que j'appelle du commentaire excessif. Neanmoins, ca peut etre ce que certains veulent. Tout est une question de dosage. Le deuxieme point au niveau des commentaires, c'est la documentation associee. Avoir une doc qui donne une bonne idee de l'architecture du programme remplace une bonne partie des commentaires du code.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Le fait qu'il n'avait pas fait d'études d'info faisait qu'il produisait des programmes simples,clair et avec une structure cohérente.
Pour l'optimisation on repassera (multiples accès aux base de donnés, plein de boucle for,etc) mais personnelement je pense que dans les applications de gestion ce n'est pas le plus important (au contraire des jeux ou du graphisme par exemple).

Ca depend fortement de la charge du serveur de base de donnees. Si la base est suffisament petite et que seules une ou deux personnes y accedent, ca ne fait pas de difference. Mais j'ai vu plus d'une fois des bases de donnees ou le besoin d'optimisation etait comparable a celui mis en oeuvre pour les graphismes...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

A l'autre extrème, quand j'ai du passer derrière un ami à moi (qui est BEAUCOUP plus fort que moi en programmation) alors là j'ai galéré, pas de commentaire, tous les raccourcies d'écriture possibles et imaginables (pour les simples style i++ ça va mais certaines sont vraiment tiré par les cheveux).

Il etait beaucoup plus fort. Cela n'est fait pas forcement un pro. Il y a certainement des gens qu'on peut qualifier de bidouilleurs qui ont des connaissances beaucoup plus poussees que pas mal de pros. Ca ne veut pas dire que le travail qu'ils font sera meilleurs dans un cadre professionnel. Si leur code est mal commente, s'ils passent des heures a faire des optimisations non-necessaires, ... c'est plutot defavorable dans un milieu professionnel, surtout pour du travail en equipe.

Personnelement je ne suis pas un 'PRO' , par exemple la phase d'analyse ne vient pas naturellement (en tout cas pas pour un petit projet), mais en général je commente mes codes pour me retrouver et par espect pour mes successeurs...

Meme pour les pros, si le projet est "suffisament" petit, il est parfois difficile de se mettre serieusement a une phase d'analyse (detaillee en tout cas). Neanmoins, essayer au moins de produire un resultat propre et retravaillable est deja un bon depart.

[dante2002]

Un autre aspect de la question est que beaucoup de personne font exprès des codes incompréhensibles pour être indispensable à leur boite...
Et ça c'est regrettable comme attitude...

[Elrond]

Un autre aspect de la question est que beaucoup de personne font exprès des codes incompréhensibles pour être indispensable à leur boite...
Et ça c'est regrettable comme attitude...

"Beaucoup", je ne pense pas. Mais il est effectivement probable que ca arrive. Et c'est effectivement tres regrettable.

Neanmoins, si le manager est competent, il va quand meme virer la personne. En effet, si le code est incomprehensible, ca veut dire qu'apres un mois ou deux que la personne n'y aura pas travaille dessus, elle sera a peu pres aussi incompetente pour y faire des modifications que n'importe qui d'autre. Sauf veritable genie (mais dans ce cas il ne devrait pas avoir besoin de cet artifice), tout programmeur a oublie la plupart des details d'un code en quelques semaines (quelques mois au plus) sans y toucher. Il en connaitra encore la structure generale, mais c'est a peu pres tout. Et dans ce cas il vaut mieux y faire travailler quelqu'un de professionnel pour clarifier et restaurer un code correct.

De plus ce genre de probleme peut etre detecte assez tot (et eventuellement resolu) si la compagnie met un place un standard de codage et system de revue reguliere du code.

[Elrond]

C'est sur que prendre de telles mesures "exigent quasiment" d'avoir au moins deux informaticiens...

Je travaille dans une pme, et de telles mesures existent (4 programmeurs pour 40 personnes). Les standards de code sont minimums, les revues sont rares, mais ils existent.

Et malgres tout, je suis souvent capable de reperer le code de l'un ou de l'autre tres rapidement.

Mais je pense que ca peut etre comme ca dans pas mal de metiers. Si une seule personne d'une entreprise connait le metier, alors elle peut avoir ses propres codes, styles, ... qui peuvent rendre difficile a quelqu'un de reprendre son travail.

Ca reste une question d'honetete et d'auto-discipline professionnelle, qui n'est effectivement pas toujours presente.

[Denis69]

Et malgres tout, je suis souvent capable de reperer le code de l'un ou de l'autre tres rapidement.

C'est parfois très facile : Dans ma boite, on programme en Delphi, et on est 3 :
L'un écrit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
if toto then begin
end;

Un autre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
if toto then
begin
end;

Et moi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
If toto Then
Begin
End;

C'est des petits trucs, mais ça fait une grande différence....
et c'est pas de standardiser le codage ki y changerait koi ke ce soit !

[Elrond]

C'est des petits trucs, mais ça fait une grande différence....
et c'est pas de standardiser le codage ki y changerait koi ke ce soit !

Standardiser le codage peut aussi contenir ce genre de petits details. C'est sur que dans ce cas ca demande pas mal de boulot pour ecrire puis apprendre le standard de codage. Certaines entreprise (bon, d'accord, c'est plutot des grandes entreprises) ont des standards de codage si complets que s'ils sont entierement appliques, il est presque impossible en lisant le code de savoir qui l'a ecrit. Il faut alors se referer a l'outil de gestion des sources pour savoir qui a modifie quoi.

Neanmoins, ca devient un cas rarissime je pense. Nous on en est definitivement pas la.

[Fratt]

pq prendre la bidouille aussi négativement ??
je pense qu'il doit exister des pros bidouilleurs, et des pros moins bidouilleurs... la bidouille, c'est juste la chose qui te fait vouloir découvrir de nouvelles, un peu comme la curiosité.. quant à savoir si c'est un vilain défaut; c'est encore une autre histoire.

Ce qui faut différencier, c'est le pro du débutant, ou de l'expérimenté par exemple. Et de même le bidouilleur, du génie et du borné...

.

Enfin, dans les entreprises (pour répondre à un sujet qui en parlait), on préfère toujours agacer les jeunes en les traitant de bidouilleur, ou les solitaires... Certains se font même insultés de pisseur de lignes !! (si si je vous dis). Mais en général, les gens qui font des remarqes comme celles-là n'ont pas réfléchi avant (ptet même po une fois dans leur pte vie). Ils sont pro du SQL qu'ils pratiquent depuis maintenant 10 ans et sont toujours pas capables de cracher ce SQL sans y réfléchir durant 2 jours..

Linus Torvald n'est-il pas le roi de la bidouille ? Et ses confrères Stallman, Raymond et même Carmack ?
Moi je vous dis, la bidouille c'est la graîne du génie.. Reste juste que ça pousse comifo et puis voilà !! comme une belle plante verte..

merci de m'avoir lu

cordialement

fratt

(je ne vise personne ici vu que je ne connais person).

[Elrond]

pq prendre la bidouille aussi négativement ??

Personnellement je ne prends pas la bidouille negativement. Mais elle ne doit pas etre la base d'un projet important. Ce que je fais en genreral dans c'est cas la c'est que je passe quelques temps a bidouiller dans des projets de test pour apprendre et mettre en place certaines choses. Ensuite je concois et realise mon gros projet de facon plus propre.

Enfin, dans les entreprises (pour répondre à un sujet qui en parlait), on préfère toujours agacer les jeunes en les traitant de bidouilleur, ou les solitaires... Certains se font même insultés de pisseur de lignes !! (si si je vous dis). Mais en général, les gens qui font des remarqes comme celles-là n'ont pas réfléchi avant (ptet même po une fois dans leur pte vie). Ils sont pro du SQL qu'ils pratiquent depuis maintenant 10 ans et sont toujours pas capables de cracher ce SQL sans y réfléchir durant 2 jours..

Bidouiller ne devient un defaut dans la vie professionnelle que quand on se contente de ca. Par ailleurs, ne pas savoir bidouiller des choses, et parfois pondre rapidement quelques lignes de code, n'est pas une bonne chose non plus. Le bidouillage est effectivement une bonne facon d'apprendre.

Linus Torvald n'est-il pas le roi de la bidouille ? Et ses confrères Stallman, Raymond et même Carmack ?

Je dirai oui et non. L'avantage de l'open source est que meme si chacun est un peu bidouilleur, la revue du code par toute un communaute permet au moins deux choses:
- Le code, meme s'il est issu d'un bidouilleur de base qui ne se preoccupe pas de qualite ou lisibilite, est revu par tellement de monde qu'a la fin la communaute devrait fournir un code lisible, reutilisable, commente...
- La plupart des gens vont probablement faire attention avant de soumettre du code pour ne pas recevoir un exces de critique.

Tout cela amene finalement un resultat de niveau professionnel (mieux meme que la plupart des projets professionnel). Mais en meme temps cela n'est souvent possible que lorsque ce n'est pas a fin commerciale: pas de delai, pas de besoin de conserver des secrets professionnels, ... C'est un cas rarement rencontre dans le milieu professionnel. C'est pourquoi il faut souvent adopter une autre attitude que celle d'etre "seulement" un bidouilleur.

[davlefou]

Bidoulle ou pro?
Il s'agit d'un difference de philosophie

Le pro est la pour vendre, il doit faire un code stable, pas toujours optimal, facile a entretinir, sur des choses fiables. C'est son gange pain.
Il ne peut pas se permettre de voir son logiciel plante. L'entreprise repoose sur ses épaules.

Le bidoulleur est la pour reussir coute que coute, le fonctionnement est obljectif primordial, mais a quelque concession. Il n'a pas de but financier, mais plutot de plaisir personnel. Ce ne l'empeche pas de faire de tres bon travail, bien au contraire, il n'a pas de contraite en temps, créativite, ou en coup ou se clientelle. C'est l'innovation pure, ca marche ou pas mais ca permette plus de richesse.

Je suis bidouilleur, professionnel au boulot, on fait differement dans les deux cas. Pas les meme contrainte.

[fabien.duminy]

La différence c'est le nombre d'années d'expérience (et le salaire ... en principe !).

Un bidouilleur (qui debug souvent le code, même si les pro le font aussi) c'est potentiellement un futur Pro (ça dépends des personnes et des circonstances). Un Pro c'est un architecte ou un expert logiciel.

J'avais un collègue qui a développé un super logiciel (un serveur applicatif "maison" pour sa société) en JAVA en 6 mois.
Je n'ai pas vu le code, mais, vu les fonctionnalités et comment le logiciel fonctionne, pour moi c'est un Pro. En plus, il est modeste car vu l'importance de son logiciel, il pourrait demander plus. C'est clair que c'est un passionné.

Un Pro, c'est, d'une certaine façon, quelqu'un qui est reconnu par ses pairs comme quelqu'un qui maitrise techniquement. L'idéal pour un Pro, c'est quand il est capable d'expliquer et de transmettre son savoir à un autre qui n'est pas -encore- un Pro.