2010-11-18 47 views
5

Je dois effectuer un grand changement à une base de code qui consiste en une poignée de différents types de changements qui doivent être appliqués dans des centaines d'endroits différents, répartis sur des centaines de milliers des lignes. J'ai une idée d'un outil qui peut m'aider avec cela, mais comme je suis sûr que je ne suis pas le seul à avoir cette idée, je me demande si c'est déjà écrit.Outil de révision de code pour la préparation d'un grand changement de base de code

Permettez-moi de décrire comment cela fonctionnerait:

  • D'abord, un peu comme grep avec le contexte, il recueillerait un ensemble de morceaux de code « intéressantes » à partir d'une expression régulière; il peut y avoir des milliers de ces endroits. Puis, permettez-moi de parcourir les morceaux, en les marquant chacun comme intéressants ou inintéressants. Cela consiste essentiellement à automatiser autant que possible le travail manuel consistant à réduire les emplacements de changement potentiels aux emplacements de changement réels.
  • Enfin, permettez-moi d'appliquer une transformation (par exemple substitution sed-style) à tous les emplacements intéressants sélectionnés.

Cet outil existe-t-il déjà?

Je pense à écrire cet outil moi-même si je ne trouve pas d'outil préexistant.

+2

Si vous ne trouvez pas d'outil approprié, vous devez en construire un vous-même. Ce serait merveilleux si vous l'avez ouvert. Il y a eu beaucoup d'endroits où j'aurais aimé avoir un outil similaire à ce que vous proposez. – sdolan

Répondre

1

Cela semble similaire à ce que Coccinelle a été écrit pour le faire, même si elle ne fonctionne qu'avec C.

+0

C'est intéressant, mais je pense que l'approche de Coccinelle est probablement trop structurée pour être pratique; en d'autres termes, il essaie d'automatiser trop, mais la complexité apparaît de l'autre côté en écrivant les patches sémantiques. Étant donné que l'ensemble de modifications n'a pas besoin d'être réutilisable, je pense qu'il est préférable de faire des choix manuels pragmatiques et ponctuels là où cela est logique. –

1

Je ne suis pas au courant des outils comme ça. Cela semble être une tâche assez spécialisée qui ne se fait qu'une seule fois depuis longtemps, et il est donc difficile de gagner de l'argent en développant et distribuant un tel outil. Par le passé, si j'avais une tâche comme celle-là, j'écrirais un script dans la version de Lisp d'Emacs. L'avantage est que Lisp est un langage puissant, et l'éditeur Emacs possède de nombreuses fonctions intégrées pratiques (par exemple, query-replace-regular-expression) et des concepts. Cependant, à moins que vous ne connaissiez déjà Emacs et Lisp, je ne le recommanderais pas; la courbe d'apprentissage est trop raide.

+0

L'outil que j'ai à l'esprit serait un travail de piratage de 200 lignes pour minimiser le temps de travail total (création d'outils + refactoring), plutôt qu'un produit poli. query-replace-regular-expression n'est pas beaucoup plus que la commande de sed; en premier passage, mon outil va probablement extraire des morceaux à modifier en un gros fichier texte, réduit manuellement, puis modifié avec sed, awk etc., puis réintégré avec les originaux. –

1

Sons intéressants. J'ai aussi joué avec une telle idée mais je n'étais pas loin des scripts en ligne de commande. Mon approche pour la préparation de refactorisation est:

  1. Trouver un chunc de code pour être remaniée avec
  2. Generate reg exp/script pour trouver un code similaire/modèle et créer une liste de l'emplacement pour ce type de motif

Le fichier de sortie contient des lignes GNU ou MS format de sortie (par exemple: fICHIER: MESSAGE eN lIGNE) Ainsi, il peut être chargé dans tous les IDE (de vim -q) et le code-morceaux peuvent être trouvés facilement en double-cliquant sur "Message d'erreur s ". Par ailleurs, il est plus facile de grep, si le code a été unifié par indent précédemment.

1

Il semble que vous envisagiez de le faire en utilisant hueristics ("grep") pour trouver votre code, et heuristiques ("sed") pour modifier votre code. Si ceux-ci vont faire l'affaire, et vous pouvez vraiment le faire en 200 lignes comme vous le dites, je suis surpris que vous avez même demandé ici SO.

En règle générale, effectuer des centaines de modifications à l'aide d'heuristiques est plutôt dangereux. Si une personne est impliquée dans chacun d'entre eux, il peut corriger les erreurs dans la mesure où il les remarque et cela peut être suffisant; dans ce cas, vous construisez juste un éditeur de texte drôle. Si vous allez dans cette direction, EMACS peut être un très bon choix, car toutes les actions que vous voulez (recherche de chaîne, extraction-à-tampon-pour-affichage, remplacement de chaîne, construction de structures de données de marqueur sur le côté) sont complètement scriptables dans Elisp et il a déjà une belle interface utilisateur.

Si vous voulez automatiser cela de façon plus fiable, vous avez besoin d'une recherche et d'un remplacement précis. Notre DMS Software Reengineering Toolkit est un outil de transformation de programme qui peut le faire pour de nombreux langages largement utilisés (vous n'avez pas dit lequel vous faisiez) y compris Java, C++, C, C#, COBOL, ... DMS peut également être entièrement scripté ensembles d'actions personnalisés.

+0

Eh bien, je peux le faire en moins de 200 lignes, mais il devient progressivement plus difficile d'écrire succinctement, et implique plus d'étapes manuelles :) - revoir la sortie de grep -n -C 10 redirigé vers un fichier texte, puis post-traitées dans un diff, et enfin appliqué avec patch. Mais une interface visuelle conçue autour de ce type de workflow - et c'est un problème de workflow par nature - rendrait la vie beaucoup plus facile. L'automatiser n'est pas le but; toute la question est la répétitivité de l'examen de chaque cas individuel. –