Je ne peux pas programmer car le code que j'utilise utilise d'anciens styles de codage. Est-ce normal pour les programmeurs?

J'ai mon premier vrai travail de programmeur, mais je ne peux résoudre aucun problème à cause du style de codage utilisé. Le code ici:

• N'a pas de commentaires
• N'a pas de fonctions (50, 100, 200, 300 lignes ou plus exécutées en séquence)
• Utilise beaucoup d' ifinstructions avec beaucoup de chemins
• A variables qui n'a pas de sens (par exemple .: cf_cfop, CF_Natop, lnom, r_procod)
• Utilise une ancienne langue (Visual FoxPro 8 de 2002), mais il existe de nouvelles versions de 2007.

J'ai l'impression d'être retourné à 1970. Est-il normal qu'un programmeur familiarisé avec la POO, le code propre, les modèles de conception, etc. ait des problèmes avec le codage à l'ancienne?

EDIT : Toutes les réponses sont très bonnes. Pour mon (dé) espoir, il semble qu'il existe beaucoup de ce type de base de code dans le monde. Un point mentionné dans toutes les réponses est la refonte du code. Ouais, j'aime vraiment le faire. Dans mon projet personnel, je fais toujours ça, mais ... je ne peux pas refactoriser le code. Les programmeurs sont uniquement autorisés à modifier les fichiers dans la tâche pour laquelle ils sont conçus.

Chaque changement dans l'ancien code doit être commenté dans le code (même avec Subversion comme contrôle de version), ainsi que des métadonnées (date, programmeur, tâche) liées à ce changement (cela est devenu un gâchis, il y a du code avec 3 lignes utilisées et 50 anciennes lignes commentées). Je pense que ce n'est pas seulement un problème de code, mais un problème de gestion de développement logiciel.

D'accord, je vais être franc. C'est un mauvais endroit pour travailler ... J'ai été dans de telles situations, et généralement cela se termine avec vous avalé par ce code. Au bout d'un an environ, vous vous y habituerez et vous perdrez le contrôle sur la façon dont les alternatives modernes peuvent être utilisées pour accomplir la même tâche plus facilement, de manière plus maintenable et aussi, plus rapidement au moment de l'exécution dans la plupart des cas.

J'ai quitté un lieu de travail comme ça, car, après seulement un mois, j'ai eu l'impression d'être entraîné dans un ancien code de skool. J'ai essayé de l'essayer, mais j'ai décidé de ne pas le faire. Je ne pouvais pas utiliser de code propre et j'ai commencé à perdre des compétences à cause de la pratique quotidienne manquante. Toute approche moderne devait être approuvée par 3 couches de développeurs, ce qui ne s'est jamais produit, car l'idée était que les choses pouvaient se casser lorsque des approches modernes étaient utilisées. Et la nature fragile du code qui sort lorsque vous n'utilisez pas d'approches modernes est assez effrayante.

Ne vous méprenez pas, il y a des cas où les gens sur-conçoivent des solutions, et je suis contre. Mais le fait d'être entraîné dans les conventions et le style de codage de 80 pendant une longue période de temps arrêtera vos progrès, ainsi que, je pense, les opportunités de carrière.

Là encore, vous devez gagner de l'argent, donc parfois vous devez faire ce que vous n'aimez pas exactement. Gardez un œil sur les symptômes d'épuisement professionnel et transformez le codage en tâche banale dans ces cas-là.

Ce style de codage (si vous voulez même l'appeler n'importe quel type de style) est un mauvais style de codage.

On peut écrire des fonctions courtes avec des noms de variables descriptives et un contrôle de flux sain dans la plupart des langages modernes (Visual FoxPro est moderne, oui).

Les problèmes que vous rencontrez sont avec une mauvaise base de code, rien de plus, rien de moins.

De telles bases de code existent et sont nombreuses - le fait que vous ayez des problèmes avec elles témoigne de leur gravité (et que vous avez une bonne formation).

