Dimensionner un système legacy au-delà du nombre de lignes

Le nombre de lignes indique le volume de texte source présent. Il ne dit pas quel volume de comportement un remplacement doit préserver, combien de ramifications ce comportement peut prendre, ni quelle part du source s'exécute encore. Confondre ces quantités explique pourquoi des estimations de modernisation apparemment précises se trompent d'un facteur entier.

J'ai vu l'analyse d'un petit parc de traitements batch prendre plus de temps que celle d'une application bien plus grande, car chaque job touchait le même dossier client mutable et chaque exception apparaissait dans un rapport de contrôle imprimé. J'ai aussi vu des répertoires impressionnants se réduire brutalement après qu'une analyse d'accessibilité a révélé que des variantes retirées depuis des années étaient toujours livrées dans l'arbre source. Le décompte était exact dans les deux cas. La conclusion qu'on en avait tirée était fausse.

L'unité utile n'est pas la ligne. C'est un comportement qu'il faut découvrir, séparer de ses dépendances, implémenter et prouver équivalent. Cinq mesures rendent ce travail visible: la profondeur des décisions, le fan-in des données persistantes, la part de code mort, la surface d'intégration et la part de comportement connue uniquement par les sorties de production. Aucune ne donne seule un prix magique. Ensemble, elles décrivent la forme du système de manière défendable.

Le nombre de lignes mesure un stock, pas une réécriture

Les lignes de code répondent à une question étroite: quelle quantité de texte une règle de comptage donnée a-t-elle classée comme source? Le rapport de Robert Park pour le Software Engineering Institute, Software Size Measurement: A Framework for Counting Source Statements, consacre beaucoup d'efforts à définir précisément les lignes physiques et les instructions logiques. C'est le premier avertissement. Deux outils peuvent diverger avant même que quelqu'un ait parlé des commentaires, des copybooks générés, des macros développées, du SQL embarqué ou de plusieurs membres contenant la même routine.

Même un comptage parfaitement normalisé mesure un stock. Il peut aider à préparer l'ingestion d'un dépôt, le stockage, le débit d'un parseur ou une première comparaison sommaire entre des versions écrites dans le même langage avec les mêmes conventions. Il ne dit pas si 40 lignes réalisent une transformation directe ou une règle avec état et 16 chemins. Il ne dit pas si 4 000 lignes copiées sont actives. Il ne révèle pas non plus qu'une affectation à une colonne de statut modifie huit jobs en aval.

Le langage fausse aussi le dénominateur. Les déclarations de données COBOL peuvent rendre visuellement volumineuses les structures d'enregistrement. APL ou SQL peuvent exprimer un comportement considérable en quelques instructions. Du Java généré peut ajouter des milliers d'accesseurs répétitifs. Un ratio fondé sur les lignes traite silencieusement ces éléments comme des unités de réflexion équivalentes. Ils ne le sont pas.

Ne tentez pas de corriger le problème avec une table de conversion des langages, où une ligne COBOL vaudrait un certain nombre de lignes Go. Cette recommandation reste populaire parce qu'elle produit rapidement une feuille de calcul et ressemble aux anciens modèles de productivité. Elle échoue lors d'une modernisation, car l'architecture cible ne doit pas conserver la forme textuelle du source. Un copybook partagé peut devenir un schéma avec des clients générés. Vingt programmes batch presque identiques peuvent devenir un service et sa configuration. Un calcul dense peut rester dense en Rust, puisque ce sont les mathématiques, et non la syntaxe source, qui déterminent le travail.

Conservez le nombre de lignes dans l'évaluation, mais donnez-lui un nom honnête. Comptabilisez séparément les lignes physiques, les instructions logiques, les lignes générées, les commentaires et les duplications. Utilisez ces chiffres pour décrire le corpus. Ne laissez jamais leur somme représenter l'effort de livraison ou le risque comportemental.

La profondeur cyclomatique révèle les décisions coûteuses

