Comment convaincre l'équipe de programmation de se défaire de ses vieilles habitudes?

https://stackoverflow.com/questions/493460

20-08-2019
|

Question

C’est davantage une question de programmation orientée métier que je n'arrive pas à comprendre comment résoudre. Je travaille avec une équipe de programmeurs qui travaillent avec BASIC depuis plus de 20 ans. On m'a demandé d'écrire le même logiciel dans .NET, uniquement avec des mises à jour et des pratiques modernes. Le problème est que je ne parviens pas à convaincre l’un des 3 autres membres de l’équipe (tous les programmeurs BASIC, même si on le fait maintenant .NET) de comprendre comment créer correctement une base de données relationnelle. Voici ce qu'ils ne comprendront pas:

Nous avons essentiellement une transaction qui garde une trace des informations de tag d'un client. Nous devons pouvoir suivre les transactions en cours et passées. Dans l'ancien système, une base de données à fichier plat était utilisée. Elle contenait une table contenant des enregistrements avec la transaction courante de base du client et une autre transaction contenant toutes les transactions précédentes du client ainsi que des informations financières importantes. Pour éviter les redondances, ils écraseraient la transaction en cours avec l'historique des transactions - (le fichier d'historique a été mis à jour en premier, puis le fichier actuel.) C'est totalement inutile, car vous n'avez besoin que d'une table de Les travailleurs ne semblent pas comprendre cela. Comment puis-je les convaincre de voir la lumière afin que nous n'ayons pas à faire un travail ridicule et que nous finissions par toucher trop souvent à la datatabse? Merci pour votre contribution!

La solution

Tout d'abord, je dois admettre que, d'après votre description, les structures de données et la logique dans les structures existantes ne sont pas tout à fait claires. Cela signifie pour moi que vous ne vous expliquez peut-être pas non plus vos collègues de travail. Une de vos priorités doit donc être de pouvoir expliquer, verbalement ou de préférence par écrit et par des diagrammes, la situation actuelle et le remplaçant proposé. Veuillez prendre cela comme une observation plutôt que comme une critique de votre question.

Deuxièmement, je trouve assez remarquable que les programmeurs de 20 ans d’expérience ne comprennent pas les bases de données relationnelles et les transactions. Le codage de fichier à plat est sorti de l’ordinaire il y a très longtemps. En 1988, j’avais traité pour la première fois des bases de données relationnelles dans un environnement commercial. C’était assez courant au milieu des années 90. Sur quel secteur et type de produit travaillez-vous? Il me semble possible que vous ayez affaire à un système intégré ou «inhabituel», auquel cas vous devez vous assurer que vous n’avez pas de problème de communication et que vous oubliez un grand éléphant. cela ne vous a pas été signalé - vous ne seriez pas le premier «consultant» à faire partie d'une équipe qui a été créée d'une manière quelconque en ne recevant pas les informations appropriées. Cela dit, de tels magasins archaïques existent toujours - l’un de mes systèmes clients actuels s’interface avec un système basé sur un fichier plat codé en COBOL, et oui, c’est un enfer à gérer ;-)

Enfin, si vous êtes complètement sûr de votre terrain et que vous faites face à une équipe qui ne prend pas en compte vos recommandations - et que le code de démonstration est une bonne idée si vous pouvez économiser du temps - alors vous aurez probablement accepter la décision avec élégance et en déplacer une. Dans cette position, j'essaierais de résumer le problème - les mises à jour de la base de données peuvent-elles être déplacées dans des procédures stockées, par exemple, de sorte que le code permettant de mettre à jour les deux tables se trouve dans le SP et puisse être modifié à une date ultérieure pour passer à votre schéma sans changement d'application correspondant? Assurez-vous que vos arguments sont bien documentés et enregistrés afin de pouvoir les revoir ultérieurement si l'occasion se présentait.

Vous ne serez pas le premier codeur à avoir mis en œuvre une solution sous-optimale en raison de la politique de son bureau. Utilisez-la comme une expérience d'apprentissage pour votre développement personnel sur la gestion de telles situations et gratifiez-vous avec la pensée que vous serez payé. pour le travail supplémentaire. Souvent, le facteur décisif dans de tels arguments n’est pas la logique, mais le "poids de la réputation" que vous apportez vous-même à la table - il semblerait que vous ayez été importé, vous n’avez pas beaucoup de ce genre de levier auprès de votre équipe. vous devrez peut-être travailler à vous faire une réputation en excelant mettre en oeuvre ce qu’ils s’engagent à faire avant que vous ayez suffisamment de réputation dans des affaires ultérieures - vous devez être modifié en premier!

Autres conseils

Parfois, vous ne pouvez pas.

Si vous lisez des livres XP, ils disent souvent que l'un de vos plus gros obstacles sera de convaincre votre équipe d'abandonner ce qu'elle a toujours fait.