Ce que vous pouvez essayer de faire est d'améliorer les choses où vous pouvez - renommer les variables, extraire les points communs et diviser les grandes fonctions en plus petites, etc. Obtenez une copie de Travailler efficacement avec le code hérité ...

Je suis sur un projet C # avec une très mauvaise structure, pas à des kilomètres de ce que vous décrivez. Il suffit de combiner 12 fonctions distinctes (copier-coller évident) en une seule qui prend un seul paramètre.

Ce n'est pas vraiment "démodé", sauf que les bonnes pratiques de conception (actuelles) n'étaient pas toujours aussi populaires. C'est juste du mauvais code. Un mauvais code ralentit quiconque. Vous finissez par vous y habituer, mais c'est simplement parce que vous vous habituez à des bizarreries spécifiques dans votre système spécifique. Étant donné un nouveau projet, vous pourriez trouver de toutes nouvelles façons d'écrire du mauvais code. La bonne chose est que vous savez déjà identifier ces odeurs de code.

La plus grande chose que vous puissiez faire est de ne pas propager le problème . Ne prenez pas ces mauvaises pratiques comme une convention à moins que votre équipe ne le soit. Gardez le nouveau code propre de manière à ne pas forcer le refactor. Si c'est si mauvais et que vous avez le temps, pensez à un refactor majeur ... mais dans la pratique, vous avez rarement ce luxe.

Pensez à ajouter des commentaires au fur et à mesure que vous comprenez les choses et modifiez les petits morceaux si possible. À moins que vous ne codiez en solo, vous devez travailler avec votre équipe; s'il n'y a pas de conventions, vous devriez prendre un certain temps pour les élaborer, et peut-être vous engager à améliorer lentement la base de code si vous la maintenez régulièrement de toute façon.

Si vous trouvez une fonction totalement isolée avec des noms de variable incorrects et que vous la corrigez de toute façon, vous pourriez aussi bien rendre les noms de variable utiles, refactoriser les ifs. Ne modifiez pas les fonctionnalités communes, sauf si vous allez en refactoriser une grande partie.

• n'avez pas de commentaires - corrigez-le au fur et à mesure que vous l'apprenez
• n'ont pas de fonctions (50, 100, 200, 300 lignes ou plus exécutées en séquence)

Cela date probablement d'une précédente itération du code. À ce stade, je me méfierais des différences subtiles entre des blocs de code d'apparence similaire qui sont devenus des "fonctionnalités". Mais quelle que soit la gravité d'une idée de ce type de structure, elle est assez simple à comprendre ... donc je ne sais pas où vous auriez des problèmes.

• utilise beaucoup d'instructions if avec beaucoup de chemins - je ne suis pas vraiment certain de ce que vous voulez dire ici
• a des variables qui n'ont aucun sens (par exemple: cf_cfop, CF_Natop, lnom, r_procod) -

Je voudrais souligner la prudence avec le bit «renommer les variables». Il y a de fortes chances que vous ne compreniez pas encore le jargon, et les noms de variables prendront beaucoup plus de sens après que vous y soyez depuis un moment. Cela ne veut pas dire qu'il ne peut pas y avoir de noms de variables problématiques également, mais vos exemples semblent avoir une logique, si vous saviez quels sont les acronymes courants sur votre site. Ce n'est évidemment pas aussi important si vous êtes une équipe de 1.

• utilise une langue que je ne connais pas (Visual FoxPro 8 de 2002) - c'est votre problème, pas celui du code

Cela me semble être une opportunité .

Il est clair que vous pouvez déjà voir beaucoup de problèmes dans la façon dont les choses sont faites et gérées. Vous pouvez soit vous plaindre que ce sont toutes des ordures et que vous ne pouvez rien faire, OU vous pouvez utiliser cela comme une occasion en or pour vraiment montrer à votre employeur votre valeur.

