34 votes

Comment dire à quelqu'un que ses méthodologies de programmation sont obsolètes?

Je suis certain que je ne suis pas la première personne à exécuter dans ce scénario, alors j'ai pensé jeter là-bas et voir ce que l'on ruche a à dire. Comme un avertissement, la personne sur laquelle je base cette question n'est pas quelqu'un que je travaille actuellement avec.

Ce qui est une preuve de tact, mais efficace, une façon de montrer à quelqu'un que certains de leurs "vieux chien" habitudes ont tombé hors de la faveur, ou ont été remplacés par des plus efficace et gérable solutions? La nature dynamique de développement tend à soutenir un LOT de compatibilité ascendante, quand il s'agit de méthodes, de sorte que "ça ne fonctionne plus" est rarement un honnête option, mais souvent ces vieilles habitudes ont été remplacées. Par exemple..

  • Toujours écrire des wrappers pour cadre les méthodes, car ils vont changer et briser votre code. N'appelez jamais quoi que ce soit dans le cadre directement
  • Ne pas utiliser les propriétés, parce que tout ce qui pourrait exécuter du code doit être dans une méthode ou une fonction. C'est ce qu'ils sont pour.
  • Ne jamais utiliser des bibliothèques tierces, car ils vous briser

La liste est longue, et je suis sûr que les gens d'ici ont une impression de ce que je reçois au. Beaucoup de ces ne sont pas les même méthodes, en soi, en tant qu'ils sont automatique des réactions à la perspective de changement.

Comment faites-vous (et, par extension, comment puis-je) faire face à de tels scénarios et de maintenir une bonne relation de travail avec ces personnes?

EDIT:

J'ai reçu quelques commentaires sur la nature des exemples. Ces exemples visent à montrer l'inflexible état d'esprit, plutôt que d'illustrer une faute avec n'importe quel habit.

36voto

Brian Points 14040

Le programmeur pragmatique mentionne qu'il vaut également la peine de planifier judicieusement votre requête. L'exemple classique consiste à attendre qu'une crise se produise avant de proposer la solution, par exemple en suggérant le contrôle de la source après la suppression accidentelle de tout le code. La prévention peut être moins chère que la guérison, mais la guérison est beaucoup plus facile à justifier.

16voto

pj4533 Points 606

Je trouve cela dépend vraiment de la personnalité de la personne en question. Par exemple, si il/elle est ouverte à de nouvelles idées, mais n'a pas été démontré que les possibilités, peut-être une conversation diplomatique fera l'affaire, indiquant la manière dont il va l'aider à changer. Fondamentalement, toujours en soulignant les aspects positifs.

Toutefois, si la personne est un de ces "je n'aime de cette façon", et de ne pas ouvrir de changement c'est beaucoup plus difficile. Dans ces cas, j'ai l'habitude de me demander, "je veux changer, juste pour changer le saké, ou est-il une bonne raison à cela?" Si j'ai une bonne raison, j'ai recruter d'autres personnes et de suggérer le changement dans un contexte de groupe.

Si ils continuent à tenir le coup, et j'ai plusieurs autres derrière moi, et je SAIS que c'est un changement nécessaire, alors, je vais le porter à mon patron pour plus d'action directe.

9voto

Si. Points 10543

Montrez-leur une meilleure façon, en expliquant pourquoi vous pensez que c'est mieux.

Sauf si vous êtes en mesure d'imposer une méthodologie, ou si vous pouvez obtenir l'adhésion de la direction, essayer de forcer quelqu'un à vous laisser frustré et irrité. Vous devez juste accepter cela et aller de l'avant.

Vous pouvez aussi dire que choisir vos batailles :)

8voto

T.E.D. Points 26829

J'ai été codage depuis la fin des années 70. Ce que vous décrivez n'est pas un vieux nous avons utilisé la méthodologie de retour dans la journée. Il est hyper-une programmation défensive. Je l'avais presque inquiétez que votre développeur était battu comme un enfant. :-)

Otoh, que, d'une certaine quantité de qui peut être sensible. Par exemple, si vous utilisez une bibliothèque qui n'est pas open source, il est presque une garantie que votre fournisseur vous sortir de l'entreprise ou sinon, arrêter de le soutenir en un jour. À moins que vous écrivez jetables code, de faire une certaine quantité de planification pour avoir à le remplacer à l'avance est simplement responsable.

7voto

lambdabunny Points 108

Dans le passé, j'ai traité ce par la présentation de nouvelles informations, puis en essayant de les amener à penser que c'était leur idée de faire le changement dans la première place. Habituellement, quand ils pensent qu'ils ont eu l'idée, ils sont beaucoup plus susceptibles de l'utiliser. :) C'est un peu manipulatrice, mais elle est préférable à un conflit ouvert et il évite de lui faire sentir hors-du-touch. Il permet aussi de les faire réfléchir sur leurs pratiques actuelles dans un non-accusatrice manière.

Cela fonctionne bien si vous êtes plus jeune que la personne en question (généralement le cas). Présenter livre/page web/etc sur le thème de l'information; de dire que vous n'êtes pas sûr que vous le comprenez et êtes à la recherche pour obtenir de l'aide de quelqu'un d'aussi expérimenté qu'à voir ce qu'il en est. Expliquer les concepts comme vous le comprenez; demandez-leur quelque chose de simple à propos de ce qu'ils devraient être en mesure de répondre. Essayez d'orienter la conversation vers les applications pratiques, leur demander des choses comme "pensez-vous un exemple de ceci serait quelque chose comme....". Souvent, ils vont avoir l'idée de "Oh, nous pourrions utiliser qu'ici!" et puis se changer eux-mêmes.

Les gens semblent beaucoup plus ouverts au changement si vous les laisser croire qu'ils proviennent eux-mêmes le changement. :)

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X