Aider quelqu'un qui n'est pas et ne sera jamais un programmeur professionnel à écrire du code plus lisible et utilisable à utiliser et à interpréter [fermé]

Je suis Elvis, essayant très fort d'apprendre à être Einstein. Je travaille pour Mort.

De quoi diable cet idiot fou parle-t-il!?!? (Il vous suffit de lire les premiers paragraphes)

Si vous n'avez pas envie de lire ce lien, en gros, je suis un programmeur professionnel, et mon patron est (c'est très précis):

le programmeur professionnel professionnel qui ne possède pas de diplôme en informatique mais qui a une grande connaissance d'Office et de VBA, et qui écrit généralement des applications de productivité partagées entre ses collègues

Cela dit, une grande partie de mon travail consiste à prendre son code pavé et à le préparer à la production. Cependant, le style très pauvre et le culte du fret rendent cela difficile. Cela est aggravé par le fait qu'il n'est pas disposé à lire des livres de programmation ou à me permettre de l'aider à remanier son code.

Existe-t-il d'autres stratégies pour aider quelqu'un qui n'est pas un programmeur professionnel, ne sera jamais un programmeur professionnel à écrire du code qui sera plus lisible et utilisable pour moi à utiliser et à interpréter?

En examinant vos réponses dans plusieurs des commentaires, je ne sais pas si vous réalisez que ce que vous vivez est assez courant, en particulier lorsque vous travaillez dans des domaines de spécialité où il faut des experts du domaine (appelons-les le scientifique) pour comprendre comment incorporer et adapter des algorithmes pour les problèmes à résoudre.

Plutôt que de se plaindre du scientifique et de s'attendre à ce qu'ils changent, sachez simplement que vous ne devriez pas vous attendre à ce que le scientifique se soucie beaucoup de la «qualité du code». Il est souvent difficile d'amener d'autres développeurs de logiciels à se soucier de la «qualité du code» et encore moins de quelqu'un dont les intérêts principaux se situent dans le domaine et non dans la programmation.

La direction à suivre dépend en grande partie du degré de confiance du «scientifique» dans votre capacité à comprendre son travail. S'ils ont la certitude que vous pouvez comprendre leur code et qu'ils ne le verront pas lorsque vous modifiez des choses, il n'y a généralement pas de problème. Ils s'appuieront sur votre expertise.

Cependant, si le scientifique ne veut pas que vous changiez son code, il est fort probable que vous n'ayez pas encore "gagné" sa confiance. Si tel est le cas, plutôt que de vous concentrer sur la réparation du scientifique, vous devriez vous concentrer sur la "réparation" de vous-même. Ce que je veux dire par là, c'est prendre des mesures pour gagner leur confiance. La façon la plus simple de procéder est probablement la suivante:

Dans le cadre de votre processus de test:

1. Commencez à transformer les algorithmes en quelque chose de plus facile à comprendre (par exemple, diagrammes, PDL, notation mathématique)
2. Apprenez à comprendre les algorithmes.
3. Assurez-vous d'identifier les cas de bord.
4. Demandez au scientifique si votre représentation "alternative" simplifiée est correcte
5. ET LE PLUS IMPORTANT identifier les problèmes que vous avez trouvés; ET sans sonner "accusateur", dites quelque chose comme "Je regardais l'algorithme et j'ai remarqué que XYZ est censé faire ceci ou est-il censé faire cela?". Rien ne gagnera leur confiance mieux que cette balle.

Une fois que vous commencez à trouver des bogues ET avez démontré un intérêt pour leur domaine d'intérêt, les chances deviennent beaucoup plus élevées qu'au moins ils vous permettront de commencer à modifier le code pour le rendre plus "professionnel". Souvent, ils ne ressentent même plus le besoin de coder un prototype. Ils écriront simplement quelque chose dans l'une de ces notations "alternatives" que vous leur avez enseignées (sans même qu'ils s'en rendent compte) et ils auront confiance que vous saurez ce qu'ils signifient.