La complexité cyclomatique compte les chemins indépendants dans un graphe de flux de contrôle. Thomas McCabe a introduit cette mesure dans son article de 1976, A Complexity Measure, avec l'expression issue de la théorie des graphes habituellement écrite V(G) = E - N + 2P. Elle est utile parce que les obligations de test se développent autour des décisions, pas autour de la mise en forme. La description technique publiée plus tard par le Software Engineering Institute apporte aussi une réserve importante: une valeur élevée ne prouve pas à elle seule qu'un module est risqué ou qu'il doit être reconçu.

Pour évaluer un système legacy, la distribution compte davantage que la moyenne du dépôt. Une moyenne de six peut décrire un code uniforme ou un code où la plupart des routines sont triviales tandis que quelques modules de règlement contiennent des centaines de chemins. Ces patrimoines exigent des plans différents. Présentez au minimum la médiane, le 90e centile, le maximum et la part de routines accessibles qui dépassent le seuil d'examen manuel choisi par l'équipe. Excluez les routines générées et mortes de la distribution principale, mais présentez-les à côté.

La complexité cyclomatique et la profondeur cyclomatique sont liées sans être identiques. La complexité compte des chemins indépendants. La profondeur mesure le niveau d'imbrication des décisions avant le retour du contrôle à un niveau plus simple. Une table de répartition plate avec 30 cas peut avoir une complexité élevée tout en restant facile à découper. Cinq conditions imbriquées qui dépendent de mutations antérieures peuvent avoir moins de chemins, mais être plus difficiles à expliquer, tester et déplacer. Les équipes confondent souvent les deux, puis s'étonnent qu'un module au score acceptable consomme tout le budget de revue.

Mesurez les deux pour chaque routine accessible. Pour la profondeur, comptez les conditions, boucles, exceptions et constructions de branchement propres au langage qui sont imbriquées, après développement du prétraitement qui modifie le flux de contrôle. Examinez ensuite les routines élevées sur l'un des deux axes. L'examen doit répondre à quatre questions: la branche dépend-elle d'un état persistant? Modifie-t-elle des données réutilisées plus tard dans la même transaction? La condition est-elle dupliquée ailleurs? Les entrées enregistrées peuvent-elles exercer les deux résultats?

N'additionnez pas tous les scores de complexité en un nombre géant. Une somme récompense la division d'une routine sans réduire les décisions réelles du système, et elle masque leur concentration. Utilisez une carte thermique ou un tableau classé qui conserve l'identité du module, le contexte d'appel et les données touchées. Une estimation de réécriture doit savoir où les décisions sont couplées, pas seulement combien d'éléments de décision un parseur a trouvés.

La complexité détermine aussi le travail de preuve. Une routine linéaire peut n'exiger que des cas limites représentatifs. Une routine profondément imbriquée qui choisit des tarifs, des taxes ou des résultats d'éligibilité demande une matrice de cas observés et construits. Cela ne veut pas dire que chaque chemin mathématique mérite son propre test. Certains chemins sont impossibles, et la validation en amont exclut certaines combinaisons. Cela signifie que l'estimation doit financer le travail qui prouvera quels chemins comptent, au lieu de supposer que le nombre de lignes les a déjà capturés.

Le fan-in des données montre le véritable rayon d'impact

Le fan-in mesure combien d'appelants ou de flux convergent vers un composant. Sur les systèmes legacy, le fan-in au niveau du code est utile, mais celui de la couche de données est souvent plus révélateur. Comptez les programmes déployés séparément, les jobs, les écrans, les rapports, les procédures stockées, les flux de fichiers et les outils opérateur qui lisent ou écrivent chaque enregistrement persistant, table, fichier, file de messages ou zone de données partagée.

La distinction entre fan-in en lecture et en écriture compte. Cinquante rapports qui lisent un journal uniquement alimenté par ajout créent du travail de migration et de compatibilité, mais un seul job de rapprochement qui écrit dans l'historique peut imposer une contrainte de bascule bien plus dure. La responsabilité mixte est pire: une transaction en ligne met à jour un dossier maître, un batch nocturne le corrige et un outil opérateur peut écraser un champ lors d'une exception. Un schéma de données montre l'objet partagé. Il ne montre ni l'ordre, ni l'autorité, ni la raison opérationnelle de ces écritures.

