S'agit-il de signes d'un mauvais développeur? [fermé]

J'avais l'habitude de reprocher aux clients de modifier le cahier des charges en raison de la pourriture du code, sans me rendre compte que les modèles commerciaux changeaient et qu'il était de mon devoir de le développer de manière adaptable. Je vois maintenant cela comme un signe d'un mauvais développeur (j'ai changé!).

Mais maintenant, je vois d’autres "problèmes" en moi. Quelques fois récemment, je me suis retrouvé à dire «c’est comme essayer d’insérer une cheville carrée dans un trou rond», et je me trouve également à blâmer l’indécision de la clientèle pour un projet qui ne progresse pas.

Y a-t-il des signes que je devrais chercher où je devrais changer d'attitude? Le client a-t-il toujours raison ou suis-je parfois justifié de me sentir frustré?

Je ne dirais pas que vous êtes un mauvais développeur. Être conscient des problèmes vous dépasse déjà.

Les exigences changent. C'est une donnée. Un bon développeur doit en tenir compte. De nombreuses techniques de programmation modernes aident à y faire face.

Rester fidèle aux spécifications d'origine n'est pas réaliste. Il n’est pas réaliste non plus de modifier constamment les exigences.

Le client n'a certainement pas toujours raison. C’est «correct» plus souvent que nous le souhaitons (par exemple, essayez de l’accommoder s’il n’est pas totalement inactif). Mais quand vous le voyez conduire le projet dans la mauvaise direction, essayez de défendre les points que vous jugez corrects.

Il n'y a pas de règles strictes sur ces choses, et même les développeurs bons et expérimentés n'ont pas atteint le "Zen" parfait. La seule mauvaise approche n’est pas d’essayer de les améliorer.

Il y a des cas où c'est le client. Mais c'est ton problème aussi

Il y a des cas où c'est le développeur, et il y a des cas, c'est le client. Mais, généralement, ils sont tous les deux votre problème, donc une attitude de blâmer soi-même a tendance à être plus de succès, car elle pèche du côté de la résolution de problèmes au lieu de pointer du doigt sans défense. Par conséquent, vous le trouverez souvent chez des développeurs plus expérimentés.

Une attitude encore meilleure consiste à regarder IMHO sans blâmer: «c’est la faute du client, j’ai un code moche, parce qu’il change toujours les exigences», il devient alors «ce client est en train de déterminer ce qu’il veut, le feedback, le prototypage rapide et la flexibilité sont plus plus important que la complétude, la robustesse et la rapidité ".

Une sorte d'esprit zen: ne le jugez pas, voyez le comme il est.

Premièrement, un client ne sait pas ce qu'il veut avant de l'avoir vu. Cela fait partie de l'attrait des petites itérations du paradigme Agile avec une forte implication des clients. Deuxièmement, ne vous attendez pas à ce qu'un produit soit "complet" lorsque votre code est complet.

Microsoft utilise un produit appelé «Watson» (le message d’envoi que vous recevez lorsque Windows s’agrandit) afin de tracer les problèmes directement vers un client. La traçabilité est un bon moyen de retracer les problèmes jusqu'aux utilisateurs qui les rencontrent. Vous pouvez obtenir la traçabilité en demandant. Ou, si vous avez les ressources, intégrez la fonctionnalité au (x) produit (s). L'essentiel est de suivre les problèmes / améliorations afin qu'ils puissent être résolus.

Enfin, le client peut être instable. Dans de tels cas, j'essaie de me concentrer sur le secret de l' iceberg .

Changer les exigences est un fait difficile de la vie; mais la pourriture du code n'est pas causée par cela.

La pourriture du code se produit lorsqu'il y a des parties de votre code que vous n'exercez pas fréquemment; Ainsi, lorsque vous apportez des modifications qui "ne devraient affecter rien d'autre", vous pouvez introduire des bogues. En d'autres termes, un code qui ne voit pas la lumière du jour se décomposer lentement et vous ne pouvez pas dire quand il a cessé de fonctionner.

Oui, c'est de votre faute et non de votre utilisateur.

La vraie solution? tester tout votre code fréquemment. Bien entendu, le meilleur moyen est de disposer de tests automatisés avec une bonne couverture.

L'indécision du client peut être un gros problème et si vous n'êtes pas responsable de la gestion de la relation client, il peut être très difficile de le gérer. Vous pouvez parler à la personne qui traite avec le client et expliquer sereinement que des progrès ne peuvent pas être accomplis tant que le client n'a pas pris de décision. Si vous êtes responsable de la relation client, vous devez lui dire qu'il doit prendre une décision avant que le projet puisse continuer. Votre attitude n’a peut-être pas besoin d’une refonte, mais d’une minute de méditation pour vous calmer. ;)

