Nous avons une situation au travail où les développeurs travaillant sur un ancien système (de base) sont poussés à utiliser des instructions GOTO lorsqu'ils ajoutent de nouvelles fonctionnalités au code existant qui est déjà infecté par du code spaghetti.
Maintenant, je comprends qu'il puisse y avoir des arguments pour utiliser "juste un petit GOTO" au lieu de passer du temps à refaire une solution plus facile à maintenir. Le problème est que ce "juste un petit GOTO" isolé n'est pas si isolé que cela. Au moins une fois par semaine, il y a un nouveau "one little GOTO" à ajouter. Cette base de code est déjà une horreur à travailler car le code datant d'avant 1984 est criblé de GOTOs qui feraient de nombreux Pastafariens Le monstre spaghetti volant a été inspiré par le monstre spaghetti volant lui-même.
Malheureusement, le langage dans lequel il est écrit ne dispose pas d'outils de refactorisation prêts à l'emploi, ce qui rend plus difficile l'idée de "Refactoriser pour augmenter la productivité plus tard", car les gains à court terme sont les seuls auxquels il est prêté attention ici...
Quelqu'un d'autre a-t-il rencontré ce problème où tout le monde est d'accord pour dire que nous ne pouvons pas ajouter de nouvelles GOTO pour sauter 2000 lignes dans une section aléatoire, mais où les Anaylsts insistent continuellement pour le faire juste cette fois-ci et pour que la direction l'approuve ?
tldr ;
Comment peut-on s'attaquer au problème des développeurs qui sont poussés (forcés) à ajouter continuellement des instructions GOTO (par ajouter, j'entends ajouter pour sauter à des sections aléatoires situées à plusieurs lignes de distance) parce que cela "fait" ? que dans "quicker" ?
Je commence à craindre que nous perdions de précieux développeurs au profit des rapaces à cause de cela...
Clarification :
Goto here
alsoThere: Non, je parle du genre de goto qui fait sauter 1000 lignes d'un sous-programme à un autre au milieu d'une boucle while. Goto somewhereClose
there: Je ne parlais même pas du genre de gotos que l'on peut raisonnablement lire et déterminer ce que faisait un programme. Goto alsoThere
somewhereClose: C'est le genre de code qui permet de faire des boulettes de viande midpoint: S'il s'agit de la première fois, Goto nextpoint detail: (chacune presque complètement différente) Goto pointlessReturn
here: Dans cette question, je ne parlais pas de l'utilisation occasionnelle d'un goto. Goto there
tacoBell: et il vient de retourner à la planche à dessin. Goto Jail
elsewhere: Lorsqu'il faut des semaines aux analystes pour décrypter ce que fait un programme à chaque fois qu'il est touché, c'est que quelque chose ne va pas du tout dans votre base de code. En fait, je suis jusqu'à mon hell: if not up-to-date goto 4 rendu de la spécification goto detail pointlessReturn: goto tacoBell
Jail: En fait, il s'agit juste d'une petite mise à jour et d'une petite victoire. J'ai passé 4 heures à refactorer une partie de ce programme particulier, un seul label à la fois, en sauvegardant chaque itération dans svn au fur et à mesure. Chaque étape (une vingtaine) était petite, logique et assez facile à mettre en oeuvre. goto bypass nextpoint: sauter spontanément de votre repas à votre écran par une sorte de magnétisme bizarre entre spaghettis et boulettes de viande. Goto elseWhere bypass: vérifier raisonnablement qu'il ne devrait pas introduire de changements logiques. En utilisant cette nouvelle version plus lisible, je me suis assis avec l'analyste et j'ai maintenant terminé la quasi-totalité de ces changements. Goto end
4: première *si première fois ici goto hell pas de second si c'est la première fois que l'on se trouve ici, on passe à l'étape suivante hell , pas de troisième si c'est la première fois que l'on se trouve ici, on passe à l'étape suivante hell quatrième maintenant à jour goto hell
end:
