Comment expliquer pourquoi les choix de conception sont bons? [fermé]

Comme je suis devenu un meilleur développeur, je trouve qu'une grande partie de mes compétences en conception provient plus de l'intuition que de l'analyse mécanique. C'est bien. Cela me permet de lire le code et de le ressentir plus rapidement. Cela me permet de traduire des conceptions entre langues et abstractions beaucoup plus facilement. Et cela me permet de faire les choses plus rapidement.

L'inconvénient est que j'ai du mal à expliquer aux coéquipiers (et pire, à la direction) pourquoi un design particulier est avantageux; en particulier les coéquipiers qui sont en retard sur les meilleures pratiques. "Cette conception est plus testable!" ou "Vous devriez privilégier la composition plutôt que l'héritage." aller directement au-dessus de leurs têtes, et conduire dans le trou du lapin de moi en essayant d'indiquer tout le monde à la dernière décennie d'avancées en génie logiciel.

Je m'améliorerai bien sûr avec la pratique, mais en attendant, cela implique beaucoup de temps perdu et / ou une mauvaise conception (ce qui entraînera du temps perdu à le réparer plus tard). Comment puis-je mieux expliquer pourquoi un certain design est supérieur, lorsque les avantages ne sont pas complètement évidents pour le public?

Cela peut ne pas répondre directement à votre question, mais cela pourrait vous conduire dans une direction intéressante.

Je pense que ce que vous devez faire est plus lié à leur vente à l'idée qu'à leur explication . Les ventes consistent à comprendre quel est le problème du client et à leur montrer comment votre produit (ou méthode de développement, peu importe) leur sera bénéfique . Chaque personne a des besoins différents, donc ces choses qui profitent à une personne et les excitent peuvent très bien laisser une autre personne froide.

Pour votre PDG, le délai de mise sur le marché peut être la clé, pour votre gestionnaire, il peut s'agir de calendriers plus prévisibles, pour vos collègues de programmation, il peut s'agir d'un codage plus rapide (ou de tests / documentation / débogage / plus simples), et pour les clients de votre entreprise, il pourrait être ... ?

Les ventes ne se font pas de manière automatique - vous devez faire un effort concerté pour comprendre le point de vue de l' autre personne , puis trouver comment mapper vos idées dans leur Happy Place ™. Une fois qu'ils savent comment ils bénéficieront personnellement de cette nouvelle chose, ils demandent souvent: «Combien cela coûtera-t-il et dans combien de temps pourrons-nous le faire? Une fois que vous avez entendu ces mots magiques, vous savez que vous avez bien fait votre travail de vente.

Je n'ai pas vraiment de solution à votre question, mais il y a quelque temps, j'ai fait face exactement au même dilemme et cherchais à répondre exactement à cette même question.

Je me retrouverais d'un côté de l'argument et quelqu'un d'autre de l'autre côté et même si chaque fibre de mon corps me disait que le bon design est X, je ne pouvais pas le soutenir en utilisant des mots.

Le pire, c'est que parfois je concède le point et laisse l'autre personne l'implémenter à sa façon pour que son design explose dans mon visage et je pense alors: "Ouais, c'est un parfait exemple de pourquoi je ne voulais pas de le faire de cette façon. Si seulement je pouvais leur montrer ce code à l'époque. "

Eh bien, je n'ai jamais vraiment trouvé la réponse, mais il y a quelques jours, alors que je parcourais le développement logiciel Lean: une boîte à outils agile, Je suis tombé sur quelque chose d'intéressant qui pourrait suggérer que la réponse n'existe pas réellement. Une section du livre parlait des dirigeants dans d'autres domaines, en particulier dans les unités d'intervention d'urgence et de la façon dont ces dirigeants prenaient des décisions. Lorsqu'il y a un incendie ou que quelqu'un vous tire dessus, ces dirigeants ne s'assoient jamais et ne discutent pas du pour / du contre avec leurs coéquipiers. Au lieu de cela, ils utilisent l'intuition, qui a été développée grâce à la formation et à l'expérience pour les aider à prendre des décisions. La même chose s'applique à notre profession: comment pouvez-vous prendre une décision parfaitement logique face à une tonne d'inconnues et de variabilité si courantes dans le développement de logiciels? Les auteurs soutiennent qu'au lieu d'essayer de justifier toutes les décisions, les développeurs devraient être encouragés à former et à améliorer leur instinct pour finalement "savoir" quoi faire.

La seule façon que j'ai trouvée pour dépasser ces arguments est de construire une expérience éprouvée de mon travail. Pour montrer à la direction et aux autres membres de mon équipe que les décisions de conception que je prends dans mon code se traduisent par un code plus facile à maintenir, à étendre et plus fiable. Vous faites cela à plusieurs reprises et les gens vous remarqueront. À ce stade, votre opinion, qui pourrait ne se baser que sur votre instinct, aura un poids beaucoup plus élevé qu'aujourd'hui. Cette stratégie a fonctionné avec 90% + de mon équipe, y compris mon patron. Malheureusement, vous pourriez trouver un ou deux gars qui sont complètement têtus et refuseront de voir quoi que ce soit à votre façon. À ce stade, vous avez peu d'options:

