Discussion :

[dk]

Résultats intéressants. Ce qui me frappe c'est le point "concevoir une solution" : 0.92% / 2% Il n'y que des archi qui ont répondu au questionnaire ou quoi ?
Au taf je réalise beaucoup de revue de code / conception, s'il y a un problème récurrent, c'est bien la conception, et effectivement ensuite le nommage, ce qui est lié parce que les devs ne saisissent pas toujours très bien ce qu'ils implémentent, ni comment ils l'implémentent. Vive l'auto évaluation en somme

[Invité]

Résultats intéressants. Ce qui me frappe c'est le point "concevoir une solution" : 0.92% / 2% Il n'y que des archi qui ont répondu au questionnaire ou quoi ?
Au taf je réalise beaucoup de revue de code / conception, s'il y a un problème récurrent, c'est bien la conception, et effectivement ensuite le nommage, ce qui est lié parce que les devs ne saisissent pas toujours très bien ce qu'ils implémentent, ni comment ils l'implémentent. Vive l'auto évaluation en somme

Très bonne remarque.

Et si on inclut les 16% de "Expliquer ce qu'on fait", ça pourrait vouloir dire que 65% des développeurs ne savent pas ce qu'ils font et n'en n'ont même pas conscience.
Ou alors ils font du PHP.

[autran]

Très bonne remarque.
Et si on inclut les 16% de "Expliquer ce qu'on fait", ça pourrait vouloir dire que 65% des développeurs ne savent pas ce qu'ils font et n'en n'ont même pas conscience.
Ou alors ils font du PHP.

Et pour cause, la plupart développeurs sont trop jeunes pour avoir cette maturité.
Quant à ceux qui sont matures, la RH les juge trop vieux et n'en veut plus comme développeurs mais c'est un autre débat...

[GeoffreyOnRails]

Résultats intéressants. Ce qui me frappe c'est le point "concevoir une solution" : 0.92% / 2% Il n'y que des archi qui ont répondu au questionnaire ou quoi ?
Au taf je réalise beaucoup de revue de code / conception, s'il y a un problème récurrent, c'est bien la conception, et effectivement ensuite le nommage, ce qui est lié parce que les devs ne saisissent pas toujours très bien ce qu'ils implémentent, ni comment ils l'implémentent. Vive l'auto évaluation en somme

Je me suis dit exactement la même chose, même si ça augmenté pour atteindre 5%. (A voté )

Je ne comprends absolument pas comment on peut avoir du mal à nommer les choses, mais ne pas avoir de mal à concevoir une solution.. La première étape pour concevoir une bonne solution, c'est de bien formuler son problème, avec le bon mot sur la bonne notion.

Pour reprendre une célèbre citation de ce cher Boileau :

Ce qui se conçoit bien s’énonce clairement

[Matthieu Vergne]

Je ne comprends absolument pas comment on peut avoir du mal à nommer les choses, mais ne pas avoir de mal à concevoir une solution.. La première étape pour concevoir une bonne solution, c'est de bien formuler son problème, avec le bon mot sur la bonne notion.

C'est peut-être là toute la subtilité : si tu cherches juste une solution (et non forcément une solution qui passe certains critères de qualité), rien ne t'empêche d'en faire une à l'intuition, sans vraiment chercher d'explication. Après quoi, quand tu revois le code pour le nettoyer un peu, tu te rends comptes que c'est pas super clair et qu'il est difficile de mettre en terme sur les concepts que tu as utilisé. Mais ça marche quand même.

Dans le domaine de l'expertise, je ferai le parallèle avec le fait que les experts ont souvent de la difficulté à expliciter leurs pensées, en particulier parce qu'ils ont automatisé leurs comportements. Notamment, quelqu'un ayant de la bouteille te trouveras rapidement des (bonnes) solutions, mais si tu lui demandes d'expliquer pourquoi ou comment ça marche, ce n'est qu'à ce moment là qu'il cherchera effectivement les règles sur lesquelles sa solution se base, pas avant (car la solution lui paraît juste évidente). Autrement dit, si la majorité des répondants sont des gens qui ont déjà une expérience bien ancrée, il me semble logique de voir une tendance "facilité de conception + difficulté de nommage" (la réciproque par contre n'est pas vraie {^_^}).

