Discussion :

[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. !

[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.

[Cincinnatus]

bonjour les tâches les plus difficiles essentiellement pour un développeur c'est de

comprendre précisément le métier du client dans le service informatique
si vous travaillez dans la banque il faut comprendre un minimum les métiers de la banque.

pouvoir conceptualiser , aller dans l'abstraction...avoir une vision globale d'un projet...

de ce qui est indiqué précédemment analyser un problème complexe et le décomposer en problèmes simples donc découper en modules.
reprendre le code de quelqu'un d'autre surtout s'il y a des tonnes de copier-coller avec du code redondant et aucun refactoring.

ce qui quelque part rejoint les avis précédents.
Etant donné que "ce qui se conçoit aisément s'énonce clairement" effectivement nommer ce que l'on fait peut être difficile je ne suis pas étonné par les résultats du graphique


des projets que l'on est pas capable d'expliquer j'ai déjà participé à ce genre de projets..
à la base le projet est mal défini, n'a pas de fonctionnalités pertinentes et c'est pour satisfaire les ambitions d'un DSI

Pour moi les éléments que tu listes font partie du boulot de développeur, en ce qui me concerne j'aime bien certains (conceptualiser, découper en modules...) et il vaut mieux comprendre le métier du client (ça peut être plus ou moins difficile selon ce métier et sa propre expérience). Il ne s'agirait donc pas (pour moi) de tâches difficiles mais importantes.

Quant à reprendre du code pourri, malheureusement ça existe. Le mieux étant de réécrire et virer ce code.

[Cincinnatus]

• Rédiger un cahier des charges
• Estimer le temps nécessaire pour effectuer des tâches
• Expliquer ce qu'on fait (ou ne fait pas)

Il arrive que les fonctionnalités demandées soient vagues ; alors le temps nécesssaire ne peut pas être estimé au début de façon fiable. Après tout, les méthodes agiles ont été créées suite à ce constat.
Expliquer ce que l'on fait à quelqu'un qui n'est pas de la partie est assez compliqué aussi (la compréhension du message dépend de l'émetteur mais aussi du destinataire, qui a peut-être des idées préconçues). Pire : expliquer les développements actuels à quelqu'un qui a fait du développement (pas à temps complet) il y a un certain temps et qui n'a pas suivi les évolutions (évolution hiérarchique) mais croit connaître .

[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.

[el_slapper]

(.../...)
Quant à reprendre du code pourri, malheureusement ça existe. Le mieux étant de réécrire et virer ce code.

souvent, le budget n'est pas en face. Ça nécessite des tests automatiques de partout, et tout le monde ne les a pas. Quand on m'a demandé de le faire, j'ai du d'abord faire tous les tests automatiques avant d'arriver à quelque chose.

[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.

[didier.cabale]

En ce qui vous concerne en tant que développeurs, quelles sont parmi les tâches citées ci-dessus, celles que vous estimez les plus difficiles dans votre métier ?

1. Concevoir une solution: même si ce n'est pas le point qui est dans 100% des cas le plus difficile, c'est *le point crucial*. De la solution envisagée dépendra toute la chaine des problématiques dépendantes: simplicité de mise en œuvre des tests, facilité de maintenance (modification du code, débogage), etc ..
Ce point nécessite à la fois une très bonne connaissance du Framework, des librairies potentielles et du métier en question.
Si vous travaillez sur un gros projet, avec une maintenance active, les *économies résultant de ce point peuvent être considérables*.
2. Travailler avec le code de quelqu'un d'autre : ça, c'est la *bouteille à l'encre* du développement informatique. Si le code précédemment réalisé est mal découpé, pléthorique et /ou inutilement complexe, vous *vivrez l'enfer*, sans pour autant pouvoir modifier structurellement l'existant, sous peine de créer une kyrielle d'effets indésirables, bugs, ..

[Kiloastein]

Estimer le temps nécessaire

[psychadelic]

Je pense qu'il manque un choix:
* Obtenir toutes les informations utiles pour concevoir la solutions technique et/ou réaliser le chiffrage.
De mon expérience, le pb ne concerne pas le client, mais les relais entre le client et l'équipe technique.

La chose la plus difficile que j'ai à faire pratiquement tous les jours, c'est savoir précisément ce qu'il faut faire. LA demande client se résume bien souvent à "j'voudrais un machin qui fait des trucs...combien de temps il te faut ?"...c'est lassant

C'est pour ça que j'ai répondu : " Traiter avec d’autres personnes ".

Parce que pour rédiger un bon cahier des charges on est obligé d'interviewer des gens qui souvent ne savent même pas ce que peut être un raisonnement cartésien; voire qui croient toujours que la terre plate (si, si, c'est du vécu).

Et tout le reste en découle :
- Recenser et documenter les fonctionnalités devient une chasse aux œuf de Paques
- Mettre en œuvre une fonctionnalité avec laquelle on n'est pas d’accord complétement inutile(s)

Quand à estimer le temps, c'est souvent une question piège, mais avec l'expérience (non pas du métier ou de moi même) mais des sournoiseries des "dirigeants" je sais quoi répondre, et par une autre question :

Vous voulez quoi ?
Le temps de réalisation avec ou sans la documentation ? , avec ou sans les tests et les retours utilisateurs ? avec ou sans relecture du code et de ses commentaires par un autre dev ?

Ps on a souvent essayé de me la faire, et ça me fait tout sauf rire : 15 jours hommes c'est pas 2 semaines, mais 3 semaines, sinon faut payer en heures sup et salaire au double pendant les week-end.

Quand à relire le code d'un autre, ça dépends surtout de la qualité d'écriture du premier codeur, parfois c'est un plaisir, mais c'est rare...

[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.