Est-ce que le faire à votre façon a déjà aidé ? Y a-t-il même eu une fois où vous avez utilisé l'indirect, l'injection et les interfaces supplémentaires, et où il y a eu une embardée de dernière minute, et où tout s'est déroulé en douceur et en beauté, sans jurer ? Même à un poste précédent, si vous n'avez jamais été capable de faire engager ce code ici ?

je vais supposer qu'il y en a eu. Entraînez-vous à raconter cette histoire. C'est spécifique et réel. Ce n'est pas “x peut arriver” ou “y peut changer” mais, “Il était une fois, je l'ai fait de cette façon et voici comment ça s'est passé.” Les managers (je parle en tant que tel) se méfient des dépenses d'argent (et croyez-moi, écrire un code plus compliqué que les autres ne peuvent pas comprendre lors d'un premier passage, c'est dépenser de l'argent) pour ce qui pourrait arriver. Ils ne veulent pas financer des spéculations qui ne sont peut-être basées que sur “l'apprentissage du livre” et la dernière mode selon Internet. Mais quand vous vous basez sur votre expérience ? C'est une situation totalement différente.

Je ne suis pas un grand fan des usines, des fournisseurs, des injecteurs et autres. Ils sont généralement configurés pour des choses qui n'arriveront jamais vraiment (passer de MS SQL à Oracle) ou ont un petit impact quand ils le font (changer le dossier où les fichiers sont enregistrés). Ils ont leur place dans des arrangements très volatiles, dans lesquels vous semblez être. Vous devez donc montrer qu'ils ont cette place. Vous semblez être dans une position de “C'est la façon normale de faire les choses, et j'ai besoin d'une raison pour ne pas le faire”. Votre manager vous dit : “Ce n'est pas normal, la normalité est simple et directe. Donnez-moi une bonne raison de mettre une autre couche en travers de mon chemin”. Travaillez sur cette raison. Travaillez sur une réussite passée, vraiment réussie, où cette couche supplémentaire a permis d'économiser des jours ou des semaines de travail. Justifiez votre ingénierie, sinon c'est vraiment de la sur-ingénierie.

Cette citation tirée d'un de vos commentaires me trouble :

En tant qu'ingénieur en logiciel, il devient pour moi une seconde nature de “faire ce qui n'est peut-être pas une bonne raison à la surface”, comme d'interfacer les inconnues que j'ai mentionnées. Le fait de devoir constamment être sur le point de m'expliquer sur des sujets très techniques (et parfois très tendus) m'épuise.

J'ai vu plusieurs répétitions du cycle de vie suivant :

• Une équipe de programmeurs qualifiés propose une approche différente de la programmation.
• On la considère pendant quelques années, jusqu'à une décennie, comme quelque chose qui devrait être utilisé universellement, malgré tous ses inconvénients et ses limites. Pendant cette phase, il suffit de dire “j'applique la méthodologie X” sans analyser si X est un bénéfice net.
• Elle se démode, mais ses idées les plus utiles restent dans la boîte à outils du développement logiciel, pour être retirées et utilisées chaque fois qu'elles apportent des bénéfices nets.

À mon avis, tant la DRT que les modèles de conception tournent autour de la séparation entre les deuxième et troisième étapes du cycle de vie de la méthodologie de programmation. Je suis sûr que le TDD et de nombreux modèles de conception auront une longue et précieuse vie dans la boîte à outils, à utiliser chaque fois qu'ils aident plus qu'ils ne nuisent. Je pense aussi qu'ils sont peut-être encore trop utilisés, par habitude plutôt que par réflexion délibérée.

Vous ne devriez jamais appliquer un design pattern parce que c'est une seconde nature, ou avoir du mal à en expliquer l'utilisation. Au contraire, avant d'appliquer un modèle, réfléchissez à ses coûts et à ses avantages dans cette situation particulière. Si ses avantages l'emportent vraiment sur ses coûts, vous devez savoir exactement pourquoi, de sorte que le fait d'expliquer le compromis ne doit pas vous épuiser. Si ses avantages ne l'emportent pas sur ses coûts, ne l'utilisez pas. Là encore, votre propre réflexion sur votre dessin ou modèle devrait vous préparer à répondre si on vous demande pourquoi vous n'avez pas utilisé un modèle éventuellement applicable.

Rappelez-vous que vous devez penser à ces compromis en termes de maintenabilité globale du programme, et pas seulement en termes de rapidité de fonctionnement de votre pièce. Trop d'indirect peut rendre plus difficile pour les futurs programmeurs de découvrir ce qui se passe réellement.

Suis-je la seule personne perplexe quant à la façon dont, sur le lieu de travail, on met autant l'accent sur les pratiques de codage plutôt que sur le conflit réel sur le lieu de travail ? Je vais donc adopter une approche différente.

Voici les aspects généralisés de votre problème tel que je le vois :

1. Vous êtes dans un domaine de compétence qui nécessite une collaboration
2. Il n'existe pas de procédures documentées régissant la manière dont ce travail de collaboration doit être effectué
3. Il y a un désaccord sur la façon dont ce travail de collaboration devrait être effectué
4. L'un de ceux qui ne sont pas d'accord est votre responsable Il me semble que votre groupe doit se réunir et se mettre d'accord sur les normes et les pratiques que vous allez adopter et les adopter globalement, pour le meilleur ou pour le pire. Parce que rien n'est pire pour un produit qu'une équipe qui est constamment en désaccord, et rien n'est pire pour votre relation avec votre employeur que de ressasser constamment les arguments avec lui.

Essayez donc de réunir votre équipe pour vous mettre d'accord sur certaines normes, et utilisez cette réunion pour plaider votre cause pour les pratiques que vous utilisez. Si vous les obtenez, génial ! Sinon, qu'il en soit ainsi. Votre travail n'est pas d'écrire un beau code. Votre travail consiste à livrer un produit fini. Si votre employeur (incarné par votre manager) et une pluralité de votre groupe insiste pour que vous le fassiez d'une certaine manière, alors qui êtes-vous pour le contredire ?

Cependant, il semble que la plupart de votre équipe soit d'accord avec vous, il devrait donc devenir assez évident au cours de ces discussions que votre manager est l'intrus. Si cette personne refuse toujours de se rallier au consensus de l'équipe, alors il s'agit d'un dysfonctionnement que nous ne pouvons pas vous aider à résoudre (à part vous recommander de passer dans une autre équipe).

Malheureusement, c'est votre manager, et vous n'écrivez pas le code de la manière dont il veut que vous l'écriviez. S'il est directeur, il ne prévoit peut-être pas de quitter l'entreprise dans deux ou trois ans, comme la plupart des développeurs le prévoient. Vous écrivez un code qui sera plus difficile à réparer pour vos remplaçants, c'est pourquoi il est dur avec vous pour l'avoir construit de cette façon.

Si je suis autorisé à faire une hypothèse ici, sachant très bien que je pourrais être loin du compte, pourquoi écrivez-vous tout cela ? Je serais plutôt surpris s'il s'agissait de quelque chose de plus que des demandes de LPP. Au cours de mes dix années de développement, un véritable modèle de stratégie/usine n'a été nécessaire que trois fois, dont deux fois dans le cadre d'emplois :

• Dans une application qui affichait des informations sur des produits, où certains de ces produits étaient essentiellement un groupe de petits produits dans une boîte, nous avons utilisé une stratégie pour déterminer quelle usine était nécessaire pour transformer les informations sur le produit (demandées via une clé) en une vue. Pas très glorieux, mais cela a fait l'affaire. Si j'ai le droit d'égaler votre humble remarque sur les insectes, je dois dire que pendant toute la durée de mon mandat, nous n'avons jamais eu un seul insecte ! (un a été signalé après mon départ mais il s'est avéré être une erreur de l'utilisateur :)).
• Dans une application qui montrait aux utilisateurs où aller pour un cours qu'ils suivaient, nous avons utilisé une usine et une abstraction pour permettre un passage rapide entre une API Bing Maps et une API Google Maps. En effet, les deux avaient un rapport coût/bénéfice et l'entreprise ne progressait pas dans le choix de l'API à utiliser. Finalement, nous avons appris de notre bureau à domicile que nous avions déjà une clé API pour l'un d'entre eux et que nous pouvions pivoter à la dernière seconde vers cette API, juste avant le lancement.