Commencez par les références statiques, puis rapprochez-les des preuves d'exécution. L'analyse statique peut résoudre le SQL direct, les noms de fichiers connus, l'usage des copybooks et les appels littéraux. Elle manquera le SQL dynamique, les noms assemblés dans des variables, les substitutions du planificateur, les alias, les exits et les accès réalisés par des outils hors du dépôt. Les journaux d'audit de base de données, les logs de jobs, les métadonnées de messages et l'historique du catalogue de fichiers révèlent une partie de ce fan-in absent. Les entretiens peuvent ajouter les outils opérateur, mais traitez un souvenir comme une piste jusqu'à ce qu'une preuve le confirme.

Classez les actifs de données selon davantage que le nombre brut de références. Séparez les lecteurs des rédacteurs, les accès en ligne des batchs et les mises à jour synchrones des mises à jour différées. Notez si une frontière transactionnelle couvre plusieurs actifs. Marquez les champs dont le sens change selon le programme, comme un statut vide interprété comme «en attente» par un job et comme «sans objet» par un autre. Ces conflits sémantiques créent plus de travail qu'une table propre avec de nombreux lecteurs ordinaires.

Un relevé de fan-in utile peut rester compact:

asset,readers,writers,execution_modes,transaction_peer,observed
CUSTOMER-MASTER,14,4,online|batch,ADDRESS-HISTORY,yes
RATE-CONTROL,6,1,batch,none,no
CLAIM-QUEUE,3,3,online|operator,PAYMENT-FILE,partial

La dernière colonne est volontaire. Une référence statique et un accès observé constituent deux affirmations différentes. Conservez-les toutes les deux. Si une estimation les fusionne, une référence jamais exécutée peut gonfler le périmètre tandis qu'un accès dynamique invisible peut disparaître.

Un fan-in élevé ne signifie pas automatiquement «réécrire en premier». Il signifie souvent le contraire. Un actif de données très partagé peut exiger une frontière de compatibilité explicite, un transfert progressif de responsabilité ou une période de coexistence entre anciens et nouveaux composants. La mesure change l'ordre des travaux parce qu'elle montre où une modification localement correcte peut encore casser le système.

Le code mort modifie le dénominateur

La part de code mort est la portion du corpus qui ne peut pas s'exécuter dans la configuration de production définie. Elle doit réduire le périmètre d'implémentation, mais seulement après que l'équipe a prouvé pourquoi ce code est mort. Supprimer un répertoire parce que personne ne s'en souvient ne constitue pas une analyse.

Utilisez trois étiquettes. Le code inaccessible ne possède aucun chemin depuis un point d'entrée configuré. Le code non observé possède un chemin possible, mais ne s'est pas exécuté pendant la période d'observation. Le comportement retiré fait l'objet d'une décision approuvée par son responsable et le remplacement ne le préservera pas. Ces étiquettes ne se remplacent pas. La documentation IBM sur l'identification du code COBOL inaccessible précise que le résultat provient d'une analyse statique et ne reflète pas le chemin d'exécution réel. Cette limite explique précisément pourquoi les preuves statiques et dynamiques doivent rester séparées.

La configuration définit l'accessibilité. Un module inutilisé dans le planning des jours ouvrés peut s'exécuter à la clôture trimestrielle. Une transaction CICS peut être désactivée dans une région et active dans une autre. Des membres JCL peuvent être sélectionnés par des variables du planificateur. Un exécutable de bureau peut charger un plugin nommé dans un fichier de configuration local qui n'a jamais rejoint le contrôle de version. Construisez l'ensemble des points d'entrée à partir des plannings de production, définitions de transactions, manifestes de déploiement, procédures de commande, jobs enregistrés et guides opérateur, pas seulement à partir d'un graphe d'appels enraciné dans le programme principal évident.