[el_slapper]

C'est peut-être là toute la subtilité : si tu cherches juste une solution (et non forcément une solution qui passe certains critères de qualité), rien ne t'empêche d'en faire une à l'intuition, sans vraiment chercher d'explication. Après quoi, quand tu revois le code pour le nettoyer un peu, tu te rends comptes que c'est pas super clair et qu'il est difficile de mettre en terme sur les concepts que tu as utilisé. Mais ça marche quand même.

Dans le domaine de l'expertise, je ferai le parallèle avec le fait que les experts ont souvent de la difficulté à expliciter leurs pensées, en particulier parce qu'ils ont automatisé leurs comportements. Notamment, quelqu'un ayant de la bouteille te trouveras rapidement des (bonnes) solutions, mais si tu lui demandes d'expliquer pourquoi ou comment ça marche, ce n'est qu'à ce moment là qu'il cherchera effectivement les règles sur lesquelles sa solution se base, pas avant (car la solution lui paraît juste évidente). Autrement dit, si la majorité des répondants sont des gens qui ont déjà une expérience bien ancrée, il me semble logique de voir une tendance "facilité de conception + difficulté de nommage" (la réciproque par contre n'est pas vraie {^_^}).

+1

Dans les domaines ou je suis bon(je ne me vante pas, tout le monde en a, et il y a plein de domaines, y compris professionnels, ou j'en suis loin), la solution me vient souvent naturellement à l'esprit. Avant même que les autres n'aient compris le problème.

[Matthieu Vergne]

Je vais faire froncer les sourcils, mais pour ma part, aucune difficulté à évaluer le temps nécessaire ! {^_^}
Comment voulez-vous trouver difficile une tâche qu'on ne fait pas ?

Ça fait longtemps que je ne fais plus d'évaluations de ce genre (et quand on me demande combien de temps il me faut, je propose une date pour voir où ça en est). Quand la tâche est simple, pas besoin d'évaluer sa durée, ça se fera entre deux tâches pour se changer les idées, sinon on se met d'accord sur une date de contrôle pour évaluer l'avancée des travaux (c'est pourquoi je préfère parler de milestone plutôt que de deadline), et on se dit si oui ou non ça a l'air de valoir le coup de continuer, de reporter ou d'oublier tout simplement.

Mais je l'avoue, je triche : je fais de la recherche. {^_^}v

[lankoande]

Qu'entendez vous par :

nommer correctement les choses ?

Je ne pense en aucun cas que cela soit un problème. Chacun nomme ses variables,
ses méthodes, ses classes, ses tables, ses ... selon son inspiration. A ce que je sache il n'ya
pas non de norme de nommage ! Alors où se trouve le problème ?
A mon avis, le dure quand on est developpeur c'est pouvoir se faire comprendre par un client
qui ignore tout du developpement. !

[ranzoken]

Pour ma part, deux taches se valent en terme de difficulté : estimer une tache et le nommage

Quand on rentre dans une nouvelle entreprise, on nous demande d'estimer notre charge, or il y a plusieurs paramètres que l'on ne connaît pas à ce moment la.
Pour moi, une bonne estimation du travail demandé est 100 % due à l'expérience, acquise lors de ses précédents projets. Il est donc nécessaire de rencontrer le problème avant d'estimer le temps de résolution. Et dans notre métier, c'est loin d'être facile d'estimer les taches puisque la technologie change sans arrêt, donc les problèmes aussi.

Le deuxième point est le nommage, l'informatique est là pour aider d'autre corps de métier. Donc les noms ne veulent pas forcement signifier la même chose d'un corps de métier à l'autre. De mon point de vue, une bonne règle de nommage à deux contraintes :
- le nom doit être compréhensible par les développeurs (ceux qui font l'application et ceux qui peuvent reprendre l'application)
- être compréhensible pour le corps de métier ou l'application sera déployé.
Or si, je vous donne des noms est-ce que tout le monde le comprendra de la même manière ? (Exemple : "ressource", "niveau",...)


Le reste des taches a chaqu'un son lot de difficulté, mais pour certaine, elle sont hors catégorie, puisqu'elle en font un métier a part entière.
Les tests est un métier a part entier.
La réalisation du cahier des charges est le boulot d'un chef de projet.
...

Je dis ça, mais, la plupart du temps les métiers sont mélangés ^^, comme moi qui fait l'analyse avec le client jusqu’à la formation des utilisateurs pour l'outil en question.

[emmanuel_dumas]

Bonjour,

Je découvre en n° 2 : Travailler avec le code de quelqu'un d'autre - 16.56%

Je trouve cela très dommage.
-> OK, faire du code au quotidien c'est une activité solitaire : le développeur seul face à son écran.
L'une des mauvaises conséquence, c'est que le développeur se referme sur lui-même.

Et la je retrouve un travers de beaucoup de développeur : dans la vrai vie, il faut intéragir avec des vrais gens, avec leurs défauts et leur histoire. Et c'est important que ce ne soit pas une source de stress.

Le code d'autre personne, ce n'est pas un mal, mais un bien.

Cordialement
Emmanuel

[ranzoken]

Je découvre en n° 2 : Travailler avec le code de quelqu'un d'autre - 16.56%

Je trouve cela très dommage.

Dans l'ensemble je suis d'accord, travailler avec le code de quelqu'un d'autre peut être un bien.

l'avantage de travailler avec le code de quelqu'un d'autre, c'est d'apprendre de nouvelle façon de faire. (et je ne dis pas ça parce que je débute)
Après il faut que le développeur ne soit pas quelqu'un qui s’obstine, qui ne voit que de la ..... si ce n'est pas lui qui l'a fait, mais une sorte d'apprentissage
qui va lui permettre d'apprendre si cette solution est performante ou non.

Après cela inclus aussi que le code que l'on reprend soit minimum de qualité.
Par exemple le type de code qui ne devrait jamais exister, lors d'une de mes premières expérience j'ai repris une application en VB5,
qui a été développée par une 15ene de stagiaires de façon successif, et ça c'est une horreur, et même si tous les stagiaires sont extrêmement bon, avec la meilleur volonté du monde le code restera "SALE". D’ailleurs la solution qui a été retenue étais de virer ce logiciel pour prendre une solution pro-logiciel toute faite ^^

[louxorman]

Bonjour, pour moi, sur de petits projets n'impliquant pas de nombreux intervenants, le plus dur est de faire comprendre au client que le gros du travail est l'audit du besoin, l'analyse, et la formulation du CDC.
C'est d'autant plus difficile que :

1/ le client doit participer à ce travail
2/ idéalement il doit aussi le payer car c'est une tache indispensable
3/ il a l'impression de payer du vent, car ce qui l'interesse est d'avoir vite un livrable, et il ne voit pas l'interet d'un bon cdc.

Comment lui faire comprendre cela ?

[Matthieu Vergne]

Comment lui faire comprendre cela ?

[semi-troll]
Soit tu es très pédagogue (i.e. tu le convainc), soit tu es patient (i.e. tu fais comme il veut et tu lui dis à la fin "je vous l'avais bien dit"), soit tu te focalises sur les bénéfices que tu pourras tirer du projet (i.e. tu trouves un meilleur client).
[/semi-troll]

Si tu veux le convaincre, il vaut mieux qu'il soit prêt à changer d'avis (sinon tu peux toujours courir) et parler le même langage que lui. Tu peux tenter de trouver des études ou des rapports relatifs à son domaine qui montrent que ce qu'il croît est une erreur. Une erreur typique, donc pas de quoi avoir honte, mais une erreur quand même.

[Dendrite]

Les questions sont pour le moins limitées.
Il y a 2 choses qui me semblent difficiles au travail, et qui ne sont pas mentionnées ici :

1) Suivre le rythme des demandes d'évolution (une blague à mon boulot, c'est de dire "Le changement, c'est tout le temps !"
2) Etre toujours à la page de la veille technologique...