Maintenant, ça ne va pas vous aider si vous montez chez votre employeur et lui dites que tout doit changer. Donc, l'astuce consiste à jouer pendant un certain temps, à poser BEAUCOUP de questions, et lorsque vous devrez écrire du code, vous devrez jouer selon leurs règles avec tous les commentaires, etc., car vous devrez garder d'autres développeurs informés en utilisant le système qu'ils préfèrent actuellement, tout en introduisant des remaniements judicieux qui ne risquent rien. Vous pouvez extraire quelques méthodes, et si votre langue le prend en charge, introduisez quelques tests unitaires. Lorsqu'on vous demande pourquoi vous l'avez fait de cette façon, ou si on vous dit que vous faites quelque chose de "mal", évitez de devenir défensif ou argumentatif tout en faisant une présentation solide de votre position pour votre style de codage préféré. Par exemple, vous pouvez vous référer à des livres tels que le code propre de Bob Martin, ou vous pouvez vous référer à d'autres livres, articles ou même questions et réponses que vous avez rencontrés sur Programmers.SE. Tout ce que vous pouvez trouver utile pour appuyer votre position avec des faits qui pourraient dépasser votre expérience aux yeux des personnes avec lesquelles vous travaillez.

En ce qui concerne les commentaires excessifs, une partie de cela peut être clarifiée si vous ajoutiez quelques noms descriptifs pour les variables et les méthodes, mais vous pourriez également être en mesure de plaider en faveur d'un bon système de contrôle de version, et en utilisant cela pour garder la trace des changements et des dates, etc., et pour l'utilisation d'un outil pour comparer les différentes versions de vos fichiers source si l'on ne vient pas déjà avec votre VCS choisi.

Comme je l'ai dit, c'est une opportunité de contribuer à l'amélioration d'une équipe de développement qui sonne comme un peu perdue pour ainsi dire. Vous avez la possibilité de vous démarquer comme compétent et compétent, et comme quelqu'un qui peut donner l'exemple. Ce sont toutes de bonnes choses pour vous aider plus tard au cours de votre carrière.

Bienvenue dans la jungle !

Malheureusement, souvent commencer à travailler dans une entreprise signifie commencer à faire face à ce genre de situations, à moins que vous ne travailliez pour une entreprise structurée et bien organisée, ces situations sont assez courantes ...

Mon conseil est:

1. Commencez à apprendre et familiarisez-vous avec: le langage de programmation utilisé (Clipper / dBase) et l'environnement (Visual FoxPro)

2. Lisez et analysez la base de code et commencez à la commenter

3. organiser / refactoriser le code (résoudre le problème de trop de lignes exécutées en séquence)

Ayant un problème face à une base de code similaire, c'est normal, mais cela peut devenir un grand défi d'essayer d'améliorer la qualité du code et de donner "votre touche" au programme en améliorant la base de code et peut-être en en faisant un meilleur programme ...

Pour répondre à votre question: Oui, les gens / entreprises partout dans le monde utilisent une infrastructure qui peut être construite sur un code merdique. Lors de votre intégration dans de telles situations, il peut être très difficile à gérer.

L'été dernier, j'ai travaillé en tant que stagiaire au développement d'une application destinée à l'équipe AQ ​​attachée à un département spécifique. L'équipe QA a utilisé de nombreux scripts autonomes (VBScript, Perl, Bash) pour exécuter des tests sur des bases de données et autres, et ils voulaient les rassembler dans une seule application. Le problème avec cela, cependant, est que ces scripts ont été utilisés ailleurs dans l'entreprise (donc les fonctionnalités principales / les noms de variables ne pouvaient pas être modifiés), et le code a été "ajouté" pendant près de 10 ans; beaucoup de merde s'était accumulée.

Voici ce que vous pouvez faire à ce sujet:

