Dans quelques endroits dans notre code, nous utilisons # des blocs de débogage pour simplifier le développement. Des choses comme: ou p> Il y a aussi quelques endroits où nous faisons des changements cosmétiques comme celui-ci: P> #if DEBUG
background = humorousImage.jpg
#else
background = standardColor
#endif
7 Réponses :
Idéalement, je pense que vous déplaceriez ces paramètres dans les fichiers de configuration et conserveriez les directives de débogage #IF pour les tests, la journalisation et les "débogage" supplémentaires. N'oubliez pas non plus que le client est confronté à un code que vous avez besoin de fournir une construction «debug» pour se comporterait désormais complètement différent. Mes deux cents.
Bien entendu, une construction «debug» pourrait être aussi simple que d'émettre une sortie de débogueur dans la version de version. Je penserais que la raison principale de ne pas le faire est que la version de libération pourrait contenir des bugs qui n'existent pas dans la construction de débogage.
Je ne peux pas dire que c'est quelque chose que je tiens à faire, personnellement - je travaille dans un environnement où notre application principale (déployée sur 400 utilisateurs) a 60 modules - et avec 5 développeurs travaillant sur les projets et Libérer des modules, vous savez simplement que, plus tôt que quelqu'un, une personne libère accidentellement un module de débogage. :)
D'accord! Peu importe à quel point vous êtes soigné - finalement, cela pourrait voir la lumière du jour afin que cela ne vaut pas la peine de le risquer.
On dirait que vous avez besoin d'une construction automatisée, vous ne publiez pas de fichiers construits sur le poste de travail de Dev individuel.
Très vrai - ça a été sur les cartes depuis un moment, Joe!
Le problème avec cela est que cela vous rend beaucoup moins susceptible de trouver des bugs dans le En général, vos constructions de débogage devraient être aussi semblables que possible à votre version de votre version. #else .
La première utilisation valide que j'ai eue pour un bloc conditionnel #Ifl:
Nous avons un nouveau système de licence / activation. Nous en avons besoin de l'inadaptation pour le débogage local, mais je ne veux pas utiliser de paramètre de configuration pour le désactiver - alors l'utilisateur pourrait contourner le système en modifiant le fichier de configuration!
donc, nous utilisons une compilation conditionnelle Bloc: espère que cela aide à peindre la photo un peu plus .!
Vous devriez essayer de garder l'environnement en direct et l'environnement de développement aussi semblable que possible, évitez donc de disposer de deux versions du code.
Une utilisation valide du #if debug construct est de Mettez des chèques supplémentaires dans le code, qui n'est pas nécessaire dans le produit final:
@Je: Oui, pour cet exemple simple, mais vous voudrez peut-être vérifier quelque chose qui nécessite un code plus complexe.
C'est une très mauvaise idée. Si vous essayez d'attraper un bogue de production, vos clauses de débogage vous trébucheront certainement à une étape ou une autre. Vous voulez être aussi proche que possible du code qui fonctionne dans la production. Dans votre exemple, vous ne pourrez jamais trouver un bogue dans la liste de contrôle ()
Par l'apparence des choses que votre code est trop étroitement couplé. Ce que vous voulez faire est de faire des modules / classes moins dépendants de l'autre et de la pratique du développement axé sur les tests. Regardez également l'inversion du contrôle (aka injection de dépendance).
Travailler efficacement avec le code hérité a une certaine utile Insights sur la façon d'introduire TDD. Il a également de très bons indicateurs sur la façon de faire TDD dans divers scénarios où il pourrait être difficile de tester les choses.
Mon style actuel consiste à avoir un fichier appelé Aadebug.h, qui contient un groupe de définition conditionnelle, chacun peut être précédé de // de la désactiver. Le fichier démarre:
//#define DX_DEBUG #ifdef DX_DEBUG #define DX_SKIP_LOGIN // #define DX_ALLOW_BULK_USER_CREATE #define DX_CREATE_EXCESS_LOGS // #define DX_RANDOM_PROBE_FAILURES #define SHORT_KEY_TIMEOUT // #define DX_OMIT_NET_VIEWER ... #endif