En général, ils recommanderont de laisser les personnes qui ne peuvent pas s’adapter se lancer dans d’autres projets (ou tout simplement de les laisser partir).

Les révisions de code pourraient vous aider dans votre cas. Les révisions de code obligatoires de chaque ligne de code ne sont pas inconnues.

Parfois, le meilleur argument est un exemple. J'écrirais un prototype (ou un remplaçant sinon trop de travail). Avec un exemple à examiner, il sera plus facile de voir les avantages et les inconvénients d’une base de données relationnelle.

En passant, les bases de données de fichiers plats ont leur place car elles sont tellement plus faciles à & "administrer &"; qu'une vraie base de données relationnelle. Garde l'esprit ouvert. ; -)

Je pense que vous devrez peut-être donner l'exemple - quand les gens verront que le & "nouveau &"; façon, c’est moins de travail, ils l’adopteront (tant que vous ne vous frottez pas le nez dessus).

Je voudrais également vous demander si l'ancien design pose réellement un problème ou s'il est simplement esthétiquement ennuyeux. Il est important de choisir vos batailles. Si l'ancienne conception ne pose pas de problème de performances ou ne rend pas le système difficile à maintenir, vous voudrez peut-être laisser l'ancienne conception toute seule.

Enfin, si vous laissez l'ancien modèle en place, essayez de résumer l'interface entre votre nouveau code et l'ancienne base de données. Ainsi, si vous persuadez vos collègues d'améliorer la conception ultérieurement, vous pouvez déposer le nouveau schéma sans avoir à changer quoi que ce soit d'autre.

Il est difficile d’extraire beaucoup de choses, sauf la frustration générale, de la question initiale.

Oui, il existe un grand nombre de techniques et d'habitudes que de longues heures suivent, qui peuvent être inutiles et même coûteuses à la lumière des changements technologiques. Certaines choses qui ont du sens lorsque le traitement de la puissance, de la mémoire et même du disque coûtent cher peuvent être des tentatives stupides d'optimisation. De plus, les gens accumulent de mauvaises habitudes et de mauvais schémas de programmation au fil du temps.

Vous devez cependant faire attention.

Parfois, il y a de bonnes raisons pour les choses que font les anciens. Malheureusement, ils ne seront peut-être même pas en mesure de verbaliser le & «Pourquoi &»; - s’ils savent même plus pourquoi.

Je vois souvent ce genre de frustration lorsque les débutants entrent dans un atelier de développement de logiciels d’entreprise. Cela peut être mauvais même lorsque l’environnement est une technologie et des outils assez modernes. Si l'essentiel de votre expérience concerne l'écriture d'applications Web et de bureau pour petites communautés, vous devez & "Connaître &"; peut avoir tort.

Il existe souvent des exigences en matière de journalisation des transactions à un niveau supérieur à ce que votre SGBD peut faire. Bien souvent, il peut s'avérer nécessaire d'aller au-delà de la sémantique des transactions de base de données pour garantir l'exactitude des séquences chronologiques, une et une seule fois, les mises à jour, la résiliation et la non-répudiation.

Et cela ne commence même pas à résoudre les problèmes liés à l'évolutivité d'entreprise ou inter-entreprises. Lorsque vous commencez à approcher un demi-million de transactions complexes par jour, vous constaterez que la technologie des SGBDR vous fait défaut. Comme les bases de données relationnelles ne sont pas conçues pour gérer des volumes de transactions élevés, vous devez souvent rompre avec les paradigmes standard en matière de normalisation et de mise à jour. Les techniques de verrouillage de SGBDR classiques peuvent détruire l’évolutivité, quel que soit le matériel utilisé pour résoudre le problème.

Il est facile de rejeter tout cela comme une lourdeur ou une erreur générale - même une incompétence. Mais faites attention car ce n'est pas toujours le cas.

Et au fait: il existe d'autres modèles que le SGBDR, et l'alternative à un SGBDR n'est pas nécessairement & "Fichier plat &"; - contrairement à l'expérience de la plupart des codeurs aujourd'hui. Certains SGBD hiérarchiques transactionnels peuvent gérer un débit beaucoup plus élevé qu'un SGBDR. IMS est toujours très actif dans les grands magasins IBM, par exemple. D'autres fournisseurs proposent des logiciels similaires pour différentes plates-formes.

Bien sûr, dans une boutique de quatre hommes, rien de tout cela ne s'applique.

Inscrivez-les à des formations dignes, puis c’est à vous de les convaincre que grâce aux nouvelles technologies, il est beaucoup plus possible (ou au moins plus facile!).

Mais je pense que la chose la plus importante ici est que des formateurs professionnels et certifiés leur apprennent les bases. Ils seront plus impressionnés par cela que par un seul de leurs collègues qui leur dira: & "Hé, pourquoi ne pas utiliser ceci? &";