1. Demandez de l'aide: vos collègues qui ont dû regarder si ce code est probablement familier avec ses particularités. Ce qui est obtus et déroutant vous convient parfaitement. Alors demandez de l'aide!
2. Refonte autant que possible: si vous devez consulter / maintenir ce code pendant une longue période, refactorisez-le chaque fois que vous le pouvez. Même si vous exécutez une recherche et un remplacement sur un nom de variable, chaque petit geste est utile. Cette entreprise pour laquelle j'ai fait un stage l'été dernier avait un problème similaire d'utilisation de noms de variables de merde. Chaque fois que je le pouvais, je faisais passer leur code dans un peigne fin, en changeant les noms des variables, en optimisant la logique (en regroupant diverses fonctions en 1, par exemple), etc. Faites de même chaque fois que vous en avez l'occasion!

Comme c'est le cas partout, tant que les fonctionnalités externes du code fonctionnent correctement, peu importe le fonctionnement des internes.

Je vais faire quelques commentaires différents de ceux de nombreux intervenants ici. Beaucoup de mes commentaires peuvent être évidents pour vous, mais il faut quand même le dire.

• Soyez prudent de changer le code que vous ne comprenez pas, jusqu'à ce que vous le compreniez.
• Si vous travaillez dans un environnement d'équipe, avec du code sur lequel vos coéquipiers travaillent, discutez de vos modifications avec eux avant d'effectuer les modifications. Personne n'aime qu'un "tireur isolé" vienne changer le code que tout le monde connaît. Cela ne veut pas dire que vos modifications ne sont pas justifiées ou la «bonne» chose à faire.
• Faites adopter vos idées. Obtenez tout le monde à bord avec vos idées, puis vous pouvez utiliser les compétences de votre équipe pour refactoriser, au lieu de vous alourdir avec toute la charge de travail.
• Gagnez l'adhésion de la direction. Ils peuvent être en mesure d'allouer des fonds pour que vous puissiez re-factoriser le code.
• Parlez à la direction en termes de compréhension des avantages de la refactorisation de sa base de code. Un code plus facile à gérer signifie moins de temps passé à résoudre des bogues, à ajouter des fonctionnalités, etc. Ce qui signifie un développement rentable. Délai d'exécution plus rapide, etc.

Il est facile d'ajouter du codage pur et des suggestions de meilleures pratiques sans comprendre la politique de votre environnement. Les personnes avec lesquelles vous travaillez peuvent ne pas vouloir changer ou allouer du temps pour changer votre base de code, mais essayez de vendre l'idée à tout le monde avant de vous lancer et de tout changer (ce qui comporte des risques inhérents en soi)

J'espère que cela t'aides.

L'une des choses qui ressort est votre commentaire édité

Chaque changement dans l'ancien code doit être commenté dans le code, ainsi que les métadonnées (date, programmeur, tâche) liées à ce changement (cela est devenu un gâchis, il y a du code avec 3 lignes utilisées et 50 anciennes lignes commentées). Je pense que ce n'est pas seulement un problème de code, mais un problème de gestion de développement logiciel.

J'ai également un projet où j'ai hérité d'une base de code FoxPro héritée avec bon nombre des problèmes que vous décrivez. L'une des premières choses que j'ai introduites dans le projet était un bon référentiel de code source. FoxPro peut s'intégrer à SourceSafe, mais ce produit est pénible à utiliser.

J'ai récupéré une copie de l'outil scx de Paul McNett http://paulmcnett.com/scX.php et l'ai intégré à mon cycle de développement. Il fait un très bon travail d'extraction du code binaire FoxPro dans un format texte qui peut ensuite être placé dans un référentiel source, comme Subversion, Mercurial ou même git. (Vous pouvez trouver le projet SubFox sur http://vfpx.codeplex.com utile.

Ces outils fournissent l'historique et permettent aux programmeurs de poursuivre le travail de maintenance du code. Il faut certainement du temps pour apprendre à utiliser ces outils, mais comme ils sont tous gratuits, cela n'a pas vraiment de sens de ne pas y investir un peu de temps. (même si vous ne pouvez pas faire avancer les projets Job de cette façon).

