Comment déterminer les dépendances pour toutes les unités? (Estimer le coût de refactoring)

Question

Malheureusement, j'ai hérité d'un morceau de conception malchanceux basé sur un "enfer" {$IFDEF}.

Ce que je ressemble à peu près comme ça (où MyDbSystemB est ce que je veux ajouter)

unit MyTable; 

interface 
uses 
    // ... 
{$IFDEF MyDbSystemA} 
    DbSystemA , 
{$ENDIF} 
{$IFDEF MyDbSystemB} 
    DbSystemB , 
{$ENDIF} 

type 
    TMyTable = class(
     {$IFDEF MyDbSystemA} 
      TSystemATable 
     {$ENDIF} 
     {$IFDEF MyDbSystemB} 
      TSystemBTable 
     {$ENDIF} 
    ) 
    // A public interface implementation 
    end; 
implementation 
    // ... 
end. 

Un certain nombre d'unités de référence TMyTable, mais elles reposent sur des fonctions spécifiques fournies avec TSystemATable:

unit oldUnit; 

interface 
    uses MyDbTable; 

type 
    TXy = class(TXyz) 
    public 
     procedure Foo(); 
    end; 

implementation 

procedure TXy.Foo(); 
var 
    table : TMyTable; 
begin 
    table := TMyTable.Create(); 
    table.SomeSystemASpecificFunction; 
end; 

J'aimerais trouver toutes ces références dans une seule vérification de référence/syntaxe. Mais comme je lis ici ce n'est apparemment pas vraiment possible

• Find all compilation errors in a Delphi project.

Quelle serait la meilleure stratégie pour trouver ces fichiers pour estimer les efforts de portage?

• Un simple fichier grep sur tous *.pas fichiers (il peut y avoir beaucoup de morts, soit le code, ou tout simplement des choses mal découplé)?

• Je suis également en mesure de fournir une implémentation de remplacement de

  TMyTable = class({ ... like above }) 
      {$IFDEF MyDbSystemB} 
  public 
      procedure SomeSystemASpecificFunction; deprecated; 
      {$ENDIF} 
  end; 
  

  avec la mise en œuvre de TMyTable, mais je aurais besoin d'estimer le coût de refactoring pour le faire correctement de toute façon. En ce qui concerne ce que je pourrais également ajouter un attribut deprecated avec le substitut SomeSystemASpecificFunction, cela me donnera au moins des avertissements.

Answer 1

Si vous connaissez les noms des membres de ce code TMyTableA prend une dépendance puis utilisez Rechercher dans les fichiers ... (ou votre outil alternatif grep -comme favori) pour identifier les références à ces membres les fichiers de votre projet.

Ceci est susceptible d'être plus fiable que toute vérification basée sur la compilation de toute façon.

Tous les outils qui prétendent trouver «toutes les erreurs de compilation dans un projet» vous mentent le plus souvent car il n'y a pas de façon fiable de distinguer les erreurs qui ne sont pas apparues suite à une autre erreur antérieure. compilation.

par exemple. dans une solution C#, il est assez courant qu'un simple changement entraîne des dizaines sinon des centaines d'erreurs de compilation qui sont corrigées en ne résolvant que la première erreur première.

c.-à-d. Le compilateur signale (par exemple) 224 erreurs alors qu'en réalité il n'y a qu'une erreur avec 223 erreurs comme effet secondaire. Pour la même raison, vous ne pouvez pas être sûr que la liste des erreurs contient toutes les erreurs authentiques que vous pourriez éventuellement découvrir.Dans certains cas, le compilateur peut être vaincu au point de ne même pas essayer de compiler du code contenant les erreurs que vous recherchez, en conséquence de ces erreurs d'effets secondaires. Certes, dans la liste des dizaines ou des centaines d'erreurs, vous pourriez alors trouver grep pour trouver celles qui semblent être candidates aux erreurs «authentiques» que vous recherchez (c.-à-d. être impliqué dans votre changement). Mais tout ce qu'il fait est de changer l'ensemble de données que vous recherchez pour localiser ces références. c'est-à-dire la liste des erreurs de compilation plutôt que les sources de votre projet.