Et un troisième est un projet auquel je m'intéresse, qui fait de la surveillance de serveurs pour les serveurs Windows :

• j'utilise une interface pour la sortie des données de surveillance et pour les moniteurs eux-mêmes. Les moniteurs sont hautement configurables (en fonction des paramètres de l'application). L'implémentation de la sortie varie selon que je teste ou non un nouveau moniteur ou que je me rends au déploiement, de sorte que l'interface IOutput a ConsoleOutput et SqlOutput comme implémentations qui peuvent varier.

Notez que mon projet personnel fait immédiatement un usage plus fréquent des modèles et inversion de contrôle (IoC) que mes projets de travail.

Si je peux vous donner un conseil après tout cela, qu'il en soit ainsi : Un travail est un travail, et si vous voulez faire les choses à votre façon, essayez de trouver un juste milieu. Les techniciens ne restent généralement pas longtemps sur place et cela ne vaut pas la peine de se battre avec la direction sur la façon de faire. Faites en sorte que vos projets personnels à domicile soient une pile de modèles autant que vous le souhaitez.

Solution facile : Solution difficile : en cas de désaccord, la **moitié de la faute vous incombe.

Prenez un congé, étudiez le fonctionnement des autres équipes, trouvez où se situe le malaxisme d'impédance entre vous et l'autre partie. Parlez-leur en personne, tôt et souvent. Si vous le faites bien, vous apprendrez tous deux à comprendre les préoccupations et les références de l'autre partie, et ils apprendront à vous apprécier pour votre contribution, votre expérience et vos opinions tranchées. Voici quelques points à considérer :