1. Vous pouvez essayer de tirer le grade (j'ai fini par aller voir mon patron et demander un grade parce que j'étais tellement fatigué de ces arguments sans issue)
2. Vous pouvez essayer de faire pression pour que la majorité de l'équipe vous soutienne.
3. Si le projet peut se permettre (c.-à-d. Pas trop de perte de productivité), ce qui à votre avis est une mauvaise décision, laissez l'autre personne gagner l'argument. Deux choses se produiront:
   • Dans certains cas (en espérant une très petite portion), votre intuition sera fausse et vous finirez par apprendre quelque chose. Bien pour vous.
   • Dans la plupart des cas (encore une fois ... espérons-le), vous ET la personne qui préconisiez une "mauvaise" conception comprendront exactement pourquoi elle est mauvaise; après tout, le recul est toujours de 20/20. J'espère que ce sera une leçon pour cette personne que vous savez peut-être de quoi vous parlez et que la prochaine fois, elle réfléchira à deux fois en plaidant.

Eh bien, cette réponse n'est pas vraiment aussi spécifique à la programmation que vous ne le pensez. Vous devez le ramener à des choses qu'ils comprennent.

Si c'est quelque chose comme la composition plutôt que l'héritage, vous n'avez probablement qu'à dire qu'actuellement peut-être 90% des développeurs considéreraient cela comme une meilleure pratique (une supposition sauvage, basée en partie sur le fait que 100% des développeurs sont d'accord sur presque rien), et vous d'accord et serait heureux d'expliquer pourquoi.

J'essaie d'être aussi honnête que possible sur ce qui est controversé et sur le pourcentage de développeurs qui seraient d'accord avec moi.

Cela fonctionne généralement mieux avec la direction qu'avec les développeurs, qui vous feront probablement descendre dans le lapin en expliquant si vous préconisez vraiment un bon design et comment le savez-vous. Il y a quelque chose de louable à cela, mais cela signifie que vous devez y consacrer beaucoup de temps. À moins qu'ils ne vous fassent suffisamment confiance pour vous croire sur parole, du moins provisoirement. Du bon côté, ils peuvent vous convaincre que vous avez tort, ce qui bat la réalité froide et dure qui vous convainc sur la route.

Pour des choses comme un design plus testable, s'ils ne conviennent pas qu'il est plus testable, c'est à peu près la même chose que le premier exemple. S'ils ne conviennent pas qu'il est souhaitable d'être plus testable, alors vous devez le ramener à des choses qu'ils comprennent. Il s'agit très probablement de la gestion, et vous pouvez parler de coûts de développement inférieurs à long terme, de moins d'AQ, de processus plus prévisibles (car la durée des cycles d'AQ répétés est difficile à prévoir), etc.

Je pense qu'une partie du problème est que vous sous-estimez à quel point il est difficile d'amener une équipe à s'entendre avec vous sur quelque chose de controversé, même si vous avez raison (et bien sûr vous ne l'êtes peut-être pas). La programmation est en partie un exercice sociologique et vous devrez peut-être prévoir du temps pour réellement descendre certains de ces trous de lapin, car un excellent design que personne ne comprend ou ne soutient n'est rarement un excellent design dans la pratique. Alors ne pensez pas à ce temps comme perdu, pensez-y comme une partie nécessaire de la réussite de votre projet. Même si ce serait tellement plus facile si vous pouviez le sauter d'une manière ou d'une autre.

Être la seule voix du changement n'est jamais chose facile. Le premier défi consiste généralement à amener d'autres personnes à bord avec vous (j'espère qu'il y en a dans votre entreprise qui sont plus ouverts d'esprit que les autres). Si vous pouvez attirer l'attention de quelques autres développeurs / gestionnaires seniors pour rejoindre votre croisade, ces voix combinées seront de plus en plus difficiles à ignorer pour les autres.

Je trouve un bon moyen d'expliquer aux gens en fournissant des exemples concrets d'erreurs passées commises dans des projets auxquels ils ont activement participé (par exemple, "Avez-vous déjà essayé de déboguer cette chose? C'est comme ça depuis des années et personne ne sait comment répare le.."). Mieux encore, en appliquant ces «nouvelles» idées et principes de conception à un petit projet / essai et en montrant à quel point il a réussi.

Selon l'attitude des autres membres de votre entreprise, le changement peut survenir rapidement, ou ce peut être comme essayer de nager dans la mélasse. Certains managers sont complètement inamovibles à moins d'avoir des statistiques / preuves solides devant eux, tandis que d'autres sont très désireux de suivre les dernières réflexions.

Vous devrez peut-être essayer différentes tactiques en fonction de la personne avec laquelle vous traitez; Proposer d'économiser de l'argent / du temps / des efforts et d'améliorer la qualité est un bon moyen d'attirer l'attention des gestionnaires non techniques; et la promesse de tests automatisés faciles fait appel à un grand nombre de développeurs qui ne supportent généralement pas de passer des jours à parcourir les mêmes feuilles de calcul de test à plusieurs reprises.

Dépend du public! En tant que développeurs, nous avons développé une intuition pour le bon et le mauvais code, et utilisons des termes émotionnels vagues comme «odeur de code», «code laid», «belle solution». Cela ne fonctionne que lorsque vous communiquez avec d'autres développeurs avec le même état d'esprit. Essayez d'expliquer à votre PDG non technique que vous devez investir x heures-homme pour rendre un code "plus beau", vous échouerez très probablement de façon spectaculaire.

Vous devez être en mesure de faire valoir que toute amélioration de conception donnée

• économiser de l'argent pour l'entreprise
• faire de l'argent pour l'entreprise

Par exemple, quel est le cas pour adhérer au principe de responsabilité unique? Si chaque classe a une seule responsabilité, il est beaucoup plus facile de localiser et de corriger les bogues, et il est plus facile d'ajouter des fonctionnalités et des améliorations. Moins de temps pour corriger les bugs et ajouter des fonctionnalités = argent économisé.