Javier souligne que les exigences changeantes sont un fait difficile. Je suis moi aussi frustré par ces situations car trop souvent, je me retrouve à travailler sur un produit sur lequel le développeur doit prendre des décisions. Auparavant, mon opinion était "Pourquoi la direction ne peut-elle pas comprendre cela avec le client?", Ou "Pourquoi avons-nous commencé ce projet si le client ne sait pas ce qu'il voulait?", "C'est tellement maux de tête quand ils changent tellement tard dans le développement ".

Fait simple: cela se produira toujours , pas seulement en programmation / développement de logiciels, mais dans tous les domaines de la vie. Le monde serait tout simplement un endroit très ennuyeux et très différent si les gens ne changeaient jamais d’avis, ne s’adaptaient jamais, ne s'adressaient jamais au changement. Les gens ont tendance à regarder ce qu'on leur donne et à l'améliorer. Ne faites-vous pas la même chose avec votre code? Si j'ai un bloc de code qui ne me satisfait pas (c'est inefficace, compliqué), je vais l'améliorer. (Le système d'exploitation se plaint-il de moi? ... parfois, si j'utilise un certain système d'exploitation non nommé, mais généralement pas)

En tant que programmeurs, nous devons saisir les occasions d’améliorer des choses et ne pas nous laisser déprimer ou les agacer. Saisissez l’occasion de parler aux gens, d’améliorer votre style, d’améliorer votre éthique de travail, d’aborder les choses avec ouverture d’esprit, de vous pousser à être meilleur que ce que vous étiez hier. Avancez dans votre carrière et ne vous installez pas trop facilement.

Je comprends que tout le monde ne sera pas d'accord avec cette réponse mais je pense qu'il est important que les réponses à cette question couvrent une perspective plus large.

Lorsque vous interagissez avec un client, vous ne programmez pas; vous apprenez et enseignez.

Tenez les clients informés et informez-les du processus. Le changement va arriver. Dites-leur que vous allez essayer de les mettre en œuvre, mais cela coûtera plus cher. Laissez-les décider.

N'entrez pas dans les détails techniques même lorsque la question posée est de nature technique. Vous êtes tenté parce que vous vous sentirez un peu sur la défensive et voudrez relever un défi / obtenir votre geek-on. Ne le fais pas; ils ne se soucient pas des détails et cesseront d'écouter après 45 secondes.

Si vous ne le leur dites pas à l'avance, ne vous attendez pas à ce qu'ils connaissent les normes de l'industrie, les meilleures pratiques ou toute autre excuse pour faire ce que vous faites. Je déteste quand je ne vois pas de frais jusqu'à la fin, mais que le vendeur me dise que c'est la norme dans l'industrie. Je ne devrais pas m'attendre à le savoir. Ma réponse est: "Est-ce que ça me fait sentir comme un idiot aussi un standard?"

Lorsque vous êtes avec un client, faites-lui plus attention que quiconque ou quoi que ce soit d'autre dans la pièce. Les chiens domestiqués sont des génies à cela; surtout si vous avez de la nourriture.

C'est une mauvaise gestion des exigences ou une mauvaise analyse. Votre analyste métier (si vous en avez un) ou celui qui répond aux exigences doit passer avec le client et essayer de répondre à toutes les exigences, même celles auxquelles le client ne pense pas. Les clients ne savent généralement pas tout ce qu'ils veulent, un excellent analyste commercial les aidera à tout comprendre.

C’est la raison pour laquelle vous devez toujours obtenir la configuration d’un document d’exigence de gestion et la signer avant qu’une application dépasse la phase de prototypage / recherche.

Or, l'idée selon laquelle ce document est en réalité définitif est erronée, mais cela devrait vous aider à avoir une meilleure idée de ce que le client souhaite réellement. Et tant que vous écrivez votre code dans un souci de maintenabilité, vous pouvez limiter vos problèmes au minimum.

Et si vous avez besoin d'une excuse pour vous en remettre, vous pouvez imputer tout retard à la BRD, à la signature du client, à l'exclusion de telle ou telle fonctionnalité, etc.

(Bien sûr, ce n'est qu'une excuse au cas où vous en auriez besoin. Vous devriez toujours prévoir de changer quelque chose )

Dans la citation d'Emerson, "une consistance idiote est le hobgoblin des petits esprits ..." le mot le plus souvent négligé est idiot . La cohérence n’est pas négociable dans certains contextes, mais elle se substitue souvent à la pensée critique et à l’analyse.

D'une part, de nombreux modèles de développement sont conçus spécifiquement pour aider l'environnement que vous décrivez. Donc, si vous vous retrouvez dans l'obligation de violer votre modèle, soit vous ne l'implémentez pas correctement, soit vous avez le mauvais modèle.

Par contre, si vous avez une justification bien argumentée et justifiable de la violation de vos règles et que vous pouvez montrer que votre méthode malpropre produit un code plus propre et plus maintenable, vous ne devez pas avoir peur de prendre la bonne voie.