Le Premier ministre optant pour une configuration trop complexe que personne n’a jamais expérimentée [fermé]

Récemment, j'ai démarré un projet qui ne semblait pas trop difficile à faire. Le concept était une application assez simple, qui devait accepter des entrées de temps en temps (peut-être 10 fois par jour), et essayer de réaliser certaines opérations et de collecter tous les résultats. à la fin. Cette application obtiendrait alors un portail Web frontal que les clients pourraient utiliser pour afficher les résultats, pas exactement comme un génie.

Pour cela, j'ai d'abord utilisé intelligemment les bibliothèques de concurrence intégrées de Python ( ThreadPoolExecutor) et utilisé une bibliothèque facile à utiliser pour le front-end (j'ai choisi Flask car il est facile à utiliser pour les débutants et relativement facile à maintenir et à tester).

Une fois le projet à mi-parcours, le PM a déclaré que nous devions utiliser des capacités de file d'attente de messages tierces au lieu de threads et mettre en œuvre l'équilibrage de la charge. Nous avons finalement commencé à travailler avec Celery, Redis, RabbitMQ, Nginx, uWSGI. et un ensemble d'autres grands services tiers que personne n'a jamais vécus.

Cela a finalement abouti à une série de codes spaghetti, à des tâches incontrôlables (en raison de la complexité des bibliothèques tierces, la correction du code ne fonctionnait même pas) et à une série de maux de tête car personne ne savait même quelle était la valeur ajoutée de ces services. .

Avant de dire "Oui, vous devriez utiliser ces services", gardez à l'esprit que personne ne sait comment les utiliser ni même ce qu'ils font en plus d'introduire du code infesté de race-condition.

Que dois-je faire à ce sujet? À ce stade, il serait tout simplement trop coûteux de revenir à ce que nous avions et le Premier ministre est impuissant à utiliser ces services, même si le produit final est maintenant moins bien loti qu’au début. Est-il utile de discuter de cela avec lui? Est-ce que je demande plus de temps? Ou la réponse dure, suis-je trop stupide pour mon travail?

Une fois le projet à mi-parcours, le PM a déclaré que nous devions utiliser des capacités de file d'attente de messages tierces au lieu de threads et que nous devions mettre en œuvre l'équilibrage de charge.

Ce n'est pas une chose appropriée pour un Premier ministre à "déclarer" unilatéralement. Deux raisons:

1. Les décisions de conception doivent être prises par une ressource technique et uniquement en réponse aux RNF . Alors, demandez poliment à votre Premier ministre s’il existe un nouveau NFR et si vous pouviez avoir des détails, s’il vous plaît.

2. Si un NFR est introduit à mi-parcours du projet, cela devrait probablement se faire via un contrôle des modifications . Le contrôle du changement est très important du point de vue de la gouvernance; il s'agirait non seulement d'une contribution à vos besoins, mais également d'une contribution importante aux scénarios de test, au manuel de déploiement et au support des opérations de QA, et (voici la partie la plus importante) au calendrier du PM . Si la nouvelle exigence introduit davantage de travail, l'équipe de développement devrait avoir la possibilité de communiquer les nouvelles estimations de développement, et le PM devra décider s'il peut accepter la nouvelle date, ajouter plus de ressources ou faire marche arrière avec l'acteur qui l'a introduit. le NFR.

Maintenant, s’il existe vraiment un NFR authentique et qu’on ne l’écarte pas, il peut également être approprié de demander des ressources nouvelles ou différentes connaissant les technologies en cours d’introduction, ou de demander un budget de formation pour certains de vos employés existants. Ressources. Donc, il y a aussi un aspect de coût .

Si vous parlez le langage du premier ministre - le calendrier et les coûts - je pense que vous obtiendrez plus de traction que de dire ce que les développeurs pensent de la conception résultante. Ces choses ont un impact réel.

Un Premier ministre devrait savoir mieux que d’introduire de telles choses à la volée, sans gouvernance, sans contrôles et sans consensus. S'ils ne l'obtiennent tout simplement pas, vous devrez peut-être faire appel à la gestion des produits ou des programmes, car il met inutilement la qualité et le calendrier en péril.

Ce qui serait stupide, c'est de vous laisser faire marcher la mort .

Ce que vous décrivez, c'est que vous avez perdu le sens critique. Il n'y a pas de sentiment de contrôle et pas de chemin clair pour y revenir.

La dernière chose à faire est de travailler dur, de garder la tête baissée et de souffrir jusqu'à ce qu'ils admettent enfin que le projet est condamné.

Ce que vous devriez faire, c'est réfléchir très fort à ce que vous êtes en droit d'attendre.

S'ils veulent que vous utilisiez des technologies que vous ne comprenez pas, attendez-vous à ce qu'ils aient le temps de les apprendre. N'ayez pas honte de ce que vous ne savez pas. Utilisez votre ignorance comme un gourdin. Quand ils exigent que vous utilisiez quelque chose, demandez pourquoi. Ne pas accepter "parce que". N'acceptez pas les «meilleures pratiques modernes». N'acceptez pas de «capacité d'échelle» sans obtenir des attentes réelles et vérifiables.

Par testable, je veux dire qu'ils DOIVENT vous dire combien de demandes par jour / heure / minute ils veulent que cela soit en mesure de le faire. Indiquez clairement que vous avez l’intention de construire quelque chose pour exercer ce système conformément à ces spécifications.

De cette façon, vous pouvez utiliser un essai gratuit de 30 jours pour prouver que le dernier truc de wiz bang qu’ils veulent en vaut la peine ou si vous préférez rester à ce que vous savez déjà.

Maintenant, gardez à l'esprit. Ce ne sont pas les outils qui ont introduit le code en proie à la concurrence. Vous avez fait ça les gars. Vous devez apprendre comment vous avez fait cela pour pouvoir annuler cela.

Et non. Il n'est pas trop coûteux de revenir à ce que vous aviez. Le Premier ministre ne peut pas avoir ce qu'il veut juste en le exigeant. Vous devez repousser jusqu'à ce que vous puissiez utiliser efficacement ce que le PM souhaite ou prouver que ce n'est pas ce dont le projet a besoin.

Sérieusement, le simple fait de céder à cela n’est pas professionnel et est mortel pour le projet.

J'ai été ici mec. Plus d'une fois. Cela vous fait sentir stupide. Ce n'est vraiment pas ça. Tu es juste perdu.

Parlez au PM. Honnêtement. Disposez le tout. Montrez que vous êtes prêt à apprendre mais que vous ne voulez pas être emmené faire un tour. Jamais jamais concevoir ou code basé sur la foi. Faites en sorte que le PM vous montre comment faire ce qu'ils veulent. Ne prétendez pas que vous comprenez quand vous ne comprenez pas. Ne dites pas que ça sera fait quand ça ne va pas. Si vous allez croire en quelque chose, croyez en vous-même. Vous devez être prêt à dire NON.

Si cela ne fonctionne pas, peaufinez le CV car vous en aurez besoin bientôt. D'une façon ou d'une autre.

Cela devrait vraiment être sur lieu de travail.stackexchange.com, parce que le problème n'est pas vraiment une question de développement logiciel, mais à propos des relations entre le lieu de travail.

Si vous êtes certain que votre approche simple aurait fonctionné et aurait produit un résultat fonctionnel assez rapidement, alors votre PM est une force destructrice de votre entreprise qui doit être supprimée. Déterminez comment faire passer la nouvelle au-dessus de lui: le fait que votre équipe dispose d’une solution simple, efficace et qui a bien progressé, et pour des raisons que personne ne peut expliquer, votre premier ministre vous a forcé à essayer une solution beaucoup plus complexe en utilisant une multitude des outils que personne ne sait, personne ne comprend, personne ne sait s'ils sont utiles, et cette décision insondable de votre premier ministre vous a causé beaucoup de problèmes et a rendu le projet en retard et ne fonctionnait pas.

Ne connaissant pas le contexte et la stratégie produit de votre direction, il est difficile de répondre de manière objective à votre question.

Voici quelques arguments objectifs. Il est cependant possible que ce ne soit pas ce à quoi vous vous attendiez:

• « Gardez à l' esprit que personne ne sait comment utiliser ces produits encore ».
• Utiliser uniquement des outils et des techniques parfaitement connus garantira une productivité élevée. Mais cela limitera considérablement la capacité d'innovation. Sur certains marchés, cela pourrait être fatal pour votre produit. Par exemple, il y a près de 30 ans, j'ai proposé d'utiliser Windows 3.0 pour développer une nouvelle version d'un produit de CAO qui fonctionnait bien sous MS-DOS. Le chef de produit a objecté que ce n’était pas un environnement éprouvé, que ce serait trop complexe et trop difficile à apprendre pour l’équipe, et que de toute façon, " Windows ne sera jamais un environnement traditionnel " ... Je vous laisse deviner le succès de son produit 2 ans plus tard.
• Tout est une question de coûts et d'avantages. Le coût de l'expérimentation par rapport aux avantages d'une évolutivité et d'une déployabilité assurées par un tiers expérimenté avec des installations gigantesques et une charge de travail lourde.
• Les inconvénients liés à l'ajout d'une nouvelle technologie peuvent être atténués grâce à une formation appropriée ou à un accompagnement initial par un consultant expérimenté.

En définitive, le choix économique incombe à votre chef de produit. Discutez avec lui des avantages et des inconvénients, pour vous assurer qu'il prend une décision éclairée et ne sous-estime pas la complexité supplémentaire. Et s'il reste sur sa piste, essayez de faire de votre mieux: vous n'avez rien à perdre et, dans le pire des cas, vous aurez une nouvelle technologie sur votre CV.

Il existe deux approches pour les bibliothèques tierces (et autres composants):

1. Utilisez-en autant que possible
2. Utilisez-en le moins possible

Mon approche est (2). On dirait que votre approche est aussi (2), mais le chef de projet aime cette approche (1).

Vous pouvez gérer cette situation de trois manières. Soit vous laissez le Premier ministre faire ce que le Premier ministre veut, vous essayez de le convaincre de changer l’approche des bibliothèques tierces, ou vous votez avec vos pieds et choisissez un autre travail.

Si vous voulez convaincre le PM de changer d’approche, considérez les arguments suivants:

• Temps d'apprendre. Chaque bibliothèque externe a besoin de temps pour apprendre, période pendant laquelle un programmeur compétent peut écrire la fonctionnalité désirée, en particulier si une énorme bibliothèque est choisie pour effectuer une tâche très simple pouvant être réalisée en quelques centaines de lignes de code.
• Remplaçabilité.Si vous avez une bibliothèque externe, comment vous assurez-vous que si son développement est arrêté, vous pouvez la remplacer par une autre bibliothèque similaire? Ma solution consiste à éviter les bibliothèques externes chaque fois que je le peux et chaque fois que cela n’est pas faisable, j’écris un simple wrapper pour résumer la partie de l’interface de programmation que je souhaite. En général, l'interface que je veux est beaucoup plus simple que l'interface proposée par la bibliothèque. Ensuite, mon code accède à la bibliothèque externe uniquement via cet encapsuleur, facilitant ainsi les remplacements. Construire l'intégralité de votre application sur un framework est un gros no-no. Des servlets? Oui, ils sont ici depuis longtemps et continuent de l'être dans un avenir prévisible. Moteurs de template? Oui, bien qu'ils ne soient pas exactement remplaçables (vous en choisissez généralement un et vous restez avec cela), la valeur qu'ils apportent est énorme, choisissez donc soigneusement - et gardez à l'esprit que lors du changement de moteur de gabarit, vous pouvez avoir deux moteurs de gabarit dans la même application, mais vous ne pouvez généralement pas avoir deux frameworks dans la même application. Apache Struts? Non, les frameworks viennent à la mode et le deviennent rapidement, et vous ne pouvez généralement pas avoir deux frameworks dans la même application.
• Version enfer. En sélectionnant une bibliothèque externe, vous devez la mettre à jour pour éviter les failles de sécurité, et sa mise à jour peut entraîner des problèmes. Des composants bien conçus (tels que Java JRE) sont compatibles avec différentes versions, mais d'après mon expérience, la plupart des bibliothèques sont des merdes parce qu'elles imposent un énorme enfer de version. De plus, le composant X peut nécessiter Z version 1 et le composant Y peut nécessiter Z version 2, et vous ne pourrez pas nécessairement relier Z version 1 et Z version 2 dans la même application.
• Failles de sécurité. En sélectionnant une bibliothèque externe, le nombre de vulnérabilités de sécurité facilement exploitables par rapport à votre application augmente. Certains pourraient prétendre que le code développé en interne ressemble à la sécurité par l'obscurité, mais encore une fois, je dirais que c'est toujours une forme de sécurité.
• Problèmes de licence. Chaque bibliothèque externe impose sa propre licence sur des parties de votre programme. Par exemple, les bibliothèques GPL ne peuvent pas être utilisées dans des programmes non GPL, et les bibliothèques LGPL nécessitent également la distribution du code source ainsi que des fichiers binaires, ce qui peut nécessiter une quantité considérable de bande passante.
• Temps de démarrage de l'application. Chaque grande bibliothèque externe ralentit le temps de démarrage de votre application. En écrivant une bibliothèque simple et légère en interne, vous pouvez accélérer le démarrage de votre application.
• Empreinte mémoire. En ayant X nécessitant Y nécessitant Z nécessitant A nécessitant B, vous avez besoin de X + Y + Z + A + B dans la mémoire en même temps. En n'implémentant que l'équivalent de X, appelons-le X '. En interne, vous n'avez besoin que de X' en mémoire. Et généralement, l'empreinte mémoire de X 'est inférieure à l'empreinte mémoire de X.
• Risque de bug. Plus il y a de lignes dans le composant externe, plus grand est le risque que vous rencontriez un bogue qui sera difficile à corriger en raison de la quantité de code que vous devez comprendre. Si vous faites la chose en interne, vous le faites généralement avec moins de lignes de code (pour faire exactement ce dont vous avez besoin, rien d'autre), et donc un risque de bugs moins important.
• Personnalisabilité. Si j'écris moi-même des requêtes SQL, je sais à quoi elle ressemble et comment elle fonctionne sur un moteur de base de données et un ensemble d'indices donnés. Si, en revanche, la requête SQL est écrite par un composant externe, je ne sais rien de ses performances. Je travaillais dans une entreprise où chaque page Web prenait plusieurs secondes à récupérer. Je soupçonnais que la cause en était la bibliothèque Hibernate qu’ils utilisaient avait extrait trop de données automatiquement dans la base de données alors que tout ce dont vous aviez besoin était d’un élément et non de tous les éléments liés à cet élément. J'ai quitté la société avant de découvrir la véritable cause de la lenteur, car je n'aimais pas l'approche consistant à utiliser un très grand nombre de bibliothèques existantes.

Méfiez-vous surtout si une bibliothèque s'appelle un framework . Cela signifie que la bibliothèque nécessite que vous construisiez votre application dans son intégralité. En général, vous ne pouvez pas avoir deux cadres dans la même application; ils se battront sans coexister pacifiquement. Bibliothèque d'utilitaires de développement Web? Oui s'il vous plait, il y en a trop peu. Si jamais je trouve une meilleure bibliothèque que celle que j'utilise actuellement, je peux utiliser la nouvelle bibliothèque trouvée dans le nouveau code tout en continuant à utiliser l'ancienne bibliothèque dans l'ancien code. Cadre de développement Web? Un grand klaxon NON!

Je pense que votre premier ministre vise un système difficile à gérer, qui nécessitera beaucoup de travail de maintenance en temps réel, garantissant ainsi vos revenus.

Personnellement, vous semblez être coincé avec python, oubliez simplement python pendant un certain temps, ne codez pas en python pendant un an, apprenez de nouvelles choses, vous verrez qu'il existe d'autres langages qui peuvent faire la même chose, et probablement mieux.

Comme d’autres l’ont dit, apprenez les outils avant de commencer à coder avec eux. Peut-être suggérerait-il qu'il serait bon d'évaluer ensemble la pile nécessaire, en se basant sur la recherche de différents outils qui semblent adaptés à la tâche. Ou peut-être demander comment il en est arrivé à cette liste, il aurait pu être aidé par quelqu'un qui est à jour.

Les développeurs ne doivent pas avoir peur d'apprendre à utiliser de nouvelles bibliothèques, de nouveaux frameworks, de nouvelles technologies, etc. Cela fait partie intégrante de la description de leur travail et il est parfaitement raisonnable que quelqu'un suggère à l'équipe de travailler avec des tâches tierces dont personne ne dispose. d’expérience ou même d’exiger que l’équipe le fasse si elle est en mesure de prendre des décisions techniques faisant autorité pour l’équipe.

Cependant, il n’est pas raisonnable de s’attendre à ce que vous puissiez simplement tirer une nouvelle technologie (et encore moins plusieurs nouvelles technologies à la fois.) dans votre pile et continuez à progresser. Un temps considérable aurait dû être programmé pour apprendre les tenants et les aboutissants de la nouvelle approche et trouver un bon design pour incorporer les nouvelles pièces, au cours duquel aucun progrès réel sur le produit réel ne serait attendu (de la part des personnes effectuant ce travail d'apprentissage / de conception , qui peut ou peut ne pas être toute l’équipe, mais si ce n’est pas le cas, il faudra probablement prévoir plus de temps pour les personnes qui ont appris à transférer des connaissances au reste de l’équipe). C'est le coût de ce genre de changement majeur. L'apprentissage de nouvelles technologies fait partie du travail du développeur, mais ce n'est pas quelque chose qui se produit avec un coût horaire nul.

Il semble que cela ne soit pas arrivé à la question. Les gens ont tout mis en œuvre pour essayer de créer de bonnes implémentations à partir de technologies qu’ils ne comprenaient pas eux-mêmes. Bien sûr, le code résultant est terrible.

Essayez de convaincre votre Premier ministre que la société devra passer plus de temps à ce sujet. Cela prendra la forme d'arrêter maintenant, d'apprendre et d'évaluer les nouvelles technologies, de trouver une bonne conception et de nettoyer le gâchis actuel de la mise en œuvre. Ou cela prendra la forme de plus de temps perdu en bugs, maintenance, développement plus coûteux, etc.

Il est impossible de dire si les choix techniques décrits dans la question (équilibrage de la charge, files de messages, etc.) sont réellement appropriés. Je ne pense pas que « personne ne l'équipe a de l' expérience avec cela avant » est une bonne raison absolument écarter une décision, mais il n'augmenter le coût à court terme de prendre cette décision (qui peut modifier la " "meilleure décision en fonction du contexte"), et si votre premier ministre n’envisage pas cela et s’attend à ce que l’équipe devienne immédiatement aussi productive que le seraient des personnes expérimentées, vous devriez reculer pour ces raisons; ils établiront des calendriers de projet hautement irréalistes, ce qui n'est dans l'intérêt de personne.