Calculez ensuite plusieurs parts: instructions statiquement inaccessibles, instructions accessibles mais non observées, instructions accessibles dupliquées et comportement dont le retrait a été approuvé. Attribuez à chacune un niveau de confiance et une référence de preuve. L'estimation ne doit exclure que la part retirée. Le code inaccessible dont la configuration reste incertaine va dans une file de résolution, tandis que le code non observé nécessite encore des tests ciblés ou une décision métier.

Le code mort peut malgré tout contenir des indices utiles. Une ancienne branche peut expliquer l'encodage d'un champ ou la mise en page d'un rapport qui subsiste ailleurs. Conservez le source et le relevé d'analyse même si le nouveau système omet le comportement. L'erreur consiste à payer la traduction de routines mortes comme si elles étaient des exigences. L'erreur inverse consiste à les effacer avant que l'équipe ait compris les contrats actifs qui se sont développés autour d'elles.

La surface d'intégration se compte en contrats

Une intégration n'est pas une simple case sur un schéma d'architecture. C'est un contrat avec un transport, une forme de données, une règle horaire, un comportement en cas d'erreur, une frontière de responsabilité, un mécanisme de sécurité et une procédure de reprise. Comptez ces contrats, puis mesurez leurs différences.

Un seul fichier nocturne à largeur fixe peut coûter plus cher à reproduire que dix endpoints HTTP ordinaires. Le fichier peut imposer un nom exact, un jeu de caractères, une longueur d'enregistrement, un ordre de tri, un total de contrôle, une fenêtre d'arrivée, une convention de relance et un accusé manuel. Le destinataire peut lire des octets de remplissage non documentés. Rien de cela n'apparaît dans un nombre de lignes. Une grande partie peut même être absente du programme émetteur, car le planificateur, le produit de transfert et la procédure opérateur portent une partie du comportement.

Inventoriez chaque bord externe et chaque bord interne qui franchit une frontière de responsabilité ou de déploiement. Incluez les bases de données détenues par une autre équipe, les fichiers entrants et sortants, les files de messages, les appels de procédure distants, les protocoles de terminal, les e-mails, les sorties d'imprimante, les fournisseurs d'identité, les interfaces matérielles, les feuilles de calcul utilisées comme modèles d'import et les transmissions manuelles déclenchées par un rapport. Ne fusionnez pas cinq fichiers sous «flux partenaire» s'ils suivent des calendriers ou des traitements d'erreur différents.

Pour chaque contrat, relevez le sens, le protocole, l'emplacement du schéma, la fréquence, le profil des pointes, l'ordre, l'idempotence, la règle de nouvelle tentative, le délai d'expiration, l'authentification, le chiffrement, le producteur, le consommateur, l'environnement de test et un échantillon capturé en production. «Inconnu» est une valeur légitime. C'est aussi du travail. Une cellule vide ne doit jamais devenir silencieusement l'hypothèse que la valeur par défaut de la cible correspondra.

La surface d'intégration possède deux scores utiles. Le nombre de contrats mesure son étendue. La nouveauté des contrats mesure combien de mécanismes différents l'équipe doit reproduire ou remplacer. Vingt fichiers qui partagent un générateur et un protocole d'accusé peuvent former une seule famille d'implémentation. Quatre interfaces utilisant une file mainframe, un flux de contrôle d'imprimante, un mécanisme propriétaire d'automatisation du poste et un partage monté manuellement créent quatre problèmes de découverte et de test.

Accordez une attention particulière au comportement négatif. Des consommateurs peuvent dépendre d'un fichier vide, d'un code retour précis, d'une nouvelle tentative retardée, d'une livraison en double ou de l'absence d'une ligne. Les échantillons de succès capturent rarement ces contrats. Rassemblez les logs d'échec et les historiques de relance. Demandez aux opérateurs ce qu'ils font lorsque l'artefact attendu n'arrive pas. Leur action fait souvent partie du système alors qu'aucun compilateur ne peut la voir.

