Discussion :

[plouiserre]

"c'est pas bien d'écrire du code avec des hacks",

Qu'est ce que les hacks en developpement?

[pseudocode]

Cette classification me rappelle assez celle des modèles de maturités :

Niveau de maturité:

• +5 : Optimised
• +4 : Managed (quantified)
• +3 : Defined (standardized)
• +2: Repeatable (disciplined)
• +1 : Initial (chaotic, ad hoc, heroic)
• 0 : Negligent
• -1 : Obstructive
• -2 : Contemptuous
• -3 : Undermining

[notia]

Qu'est ce que les hacks en developpement?

Alors "hack" synonyme: bidouille, "truc et astuce" ou encore un truc foireux
Definition : petit bout de code que tu glisses dans ton application pour corriger souvent un bug ou pour mettre en place une évolution de la mort de derniere minute sorti par ton chef. Comme souvent ces petites mise à jour t'obligent à casser la belle architecture de la mort que tu as concu, ce qui te fendrait le coeur, tu préferes mettre en place une petite bidouille, un truc foireux qui n'est généralement pas documenté mais qui fait que tout marche. Tant que c'est toi qui maintient l'appli, il n'y a pas de souci.
Les problèmes surviennent lorsqu'un autre développeur reprend l'application.
Car le hack est bout de code qui laisse généralement perplexe, on a souvent l'impression que ca sert à rien et on a souvent envie de le supprimer, c'est la que les ennuies commencent.

[Flaburgan]

Qu'est ce que les hacks en developpement?

Je reprends un peu la définition de notia car je n'ai pas exactement la même.
Un hack est une manière de modifier le comportement normal d'une application.

En développement, c'est donc quelque chose qui va sortir du cycle de fonctionnement classique.

Exemple : j'ai une appli qui récupère des données dans une database et qui les affiche. Mais pour X ou Y raison, la base n'a pas les données du mois de novembre. Je connais ses données mais je n'ai pas le droit de modifier la base. Je fais donc rajouter "en dur" dans mon code quelque chose du genre "si le mois demandé est novembre alors ne va pas chercher les données de la base mais prend les ici", en écrivant directement les données dans les fichiers du programme.

Bien sûr, ça marche, mais c'est épouvantable pour la maintenance...

[sevyc64]

Je me reconnais très bien dans ce que dit ce Steven Benner autant dans le premier que dans le second post.

Si j'en crois son classement, certes exagéré mais pas si loin de la réalité que ça, je suis à la fois dans la première et dans la cinquième catégorie, suivant les circonstances, avec une préférence pour la cinquième et une haine viscérale de la quatrième catégorie que l'expérience mais surtout l'age n'arrange pas.

Il revient à ma mémoire une définition d'un de mes professeurs. C'était dans un autre contexte, mais c'est applicable à l'opinion de Steven Benner.

Face à un problème :

- Les mauvais développeurs croient connaitre la bonne méthode

- Les bons développeurs connaissent déjà la bonne méthode

- Les grands développeurs ne connaissent pas la bonne méthode, mais savent comment la trouver

Je suis donc un grand développeur, alors

JE hais les tests qu'il faut parfois passer en entretien, pondre un bon de code, comme ça sur le pouce sans pouvoir préparer, ni réfléchir, comme si on avait tout en mémoire, comme si développer c'était comme réciter les tables de multiplications à l'école primaire.
Et généralement j'échoue.

[el_slapper]

autant son premimer post me parait caricatural au possible, autant j'apprécie le fond du deuxième : l'important, c'est de savoir s'adapter. Se couler dans les pratiques locales, ou du moment.

Pour les tests : j'ai été amené à en faire, et à réfléchir au sujet, face à une hiérarchie traumatisée(à juste titre) par quelques recrutements hautement malheureux. J'aurais aimé pouvoir testé l'adaptabilité des gens, mais j'avais pour contrainte "un QCM, pas plus de 15 minutes, on est pas là pour faire chier les gens pendant 2 heures". Je me suis donc limité à un petit test sur les bases techniques utilisées en local, juste pour vérifier que les gens qui annoncent "15 ans d'expertise dont 12 en COBOL" sont capables de comprendre un code basique dans ledit langage.