• produit de qualité vs. délai de mise sur le marché
• bon produit vs. bon code
• code intelligent vs. code explicite
• culture d'entreprise descendante vs. culture d'ingénierie ascendante

Si cela ne fonctionne pas bien, envisagez un autre rôle dans l'équipe, une autre équipe dans l'entreprise ou, enfin, une autre entreprise.

Si vous faites face à ces gens de front, vous rencontrerez la plus grande résistance, celle des sauterelles. J'ai été le plus efficace pour apporter des changements lorsque j'ai stratégiquement frappé les bons points de pression. Cela demande beaucoup de patience et beaucoup de concessions. Je dois d'abord adapter à eux avant d'appliquer une pression sur les points faibles.

Videz votre esprit, soyez sans forme. Sans forme, comme l'eau. Si vous mettez de l'eau dans une tasse, elle devient la tasse. … Maintenant, l'eau peut couler ou elle peut s'écraser. - Bruce Lee

Écoutez-les et posez beaucoup de questions. **Écouter quelqu'un avec sincérité lui enlève le désir de résister. Comprendre ce qui motive leur réflexion puis parler leur langage. Comme vos convictions sont axiales, il est probable qu'en ce moment, il reflète votre entêtement, votre mépris et votre frustration. Puisque vous êtes subordonné, c'est à lui de choisir de ne pas se joindre à votre longueur d'onde et c'est à vous de construire le pont.

En le voyant, vous vous verrez. Comme vous le traitez, vous vous traiterez vous-même. Lorsque vous penserez à lui, vous penserez à vous. N'oubliez jamais cela, car en lui vous vous retrouverez ou vous vous perdrez. - Helen Schucman

Un maître de Wing Chun Kung Fu attire son adversaire et le rapproche avant de chercher et attaquer la ligne centrale où il est le plus vulnérable. Ne discutez pas de détails juste pour gagner, trouvez la ligne centrale du problème et concentrez la pression à cet endroit.

J'ai affaire quotidiennement à des ingénieurs qui refusent de se réoutiller ou d'apprendre de nouveaux paradigmes de programmation et on m'a donné une forme d'argument du type “je suis là depuis les cartes de pointage” plus de fois que je ne peux en compter. J'estime que j'ai perdu 80% des batailles, mais ces 20%…woh…j'ai fait en sorte que de grands changements se produisent. Je peux sembler vague, mais faites une recherche sur google sur certains de ces mots-clés et vous comprendrez ce que je veux dire.

Aussi, essayez de vous lancer dans un nouveau projet d'écureuil que vous pourrez faire à votre façon. Si cela fonctionne vraiment et permet de gagner du temps ou de l'argent, les gens se rallieront à votre façon de penser. S'il n'y a pas de nouveau projet, créez-en un pendant votre temps libre pour résoudre un problème que l'entreprise a rencontré et que personne n'est intéressé à prendre le temps de résoudre.