Par tous les moyens, ma première tentative serait de proposer quelques suggestions sur la meilleure façon pour le scientifique de mieux "communiquer" afin de vous aider; mais il semble que vous ayez essayé cela. La seule étape sur laquelle vous avez le contrôle est donc ce que vous faites. Gagnez leur confiance et presque toujours, l'expert du domaine sera soulagé de transmettre le codage à quelqu'un d'autre et de ne pas avoir à se soucier de tous les petits détails qui entrent dans l'écriture de code. Ils préfèrent de loin se concentrer sur l'amélioration des algorithmes.

Parfois, tout ce que vous pouvez faire est de proposer une suggestion et de la laisser après. Vous n'impressionnerez pas votre patron ou une personne âgée si vous continuez à insister sur quelque chose qu'ils ont déjà rejeté ou décidé de ne pas faire, même si vous avez 100% raison. En fait, cela nuira à une relation, que vous soyez le suggérant ou le suggéré. Concentrez-vous simplement sur ce que VOUS pouvez faire pour vous faciliter la tâche.

Quand il est vraiment "quelqu'un qui n'est pas un programmeur professionnel, ne sera jamais un programmeur professionnel" comme vous le dites et quand une grande partie de votre travail consiste vraiment à "prendre son code pavé et le préparer à la production", cela ressemble à votre une équipe de deux personnes serait plus productive lorsqu'il vous laisserait la programmation et se concentrerait sur la partie managériale du projet.

Cependant, cela suppose que vous avez raison. Nous, les programmeurs, avons toujours tendance à ignorer le code écrit par d'autres personnes bien pire que le nôtre. Cette idée préconçue est vraiment difficile à vaincre et nous conduit à sous-estimer nos collègues. Ce que vous considérez comme une «programmation culte du fret» pourrait être de «bonnes pratiques éprouvées» de son point de vue, et ce que vous considérez comme «une application élégante de modèles orientés objet» pourrait être pour lui «une ingénierie inutile». Difficile à dire pour moi, car je ne connais que votre côté de l'histoire.

Le dédain pour le code des autres peuples devient d'autant plus fort que nos styles de programmation sont différents. Dans ce cas, c'est un instinct positif, car le mélange de différents styles de programmation dans un projet le rend très difficile à maintenir.

Lorsque vous ne pouvez pas imiter le style de l'autre, vous pouvez définir des responsabilités claires. Rendez une personne responsable d'une partie de la demande et l'autre personne de l'autre. Définissez des interfaces claires entre les deux modules ensemble, mais laissez l'implémentation interne au responsable. Pour le sensibiliser davantage aux bogues de son code, vous pouvez lui écrire des tests unitaires et signaler quand son code ne se comporte évidemment pas selon le contrat d'interface que vous avez spécifié ensemble.

En établissant une propriété de code claire, vous pouvez atteindre une meilleure coexistence de vos différents styles. De plus, lorsque vous êtes tous les deux responsables de la correction des bogues dans leur propre code, vous n'aurez pas à naviguer souvent dans le code de l'autre.

Vous devez vous demander: quel est votre objectif ultime ici? 1. pour aider votre patron? 2. pour aider l'entreprise? 3. pour vous aider? Et avant de répondre «tout ce qui précède», ralentissez. Votre première tâche est de définir clairement votre objectif principal, car la réponse en dépend.

Si votre objectif est de:

1. Aider votre patron? Abandonnez-le. Il ne semble pas le demander. Vous avez dit: "Il sait que son code est mauvais, mais il fait ce dont il a besoin." Eh bien, fin de la discussion. À moins que votre patron ne soit insatisfait de la situation actuelle et jusqu'à ce qu'il ne change pas, il n'appréciera pas vos efforts pour l'aider. Si, à un moment donné, il «ressent la douleur» du statu quo, j'espère que vous vous serez établi comme un mentor de confiance et qu'il saura où demander de l'aide.