Eh bien ça a suffit à éliminer la moitié des candidats..... Pour l'autre moitié, ceux qui n'avaient pas bidonné leur CV(parceque mon test, il ne vole vraiment pas haut), ils ont gardé la méthode "standard" : le courant doit passer(en bref, à la tête du client). C'est évidemment suboptimal, mais il est difficille d'évaluer réellement quelqu'un en quelques minutes.

D'ou ma conclusion : un test pour éliminer les boulets, c'est pertinent. Un test pour trouver la perle rare, c'est de la clownerie.

[pcaboche]

Je classe les développeurs en 2 catégories. Ceux qui font gagner de l'argent à leur boite et ceux qui bloguent sur le classement des développeurs en 5 catégories.

Cyniquement, s'il s'agit de classer les développeurs en 2 catégories, j'aurais plutôt dit : "ceux qui font *vraiment* gagner de l'argent à leur boite (*) et ceux qui lèchent le cul du patron pour obtenir une promotion". Mais bon...

(*) par exemple en apportant une plus-value que personne d'autre ne peut apporter

[Elepole]

<Troll>
Les dev open-source font partie uniquement de la 2 et 3 categorie
</Troll>

[ymajoros]

Je ne sais pas ce qu'est un vrai développeur, mais je sais ce qu'est un vrai bloggueur de seconde zone ;-) C'est du n'importe quoi : que des avis (stéréotypés), pas de faits.

Sur le fond : prétendre que les théoriciens sont à éviter... C'est un peu simpliste.

[dtravailloux]

Un vrai développeur, puisque c'est de ça qu'il s'agit est celui qui sait souffrir..en silence..

[mode 10ème degré]
pris entre les demandes délirantes des commerciaux, les délais du chef de projet intenables, un salaire de misère, une reconnaissance proche de zéro....il doit faire preuve d'abnégation ou tout envoyer bouler et faire autre chose...

Après tout, il m'a fallut 4 ans pour me rendre compte de la situation et cela fait déja 6 ans déja que je suis parti vers d'autres horizons. Maintenant que je suis de l'autre côté, j'ai pas l'impression que cela ait changé beaucoup...
[/mode 10ème degré]

bon courage les gars !

[super_bus]

Bonsoir à tous,

Je ne pense pas que définir ce qu'est un développeur vis-à-vis de lui-même soit judicieux. Le mieux est de la qualifier vis-à-vis des autres intervenants.

Pour un utilisateur lambda, il s'agit de celui qui sait répondre à son attente, c'est à dire respect des fonctionnalités, aucun bogue, rapidité dans l'exécution de ses traitements, toujours à l'écoute des désirs de l'utilisateur ...

Pour un patron, il va de soi que cela tourne entre la rentabilité et le cout. Donc bonne connaissance du ou des langages, rapidité dans l'écriture des programmes (au sens le plus large), aucun besoin de formation, peu de maintenance, facilité à la mise en œuvre, et à l'évolution, grande capacité d'adaptabilité (au changement d'environnement), et aussi, sinon le plus important, savoir s'intégrer à un groupe de travail, et donc ne pas être individualiste.

Pour un chef de projet, il s'agit du respect des délais, de ne pas faire une usine à gaz, d'être autonome, de connaitre le métier du client ...

Pour l'écriture, en général on exige la lisibilité des programmes, de ne pas se faire plaisir en construisant un programme dont seul l'auteur sait de quoi il en retourne, car il faut toujours avoir à l'esprit que l'on travail pour un autre développeur qui fera par la suite la maintenance, de pratiquer la programmation structurée, ainsi que la modularité sous forme de bibliothèques réutilisables, de créer une bonne documentation dont on néglige souvent ...