Je suis fortement d'accord avec la réponse de funkymushroom. Si vous êtes un environnement d'équipe, assurez-vous que les autres savent que vous êtes refactor ou réorganiser le code, si jamais vous prévoyez d'obtenir de bonnes missions futures.

Par expérience personnelle, je sais, bien que ce ne soit pas votre style de codage, si vous maintenez le code, que d'autres modifient et maintiennent également, restez dans le style du code existant. L'ajout de commentaires et de clarifications est correct, mais la disposition et les conventions de base doivent rester. Les anciens gourous / pistolets du projet s'attendent à ce que le code soit similaire à ce qu'ils voient depuis des années.

Lorsqu'un client crie à propos d'un bogue, votre gestion ira aux anciens pistolets pour résoudre le problème le plus rapidement possible. Si ces vieux pistolets, lorsqu'ils sont sous pression, vous trouvent "nettoyé le code" et qu'ils doivent maintenant passer du temps à comprendre où vous avez déplacé ou renommé cette variable dont ils savent qu'elle doit être modifiée, votre nom dans l'entreprise sera changé en " boue".

Une fois la crise terminée, d'abord le vieux fusil vous reprochera lentement la mise à jour critique. Ensuite, vous constaterez que vous pouvez conserver le code nettoyé aussi longtemps que vous êtes dans l'entreprise. Enfin, lorsque de nouveaux projets intéressants seront disponibles, vos gestionnaires demanderont aux gourous qui devrait travailler le projet, et si vous les avez vissés une fois, vous ne pourrez jamais arriver au nouveau projet, jusqu'à ce que votre fourrage soit jeté à la fin pour respecter un délai.

Si vous avez appris au collège la «bonne» façon de coder et que vous êtes maintenant sur le marché du travail, oubliez cette «bonne» façon. Ce ne sont pas des missions collégiales, ces projets ne durent pas seulement un semestre, ils peuvent vivre pendant des années et devront être maintenus par un groupe de personnes avec différents niveaux d'expertise et différents niveaux d'intérêt pour la dernière tendance CS. Vous devez être un joueur d'équipe.

Vous pouvez être la plus grande programmation hot shot à l'école, mais sur le lieu de travail, votre premier emploi, vous êtes un débutant sans crédit de rue. Les gens qui programment depuis des années ne se soucient pas de votre école ou de vos notes, c'est à quel point vous jouez bien avec les autres et à quel point vous perturbez leur vie.

Au cours de mes 20 ans, il me semble que plusieurs programmeurs as ont été licenciés, principalement parce qu'ils exigent de faire les choses à leur “bonne” manière. À moins que vous n'apportiez quelque chose de très, très, très unique au travail, vous êtes remplaçable. Vous avez peut-être été en tête de votre classe, mais l'année prochaine, quelqu'un d'autre sera en tête de sa classe et à la recherche d'un emploi.

Je considère cela comme votre travail principal, c'est de garder votre emploi, jusqu'à ce que vous décidiez de changer d'emploi. Pour garder votre emploi, vous devez jouer bien dans la cour de récréation que quelqu'un d'autre a construit et payé.

Je sais que j'ai l'air négatif, mais il y a toujours de l'espoir. Au fur et à mesure que vous gagnez de l'expérience, que vous réussissez, vous gagnez de l'influence et vous pouvez changer les choses de manière meilleure. Lorsque vous écrivez un nouveau code ou sur un nouveau projet, appuyez sur les modifications que vous recherchez. S'il s'agit d'un nouveau code, les anciens canons ne s'attendent pas à ce que ce soit comme ils l'ont laissé, et quand ils voient les avantages, ils pourraient apprendre et adapter la nouvelle façon.

L'ancien système peut changer, mais cela prend du temps. Changer quelque chose introduit un risque et un risque de haine commerciale, et vous devez prendre du temps et travailler pour que l'entreprise soit à l'aise avec le changement.