Que dois-je faire ?

En génie logiciel, la qualité de l'écriture (ou de la surécriture) du code est toujours sujette à un certain niveau d'interprétation (opinion). Pour moi, vous prenez les mesures que je prendrais à votre place, mais en fin de compte, c'est votre manager qui a besoin de voir la lumière….continuez à lui montrer.

Je continuerais, même si cela peut être douloureux, à faire exactement ce que vous faites et à souligner le retour sur investissement de l'utilisation du modèle de conception là où vous le pouvez, sans faire paraître votre manager mauvais.

Ne changez pas ce que vous faites à moins que vous vous sentiez en danger de faire pire qu'une réprimande. Continuez à leur montrer les avantages de l'utilisation du modèle, et ils finiront par se raviser.

En poursuivant la lutte, essayez de gagner d'autres alliés dans l'équipe. De cette façon, vous n'êtes pas la seule voix entendue pour défendre le modèle.

A un moment donné, cependant, si ils refusent, vous avez le choix de décider si cet environnement est bon pour vous. Je ne pense pas que vous en soyez encore là, mais vous devrez peut-être passer à un environnement plus acceptable pour les bonnes pratiques de codage.

Rappelez-vous, ce combat que vous menez est un marathon. Si vous voulez changer la culture du codage, il vous appartiendra de démontrer la valeur du modèle.

Premièrement, nous ne pouvons pas dire, à partir des informations données, qui a raison. En fait, si j'étais appelé à vérifier le projet, j'aurais peut-être encore du mal à décider qui a raison, car vous pourriez concevoir le projet en ayant des objectifs différents. Mais je suppose que le patron connaît mieux les objectifs que vous.

Deuxièmement, votre question : “comment puis-je persuader mon patron ?” La réponse est que vous ne le pouvez probablement pas. En fin de compte, c'est lui le patron. La seule fois où j'ai persuadé mon patron de changer ses idées sur le génie logiciel, c'est après que nous ayons passé un an à corriger un logiciel peu fiable qui était écrit de la façon dont il le voulait, et que nous lui ayons dit que nous ne pouvions pas le rendre fiable, sauf en le concevant différemment.

Nous ne savons pas qui est juste ici d'un point de vue technique - il pourrait s'agir d'un manager coincé dans le passé, ou d'un nouveau développeur croyant aveuglément à tout le battage publicitaire.

Mais c'est votre manager, et vous ne traitez pas avec le manager, vous traitez avec son refus de faire ce que vous pensez être le mieux, et insistez pour faire ce qu'il elle pense être le mieux. Et c'est l'état normal des choses, que votre manager prenne la décision. C'est également normal qu'il soit responsable du succès ou de l'échec, et non pas vous. C'est lui qui a l'autorité. Et il a raison, vous ne devriez pas remettre en question son autorité. Vous pouvez remettre en question son droit, mais pas son autorité. En attendant, au lieu de penser que les choses ne vont pas comme vous le souhaitez, réfléchissez à la manière dont vous pouvez produire le meilleur code de qualité possible dans les limites de vos possibilités. Beaucoup de choses peuvent être faites de différentes manières. Il y a “simple, mal conçu” et “simple, bien conçu”. Optez pour cette dernière.

L'expérience permet de juger si les avantages du modèle de conception sont possibles et probables à l'avenir. Si le superviseur connaît le modèle et le refuse toujours, il reconnaît probablement le cas lorsque l'application de ce modèle ou d'un modèle similaire ne porte pas ses fruits. Parfois, l'expérience contredit les règles ou, plus probablement, leurs interprétations.

Il existe une opinion connue selon laquelle un code plus court et plus simple est plus facile à comprendre et plus ouvert à des modifications importantes.

Je suggère de jumeler la programmation et l'examen par les pairs. Cela aidera vos collègues à mieux comprendre votre code, car vous devez expliquer pourquoi et comment pendant que vous le faites plutôt qu'après coup.

Soit ils apprendront de vous et verront pourquoi c'est intelligent, soit vous apprendrez que les meilleurs programmeurs écrivent du code que d'autres peuvent maintenir.