Et pour finir, la qualité essentielle du développeur est son sens du relationnel, car beaucoup d'informaticiens sont orgueilleux. On ne peut rien leur dire ou leur demander sans qu'ils se fâchent. Ils ont tendance à se prendre pour Dieu, même si leur pouvoir de création est important, ils restent des humains.

Sinon pour revenir au classement, je n'en connais que deux : les bons et les mauvais. Et je peux vous assurer qu'il y a beaucoup de mauvais développeurs,
car ils se prennent tous pour des bons. Seul l'humilité est la règle.

[olivieram]

Bonsoir à tous et à toutes,

Je viens ce soir d'envoyer un mail à mon responsable pour lui préciser que je voudrais passer "expert technique" et j'ai pensé que je lui prouverai mes qualités plus tard, en lui parlant de mes compétences en algorithme par exemple.

Bon gré, mal gré, je suis rentré chez moi et j'ai un peu surfé sur le net.
J'ai trouvé donc cette discussion très intéressante pour mon avenir.
Pas parce que je me destine chef de projet ni responsable avec des tâches administratives à faire mais parce que j'ai envie d'apprendre + de choses.
Et pourtant je suis développeur depuis + de 10 ans.
Pendant ces années là, je n'ai trouvé que des gens surchargés de travail tandis que moi je n'avais besoin que de quelques minutes à plancher. C'est dire si je suis vraiment chanceux ou alors je suis un crack

Mais, j'ai conscience que l'important dans la réalisation de logiciels, c'est la probité : les vertus, la droiture, etc. C'est tout à fait ce que j'ai pressenti quand j'ai commencé à faire de la programmation (il y a fort fort longtemps).

En effet, l'ordinateur est sans faille et il fait exactement ce qu'on lui dit de faire sans se détourner de sa tâche et cela quoique ce soit de ce qu'on lui dit de faire.
Du coup, et c'est là que je vais citer un film éponyme (vous le connaissez par coeur) : il était bien le contraire d'un ordinateur.

Alors, quand on dit développeur 'bon' ou 'mauvais' c'est sûrement nos consciences qui nous parlent.
Parce que lorsque l'on développe on pense pour le bien d'autrui et pas pour soi. On pense comme on le fait, on pense comme un ordinateur, avec droiture et respect.
Et c'est là que l'on viendra nous dire que ce n'est plus ce qu'il faut faire encore aujourd'hui ?

[Rocket06]

pourquoi 5 ? pourquoi 3 ou 7 catégories ?

Je dirai même plus, pourquoi 4 ? Pourquoi 2 ou 6 ?

bref , c'est une opinion , pas une analyse.

C'est peut-être aussi les 2, et même les 3 ou 4 en même temps.

Je classe les développeurs en 2 catégories. Ceux qui font gagner de l'argent à leur boite et ceux qui bloguent sur le classement des développeurs en 5 catégories.

Donc la 1ère, c'est les soumis, et la 2ème, c'est ceux qui ont aussi une vie à côté ^^

[Gabrielly]

Je me retrouve dans la catégorie 2.

[ThomasR]

Il y a ceux qui produisent des codes élégants dans le respect des délais et avec un souci commercial évident...

[pcaboche]

Il y a ceux qui produisent des codes élégants dans le respect des délais et avec un souci commercial évident...

Wow... non seulement le Père Noël existe, mais en plus il travaille dans une SSII.

[pseudocode]

Wow... non seulement le Père Noël existe, mais en plus il travaille dans une SSII.

ou chez Apple...

[ThomasR]

Wow... non seulement le Père Noël existe, mais en plus il travaille dans une SSII.

Parce que tu trouves çà paradoxal ? Moi pas.

Lorsque ca fait des années que tu développes avec un language, si t'arrives pas à faire des codes optimisés, élégants et à les pondre dans le respect des délais c'est qu'il faut arrêter ce métier.

Dans le fond sa catégorisation est marrante, c'est à sortir devant la machine à café.

(je sens que ma prétention va me couter cher )

[pcaboche]

Parce que tu trouves çà paradoxal ? Moi pas.