La sortie de production peut être la seule spécification

Certains comportements legacy n'existent que dans ce que produit la production. Le code les calcule, les utilisateurs et systèmes en aval en dépendent, mais aucune exigence actuelle ne les explique. Cet écart mérite sa propre mesure, car il modifie le travail de découverte et de vérification.

Commencez par compter les surfaces comportementales: réponses d'API, modifications de base de données, fichiers, messages, champs d'écran, rapports imprimés, traces d'audit, codes retour, événements temporels et invites opérateur. Pour chacune, classez la source de spécification comme documentation actuelle, tests exécutables, déduction du code, confirmation métier ou observation de la production. Plusieurs sources peuvent s'appliquer. La catégorie dangereuse est «production seulement»: aucun document fiable ni test ne définit le résultat, et les utilisateurs jugent la correction en comparant avec ce que produit l'ancien système.

«Production seulement» ne signifie pas que le mystère doit durer. Capturez des paires représentatives d'entrées et de sorties, normalisez les champs variables comme les horodatages ou identifiants générés, puis rejouez si possible les entrées sur l'ancien système dans des conditions contrôlées. Préservez l'ordre, les arrondis, l'encodage, le traitement des blancs et les sorties d'erreur avant que quelqu'un ne les «nettoie». Un espace final peut être insignifiant dans un rapport et délimiter un champ dans un autre.

Mesurez ce point comme une part pondérée, pas comme un simple nombre de sorties. Donnez plus de poids aux sorties qui déplacent de l'argent, clôturent des comptes, pilotent un travail physique, répondent à une revue d'audit ou alimentent un autre système. Relevez aussi la couverture: variété des entrées, variété calendaire et comportements d'erreur présents dans le trafic capturé. Trente jours de requêtes en ligne peuvent couvrir les chemins ordinaires tout en ratant le traitement de fin d'année. Un million de contrôles de santé répétés n'apporte presque aucune connaissance comportementale.

C'est ici que l'estimation et la vérification se rejoignent. Si le comportement est documenté et testé, l'équipe de remplacement peut implémenter un contrat explicite. S'il n'existe que dans les sorties, l'équipe doit découvrir le contrat, construire un comparateur, classer les différences et obtenir une décision lorsque l'ancien comportement est incohérent. Ce travail existe même si la routine responsable ne compte que 80 lignes.

Le trafic enregistré constitue une preuve, pas un oracle. Il peut contenir de mauvais résultats, des défauts masqués, des données sensibles et des dépendances accidentelles. Appliquez des contrôles d'accès et la minimisation des données, repérez les champs qui ne peuvent pas quitter le périmètre du client et demandez à un responsable désigné si un écart révèle une régression ou un ancien défaut à retirer. Une parité automatisée sans ce processus de décision peut préserver les erreurs avec une précision impressionnante.

Un profil de taille garde les risques distincts

Combinez les mesures dans un profil, pas dans un score pondéré universel. Un seul nombre semble pratique, mais détruit les informations nécessaires pour choisir l'architecture, ordonner le travail et fixer la profondeur de vérification. Deux systèmes peuvent recevoir le même score alors que l'un concentre une logique de décision et l'autre place du code simple derrière des dizaines d'interfaces fragiles.

Le profil doit contenir plusieurs relevés reliés pour la configuration de production évaluée. Le relevé du corpus contient les instructions logiques ainsi que les parts par langage, génération, duplication et commentaires. Le relevé des décisions contient la complexité et l'imbrication maximale, avec la médiane, le 90e centile, le maximum et les points chauds accessibles. Le relevé de concentration des données contient les lecteurs et rédacteurs par actif, les autres actifs de la transaction, les modes d'exécution et les accès observés.