Et j'ai voté (mais ce serait en 3 et 4) reprendre le code d'un autre (quand on le trouve mauvais en tout cas), et développer un module quand on n'est pas d'accord.

A part ça, ce métier est MERVEILLEUX, je ne m'y ennuie jamais et j'ai l'impression d'être moins bête chaque jour. Il n'y a pas beaucoup de métier qui procure cette délicieuse sensation.

[polkduran]

Travailler avec des personnes incompétentes

[Jitou]

Estimer le temps est de toute manière compliqué pour un développeur ou pour quiconque, architecte ou chef de projet y compris. Aucune estimation n'est fiable dans 95% des projet et pourtant il faut le faire à minima lors de la proposition initiale.

Ensuite écrire les tests ou rédiger la documentation, un développeur ne devrait pas avoir à le faire, car pour plus de pertinence et d'efficacité ce devrait être une personne étrangère au dev et surtout non technique qui devrait s'en charger. Selon le principe de celui qui code ne test pas lui même (tests fonctionnels et pas unitaires ici).

Mettre en œuvre une fonctionnalité avec laquelle on n'est pas d’accord ne devrait jamais être un pb, en tant que développeur on ne décide pas ce que veut le client par contre on a normalement la latitude de décider de la meilleure implémentation technique du moins en accord avec l'architecte technique.

