Suivre les progrès de la mondialisation

Question

Avec notre prochaine version majeure, nous cherchons à mondialiser notre application ASP.Net et on m'a demandé de réfléchir à un moyen de garder trace du code qui a déjà été travaillé dans cet effort.

Je pensais utiliser un attribut personnalisé et le placer sur toutes les classes "corrigées".

Qu'en penses-tu?

Quelqu'un a-t-il une meilleure idée?

Answer 1

L'utilisation d'un attribut pour déterminer les classes qui ont été globalisées nécessiterait alors un outil de traitement du code et les classes qui ont été et n'ont pas été "traitées", il semble que cela devienne un peu compliqué.

Un processus de suivi de projet plus traditionnel serait probablement meilleur - et ne "polluerait" pas. votre code avec des attributs / autres balises qui n’ont aucune signification fonctionnelle au-delà de la fin du projet de globalisation. Pourquoi ne pas créer un défaut pour chaque classe qui nécessite du travail et le suivre de cette manière?

Answer 2

Pourquoi ne pas simplement compter ou lister les classes puis travailler classe par classe? Même si un attribut peut être une idée intéressante, je le considérerais comme trop sophistiqué. La globalisation ne fait rien de plus que, bien, parcourir chaque classe et globaliser le code:)

Vous voulez quand même finir avant la prochaine version. Alors allez-y et faites-le un à un, et là vous avez vos progrès. Je considérerais trop un défaut soulevé pour chaque classe.

Dans mon dernier projet, j’ai commencé la globalisation un peu tard. Je viens de parcourir la liste des fichiers de code, de haut en bas. Alphabétiquement dans mon cas, et dossier après dossier. Donc, je devais toujours me souvenir du dernier fichier sur lequel j'avais travaillé. Cela a plutôt bien fonctionné pour moi.

Éditer: Autre chose: dans mon dernier projet, la globalisation impliquait principalement de déplacer des chaînes codées en dur dans des fichiers de ressources et de générer à nouveau tout le texte lorsque la langue changeait à l'exécution. Mais vous devrez aussi penser à des choses comme les formats numériques, etc. FxCop de Microsoft m'a aidé dans cette tâche, car il marque toutes les conversions de nombres, etc. sans spécifier de culture comme violation. FxCop en assure le suivi. Ainsi, lorsque vous résolvez une telle violation et réexécutez FxCop, la violation est signalée comme manquante (c'est-à-dire résolue). C'est particulièrement utile pour ces choses difficiles à voir.

Answer 3

Pourquoi ne pas écrire un test unitaire pour chaque page de l'application? Le test unitaire chargerait la page et effectuerait une

foreach (System.Web.UI.Control c in Page.Controls)
{
    //Do work here
}

Pour la partie travail, chargez différents paramètres de globalisation et vérifiez si la propriété .Text (ou la propriété pertinente pour votre application) est différente.

Mon hypothèse serait qu'aucune langue ne devrait sortir pareil dans tous les cas sauf les plus simples.

Utilisez l'ensemble de tests unitaires qui ont été effectués avec succès pour suivre vos progrès.