Le relevé d'accessibilité contient les parts retirées et non résolues, avec les racines statiques, la période d'exécution et les décisions des responsables. Le relevé des contrats contient les interfaces distinctes, les familles de mécanismes, les échantillons d'échec et l'accès aux tests. Le relevé des preuves comportementales contient les surfaces pondérées connues uniquement par la production, la variété des entrées capturées, les lacunes calendaires et la personne chargée de décider sur les écarts. Conservez des identifiants stables entre ces relevés afin qu'un examinateur passe d'un point chaud à sa preuve sans rapprocher manuellement des descriptions.

Versionnez le profil avec les points d'entrée, le jeu de configurations, la période d'observation, les versions des outils et les exclusions. Sans cela, un scan ultérieur peut sembler contredire l'évaluation alors qu'il a simplement utilisé d'autres racines du planificateur ou développé les copybooks différemment.

Utilisez des bandes plutôt qu'une fausse précision. Pour la profondeur des décisions, une bande peut distinguer les routines ordinaires, les points chauds à examiner et les candidats à la décomposition. Pour le fan-in des données, elle peut séparer les actifs isolés, les modèles partagés en lecture et les responsabilités d'écriture contestées. Définissez chaque bande par une action. Une cellule rouge doit signifier «exige une frontière de compatibilité et la revue du responsable», pas «semble inquiétant».

Le profil rend aussi l'incertitude visible. Indiquez si chaque valeur vient d'une analyse statique, d'une observation d'exécution, de dossiers de configuration ou d'une décision du responsable. Ajoutez une référence de preuve et un niveau de confiance. Une règle inconnue de nouvelle tentative d'intégration et un décompte exact de 200 000 lignes ne doivent pas se fondre dans une moyenne rassurante. L'inconnue peut dominer le risque de bascule.

Conservez les observations brutes à côté des valeurs dérivées. Si un analyseur trouve 26 appelants tandis que les données d'exécution en montrent 19, gardez les deux nombres et l'état du rapprochement. Un travail ultérieur peut prouver que cinq appelants appartiennent à des plannings retirés et que deux appels sont des alias dynamiques. Remplacer le premier chiffre détruit la piste d'audit et rend l'estimation plus certaine que ne l'a jamais été l'évaluation. La même règle vaut pour la normalisation de la complexité, la détection des duplications et la couverture du trafic.

Pour estimer, transformez les éléments du profil en lots de travail assortis de conditions d'achèvement observables. Un point chaud de décision est terminé lorsque sa table de comportement, son implémentation et ses cas de parité sont acceptés. Un actif de données est terminé lorsque la responsabilité, le comportement transactionnel, la règle de migration et les consommateurs sont pris en compte. Une intégration est terminée lorsque les succès, les erreurs, les nouvelles tentatives et la transmission aux opérations fonctionnent dans l'environnement cible. Une surface connue uniquement par la production est terminée lorsque les cas capturés correspondent ou qu'un responsable approuve chaque différence voulue.

Ainsi, les multiplicateurs restent locaux. Une routine très complexe affecte le lot de travail auquel elle appartient. Elle ne rend pas arbitrairement chaque transfert de fichier et chaque écran deux fois plus cher. Un rapport mal spécifié ajoute du travail de découverte et de comparaison à cette surface de sortie. Il ne gonfle pas le code mort. Les facteurs locaux se contestent, se révisent et se vérifient plus facilement.

Estimez les unités de preuve, pas les nouvelles lignes

Une fois le profil établi, estimez les unités de comportement préservé et de preuve. Commencez par les fonctions accessibles, puis séparez-les là où la responsabilité des données, les contrats d'intégration ou les méthodes de vérification diffèrent. Le nombre de lignes de la cible est inconnu et largement sans intérêt. Le travail d'architecture peut supprimer les répétitions, réunir des programmes ou remplacer une plomberie procédurale par des fonctions de plateforme.

Pour chaque unité, estimez quatre activités: découverte, conception et implémentation de la cible, construction des preuves et acceptation. La découverte comprend la résolution des appels dynamiques, des structures absentes, des responsables et des règles connues uniquement en production. La construction des preuves comprend la capture du trafic, les jeux de données, les comparateurs et les cas d'échec attendus. L'acceptation comprend l'examen des différences par une personne autorisée à décider si l'ancien comportement reste exigé.