Lorsque ca fait des années que tu développes avec un language, si t'arrives pas à faire des codes optimisés, élégants et à les pondre dans le respect des délais c'est qu'il faut arrêter ce métier.

Je suis d'accord... tant que tu travailles tout seul.

Le problème, c'est que ce cas est rare. Le plus souvent, tu travailles au sein d'une équipe et là, les choses se gâtent.

Tout d'abord, il y a la hiérarchie. Tu as un chef qui veut que les choses soient implémentées d'une certaine façon et si tu entrevois que ça va poser des problèmes à l'avenir (ex: problèmes de performance), il va falloir parlementer pendant des heures avec ledit chef. S'ensuivent des discussions souvent houleuses qui finissent presque invariablement par "c'est moi le chef, tu fais ce que je dis et tu discutes pas".

Variante: l'entreprise est organisée de telle façon que tu as les concepteurs d'un côté (qui sortent de beaux diagrammes UML, toussa) et les développeurs de l'autre (qui sont confrontés aux problèmes d'implémentation que les beaux diagrammes UML ne pouvaient prévoir).


Ensuite, tu as les autres collègues. La directive, c'est : "il faut écrire du code qui soit facilement compréhensible par tous, au cas où quelqu'un devrait reprendre ton code" (ce que j'appelle vulgairement : "apprendre à programmer pour les nuls").
Traduction d'un point de vue IT : "Fais une implémentation naïve, même si c'est pas performant, de manière que même un stagiaire pourrait comprendre"
Traduction d'un point de vue RH : "Si tu continues à remettre en question les choix de ton chef (alors que tes arguments sont parfaitement fondés), tu risques de prendre la porte, même si tu es considéré par tous comme le meilleur développeur de la boite... Donc ça serait sympa si quelqu'un pouvait maintenir ton appli après ton départ"

Du coup, sur ordre du patron, on part pour l'implémentation naïve, ultra compréhensible, mais qui est tellement peu performante qu'elle en est complètement inutilisable ("pourtant j'vous avais prévenus" ). De là tu dois subir les foudres des utilisateurs mécontents et ton patron viens te demander "t'aurais une solution pour résoudre ce problème ?" (par "solution simple" il pense bien évidement : "un petit hack qui me permettrait de ne pas perdre complètement la face") et toi de lui répondre: "oui, j'ai une solution : TOUT CASSEEEEEEEER !"

Par chance, ce n'est pas une grosse appli (d'un point de vue taille du code. Par contre pour la boite, c'est crucial pour le business) et certaines parties de code peuvent être récupérés (les bouts de code adaptés des exemples fournis dans la doc officielle de la bibliothèque qu'on est en train d'utiliser). Tu refais l'appli et ô miracle, ça marche nickel ! (et ça prend vraiment peu de ressources)

En plus le code est beau et élégant... pour ensuite te rendre compte que tes charmants collègues pourtant "expérimentés" ne savent pas ce qu'est un Generic et n'ont jamais écrit d'application qui s'exécutait sur plus d'un thread à la fois.

Avis du patron: "de belles réalisations, mais souvent un peu complexes et une tendance à tout réécrire". Boulet, va !

Si, à la lecture de ce pamphlet, vous avez l'impression que ça sent le vécu, c'est parfaitement normal...

[lvr]

Tout d'abord, il y a la hiérarchie. Tu as un chef qui veut que les choses soient implémentées d'une certaine façon et si tu entrevois que ça va poser des problèmes à l'avenir (ex: problèmes de performance), il va falloir parlementer pendant des heures avec ledit chef. S'ensuivent des discussions souvent houleuses qui finissent presque invariablement par "c'est moi le chef, tu fais ce que je dis et tu discutes pas".

Quelle image de merde tu as des chefs de projet ! Les bons techniciens (ie développeurs, architectes, ...) sont là pour être écoutés et conseiller leur hiérarchie immédiate sur les pros et les cons des choix et solutions techniques. Mais bon forcément, il y a des gars qu'on est plus prompt à écouter que d'autres, et pas forcément ceux qui abondent dans notre direction.