2. Aider votre entreprise? La situation actuelle menace-t-elle les résultats? Les délais sont-ils menacés? La haute direction augmente-t-elle sa chaleur? Sinon, abandonnez-le. (C'est essentiellement le point que Jimmy Hoffa a soulevé dans son commentaire à votre message d'origine.) Si, cependant, la situation actuelle représente en fait un risque inacceptable pour votre département / entreprise, alors un changement de processus est de mise. Dans ce cas, je vous suggère de vous asseoir et de décrire un autrerépartition du travail. La clé ici est d'expliquer que le temps que vous passez à refactoriser le code de votre patron serait mieux utilisé pour écrire un nouveau code. Vous dites que vous n'avez pas le temps de tout écrire vous-même, mais ce n'est pas ce que je suggère. Vous devez déterminer comment maximiser vos forces respectives. Arrêtez de le considérer comme un Mort et considérez-le comme un développeur junior avec une connaissance supérieure du domaine. Il s'agit d'un arrangement de travail très courant dans l'industrie, et il vous incomberait d'apprendre à y prospérer. Par exemple, assurez-vous qu'il sait que vous savez à quel point son expertise est essentielle (répétez souvent cette étape), puissuggérer humblement la stratégie suivante (ou quelque chose de similaire) comme un moyen plus rapide pour mettre ses connaissances sur le marché: (a) diviser le travail en sprints "agiles", (b) collaborer fortement à l'avance (dans chaque sprint) définissant le plus -toutes les exigences et l'architecture. (c) Le laisser partir et construire le prototype pour élaborer toutes les décisions algorithmiques, pendant que vous construisez l'infrastructure que vous avez acceptée à l'étape précédente. (d) Implémentez ses algorithmes dans votre structure pendant qu'il construit des tests pour le vérifier. (e) Conduisez votre V&V ensemble dans un environnement de programmation par les pairs. (par exemple, "Ce test a échoué; pourquoi? erreur de logique algorithmique ou erreur de codage?"; répéter ici).

3. Aide-toi? Soyez honnête ici. Si tout ce que vous faites, c'est vous plaindre que vous n'aimez pas votre travail, je vous suggère de passer plus de temps à réfléchir au point 2 ci-dessus. Si vous ne vous souciez pas de l'entreprise ET que vous n'aimez pas votre travail, commencez à distribuer votre CV. Si vous vous souciez de votre entreprise mais que vous n'aimez pas votre travail, vous concentrer sur # 2 devrait vous aider sur les DEUX comptes. Mais dans ce cas, ce n'est "gagnant-gagnant" que s'il est clair pour tout le monde que votre passion découle véritablement d'un désir d'aider l'équipe, et pas seulement d'une frustration égocentrique dans votre mission.

Je ne suis pas sûr que j'ajouterai quelque chose à cette discussion, mais ayant travaillé dans des scénarios similaires où une violation d'accès frappe une ligne avec ShowMessage('Hello');ou similaire, seulement pour découvrir que la même ligne a plus de code, hors de l'écran à la droite,

Je crois que vous avez deux options de base:

1. Laissez le code s'exécuter . Si le code fonctionne et fait ce qu'il devrait faire, à moins que votre patron ne vous demande spécifiquement de corriger son code, laissez-le tel quel. Cela peut également l'amener à comprendre que votre code est plus joli et à vous laisser le travail (comme l'a également souligné Dunk dans sa réponse).
2. Si vous êtes très déterminé à professionnaliser le code, créez une bibliothèque / un framework qu'il pourra utiliser. S'il y a un modèle sur les erreurs / stratégies que vous corrigez généralement, vous pouvez les regrouper dans quelques fichiers de bibliothèque et le lui donner en tant que "bibliothèque de base pour l'entreprise" , que vous pouvez également utiliser comme interface commune.