Ne cachez pas l'incertitude dans un chiffre d'effort plus grand. Tenez un registre des hypothèses avec un test et un responsable. «RATE-CONTROL n'a aucun rédacteur interactif» peut être testé avec les journaux d'accès et une revue opérateur. «Tous les jobs de clôture trimestrielle figurent dans l'export du planificateur» peut être vérifié contre l'historique d'exécution. Résolvez tôt les hypothèses à fort impact, car elles peuvent modifier les frontières, et pas seulement les heures.

Une comparaison chiffrée rend le point concret. Le système A compte 700 000 instructions logiques, 45 pour cent de comportement retiré avec approbation, une profondeur de décision modérée, deux centres de données fortement écrits et six familles d'intégration avec des cas d'échec capturés. Le système B compte 180 000 instructions, presque aucun comportement retiré, plusieurs routines de règlement profondément imbriquées, neuf actifs de données à responsabilité contestée et des sorties dont les règles n'existent que dans les rapports de clôture mensuelle. Une estimation par lignes rend A presque quatre fois plus grand. Un profil comportemental peut raisonnablement montrer que B porte davantage de découverte et d'acceptation. Le profil ne prouve pas le prix. Il montre pourquoi le prix doit suivre les preuves plutôt que le volume de texte.

Cette méthode rend aussi les estimations des prestataires comparables. Demandez à chaque candidat ses points d'entrée comptés, sa classification d'accessibilité, sa distribution de complexité, ses actifs à fort fan-in, son inventaire des contrats, ses surfaces connues uniquement en production et ses hypothèses non résolues. Si l'un fournit un multiplicateur de lignes et l'autre identifie les neuf actifs aux rédacteurs concurrents, vous voyez qui a examiné le système et qui a chiffré un récit.

CodeHero lit l'ensemble de l'arbre source en parallèle, puis vérifie le comportement modernisé sur le trafic de production enregistré avec un banc de parité. Cette combinaison traite l'échelle du corpus et la preuve comportementale comme deux problèmes distincts. Cette distinction compte davantage que toute promesse sur le nombre de lignes qu'un outil peut ingérer.

L'approbation doit suivre la piste de mesure

Une estimation crédible d'un système legacy permet à un autre ingénieur de remonter du périmètre aux preuves. Pour chaque grand lot de travail, vous devez pouvoir retrouver les points d'entrée qui l'atteignent, les décisions qu'il contient, les données qu'il lit ou écrit, les contrats qu'il traverse et les exemples de production qui définissent son acceptation.

Avant d'approuver un plan, demandez ce que l'analyste a exclu et sous l'autorité de qui. Demandez quelles périodes d'exécution l'observation a couvertes, y compris les chemins de fin de trimestre ou d'année. Demandez les plus gros points chauds de complexité plutôt qu'une moyenne. Demandez quels actifs de données ont plusieurs rédacteurs. Demandez quelles interfaces manquent d'échantillons d'échec. Demandez quelles sorties n'ont aucune spécification au-delà de la production. Une réponse directe peut contenir de l'incertitude. Une confiance vague doit arrêter l'approbation.

Le nombre de lignes garde sa place sur la première page, car il décrit la matière analysée. Il doit se trouver à côté des parts de code mort et généré, pas au-dessus des mesures qui décrivent le comportement. L'estimation doit changer lorsqu'un rédacteur caché apparaît, lorsqu'un job supposé mort se révèle actif ou lorsqu'une sortie manque d'exemples. Si elle change seulement quand quelqu'un trouve un autre répertoire de fichiers source, le modèle mesure un stock et l'appelle travail d'ingénierie.

Le premier livrable qui mérite d'être payé est le profil de taille versionné avec son registre de preuves. Il donne une base concrète aux décisions d'architecture et commerciales, et fournit à l'équipe de remplacement une définition de fini qui résiste à la production.