Travailler avec le code de quelqu'un d'autre ne doit pas non plus poser de difficultés si les règles de nommage, l'architecture des packages, les API utilisées sont respectés et les patterns de conception utilisés à bon escient.

[el_slapper]

(.../...)Ensuite écrire les tests ou rédiger la documentation, un développeur ne devrait pas avoir à le faire, car pour plus de pertinence et d'efficacité ce devrait être une personne étrangère au dev et surtout non technique qui devrait s'en charger. Selon le principe de celui qui code ne test pas lui même (tests fonctionnels et pas unitaires ici). (.../...)

D'accord, à un détail près : quelle doc? Parceque la doc technique qui explique comment sont codés les éléments, je ne vois pas qui d'autre que le développeur peut s'y coller.

[Jitou]

D'accord, à un détail près : quelle doc? Parceque la doc technique qui explique comment sont codés les éléments, je ne vois pas qui d'autre que le développeur peut s'y coller.

OK pour la doc technique (je ne parle pas de la doc d'architecture) sauf qu'en 15 ans de projets je n'ai jamais eu à le faire ni jamais vu le faire ... après ce que l'on fait en pratique c'est que l'on commente correctement son code, ce qui sera plus utile pour un développeur après qui reprendra le code pour sa maintenance.

[el_slapper]

OK pour la doc technique (je ne parle pas de la doc d'architecture) sauf qu'en 15 ans de projets je n'ai jamais eu à le faire ni jamais vu le faire ... après ce que l'on fait en pratique c'est que l'on commente correctement son code, ce qui sera plus utile pour un développeur après qui reprendra le code pour sa maintenance.

ça m'est arrivé plusieurs fois qu'on me l'exige. je trouve l'exercice intéressant, ça oblige à justifier les choix qu'on a fait, et parfois on se rend compte qu'on a pas forcément choisi le meilleur chemin. Après, oui, un code auto-documenté est plus utile.

[Glutinus]

J'ai hésité entre Estimer le temps de travail et Expliquer les choses.
Mais expliquer, je pense que c'est très possible, à terme. Bon bien sûr, quand on a une quiche devant soi qui comprend pas comment fonctionne une souris, que faire A1+A2 c'est compliqué mais qui se permet de dire que rajouter un bouton dans le formulaire qui devrait calculer le taux d'indexation de Bougrain-Dubourg par rapport aux données de Wall Street qui viendront après-demain, ça prend pas deux minutes hein.
Il est évident que faire fonction, une requête, une page, qui semble simple parce qu'on l'a fait 100 fois, mais modulo le contexte donné et des fois des choses dont on n'est pas au courant, c'est ultra-difficile.

Je pense que le pire qui me soit arrivé au niveau chiffrage d'un projet, c'était la méconnaissance de mon client. Effectivement, je n'avais pas pris en compte le fait que... je devais fournir un cahier de recette et des données à l'équipe d'homologation !