Évitez ou embrasser des constructions C # qui modifier et continuent pause?

Question

Je développe et maintiens un grand (500k + LOC) WinForms d'app écrit en C # 2.0. Il est multi-utilisateurs et est actuellement déployée sur 15 sur les machines. Le développement du système est en cours (peut être considéré comme une version bêta perpétuelle), et il y a très peu fait pour protéger les utilisateurs contre les insectes nouveaux potentiels qui pourraient être introduits dans une version hebdomadaire.

Pour cette raison, entre autres, je me suis trouvé devenir très dépendante de modifier et-continuer dans le débogueur. Il aide non seulement avec les chasseurs de bugs et corrections de bogues, mais dans certains cas avec le développement en cours ainsi. Je trouve qu'il est extrêmement précieux pour être en mesure d'exécuter un nouveau code de dans le cadre d'une application en cours d'exécution - il n'y a pas besoin de recompiler et ajouter un point d'entrée spécifique au nouveau code (avoir à ajouter des options de menu factices, boutons, etc à l'application et ne pas oublier de les enlever avant la prochaine version de production) -. tout peut être essayé et testé en temps réel sans arrêter le processus

Je tiens modifier-et continuer en si haute que je Code activement écriture pour être entièrement compatible avec elle. Par exemple, j'éviter:

• Les méthodes anonymes et les délégués en ligne (à moins complètement impossible de réécrire)
• méthodes génériques (sauf dans stable, le code de service invariable)
• Ciblage des projets à 'Tout CPU' (à savoir ne jamais exécuter en 64 bits)
• Initialisation des champs au niveau du point de la déclaration (initialisation est déplacé vers le constructeur)
• écrire des blocs d'énumérateur que l'utilisation yield (sauf dans le code de service)

Maintenant, je suis pleinement conscient que la nouvelle langue dispose en C # 3 et 4 sont en grande partie incompatibles avec edit-et-continue (expressions lambda, LINQ, etc.). Ceci est l'une des raisons pour lesquelles j'ai résisté à faire avancer le projet jusqu'à une version plus récente du Cadre.

Ma question est de savoir s'il est bon d'éviter d'utiliser ces constructions plus avancées en faveur de code qui est très, très facile à déboguer? Y at-il une légitimité dans ce genre de développement, ou est-ce gaspillage? En outre, surtout, faire l'une de ces constructions (expressions lambda, les méthodes anonymes, etc.) encourent la performance / frais généraux de mémoire que bien écrit, modifier-et continuer compatible avec le code pourrait éviter? ... ou le fonctionnement interne du compilateur C # rendent ces constructions avancées courir plus vite que-écrit manuellement, le code « élargi »?

Answer 1

Sans vouloir paraître banal - il est bon de tests unitaires d'écriture / intégration plutôt que de compter sur Edit-Continuer.

De cette façon, vous dépensez l'effort une fois, et tous les temps est « libre » ...

Je ne vous suggère des unités d'écriture rétrospectivement pour tout votre code; plutôt, chaque fois que vous devez corriger un bug, commencez par écrire un test (ou plus souvent des tests multiples) qui prouve le correctif.

Comme le mentionne dans Swersky @ Dave les commentaires, le livre de plumes Mchael, Travailler efficacement avec Legacy code est une bonne ressource (il héritage de 5 minutes après que vous avez écrit, non?)

Oui, je pense qu'il est une erreur pour éviter de nouvelles contructs C # en faveur de permettre de modifier et de continuer; Mais je pense aussi qu'il est une erreur d'adopter de nouvelles constructions juste pour le plaisir de le faire, et surtout si elles conduisent à plus difficile à comprendre le code.

Answer 2

I love 'Modifier et continuer'. Je trouve qu'il est un énorme catalyseur pour le développement interactif / mise au point et je trouve aussi assez ennuyeux quand il ne fonctionne pas.

Si « Modifier et continuer » aide votre méthodologie de développement puis par tous les moyens à faire des choix pour le faciliter, en gardant à l'esprit la valeur de ce que vous renoncez.

L'un de mes bêtes noires animaux est que tout d'édition en fonction avec des pauses expressions lambda Modifier et continuer ». Si je HEURTER assez je peux écrire l'expression lambda. Je suis sur la clôture avec des expressions lambda. Je peux faire des choses plus rapidement avec eux, mais ils ne le font pas me sauver du temps si je finis les écrire plus tard.

Dans mon cas, j'éviter d'utiliser des expressions lambda quand je ne suis pas vraiment besoin. Si elles obtiennent de la façon dont je peux les envelopper dans une fonction afin que je puisse « Modifier et continuer » le code qui utilise les. Si elles sont gratuites je les écrire.

Votre approche n'a pas besoin d'être en noir et blanc.

Answer 3

Je voulais clarifier ces choses un peu

  

il est bon d'éviter d'utiliser ces constructions plus avancées en faveur de code qui est très, très facile à déboguer?

Modifier et continuer est pas vraiment le débogage, il développe. Je fais cette distinction parce que les nouvelles fonctionnalités C # sont très débogable. Chaque version de la langue ajoute le support du débogage pour les nouvelles fonctionnalités de langue pour les rendre aussi facile que possible débogage.

  

tout peut être essayé et testé en temps réel sans interrompre le processus.

Cette déclaration est trompeuse. Il est possible avec Modifier et continuer de vérifier un changement corrige un problème très spécifique. Il est beaucoup plus difficile de vérifier que le changement est correct et ne casse pas une foule d'autres questions. A savoir que modifier et continuer ne modifie pas les fichiers binaires sur le disque et ne permet donc pas des éléments tels que les tests unitaires.

Dans l'ensemble si oui, je pense que ce serait une erreur pour éviter de nouvelles contructs C # en faveur de permettre d'éditer et de continuer. Modifier et continuer est une grande caractéristique (vraiment aimé quand je rencontrais dans mes C ++ jours). Mais sa valeur en tant que serveur de production aide ne compense pas les gains de producitivy de la nouvelle C # dispose à mon humble avis.

Answer 4

  

Ma question est de savoir s'il est bon d'éviter d'utiliser ces constructions plus avancées en faveur de code qui est très, très facile à déboguer

Je dirais que chaque fois que vous vous forcer à écrire du code qui est:

1. Moins expressif
2. long
3. répétée (d'éviter les méthodes génériques)
4. Non-portable (jamais mise au point et tester 64bit ??!?!?)

Vous ajoutez à votre coût d'entretien général beaucoup plus que la perte de la « Modifier et continuer » fonctionnalité dans le débogueur.

J'écrirait le meilleur code possible, pas de code qui fait fonction de votre travail IDE.

Answer 5

Bien qu'il n'y ait rien de mal avec votre approche, il ne vous limite à la quantité d'expressivité compris par l'EDI. Votre code devient le reflet de ses capacités, non pas de l'linguistiques, et donc votre valeur globale dans le monde du développement diminue parce que vous vous empêchent d'apprendre d'autres techniques d'amélioration de la productivité. Éviter LINQ en faveur de Edit-et continuer se sent comme un énorme coût d'opportunité pour moi personnellement, mais le paradoxe est que vous devez acquérir une certaine expérience avec elle avant de pouvoir se sentir de cette façon.

En outre, comme cela a été mentionné dans d'autres réponses, unité de tester votre code supprime besoin pour exécuter l'application entière tout le temps, et résout ainsi votre dilemme d'une manière différente. Si vous ne pouvez pas un clic droit dans votre IDE et tester seulement les 3 lignes de code que vous aimez, vous faites trop de travail au cours du développement déjà.

Answer 6

Vous devriez vraiment introduire l'intégration continue, qui peut vous aider à trouver et éliminer les erreurs avant de déployer le logiciel. Surtout les grands projets (je considère 500k assez grand) besoin d'une sorte de validation.

http://www.codinghorror.com/ blog / 2006/02 / revisitant-edit-et-continue.html

En ce qui concerne la question spécifique: Ne pas éviter ces constructions et ne comptez pas sur vos folles compétences de débogage - essayez d'éviter les bugs du tout (dans le logiciel déployé). tests unitaires d'écriture à la place.

Answer 7

J'ai aussi travaillé sur de très grands projets permanents bêta.

Je l'ai utilisé des méthodes anonymes et les délégués inline garder quelques morceaux relativement simples de proximité usage d'une logique à leur seul lieu d'utilisation.

Je l'ai utilisé des méthodes génériques et des classes pour la réutilisation et la fiabilité.

J'ai initialisés cours dans les constructeurs comme toute mesure possible, de maintenir et invariants de classe éliminer la possibilité de bugs causés par des objets dans les états invalides.

Je l'ai utilisé des blocs de recenseur pour réduire la quantité de code nécessaire pour créer une classe de recenseur à quelques lignes.

Tous ces éléments sont utiles pour le maintien d'un grand projet en évolution rapide dans un état fiable.

Si je ne peux pas modifier-et continuer, je éditer et recommencer. Cela me coûte quelques secondes la plupart du temps, quelques minutes dans les cas désagréables. Cela vaut la peine pour les heures qui ont une plus grande capacité à raisonner sur le code et une plus grande fiabilité grâce à la réutilisation qui me sauve.

Il y a beaucoup, je vais le faire pour le rendre plus facile de trouver des bugs, mais pas si ça va le rendre plus facile d'avoir des bugs aussi.

Answer 8

Vous pouvez essayer Test Driven développement. Je l'ai trouvé très utile pour éviter d'utiliser le débogueur du tout. Vous commencez à partir d'un nouveau test (par exemple le test unitaire), puis vous exécutez que ce test unitaire pour vérifier votre développement - vous n'avez pas besoin toute l'application en cours d'exécution tout le temps. Et cela signifie que vous n'avez pas besoin modifier et-continuer!

Je sais que TDD est le mot à la mode actuelle, mais il fonctionne vraiment pour moi. Si je dois utiliser le débogueur je le prends comme un échec personnel:)

Answer 9

En se fondant sur Edit et Cont. sons comme il y a très peu de temps consacré à la conception de nouvelles fonctionnalités, et encore moins des tests unitaires. Ce que je trouve être mauvais parce que vous finirez probablement faire beaucoup de débogage et correction de bogues, et parfois vos corrections de bugs causer plus de bogues, droit?

Cependant, il est très difficile de juger si vous devez ou ne devrait pas utiliser les fonctions linguistiques ou non, parce que cela dépend aussi beaucoup, beaucoup d'autres facteurs: reqs du projet, les délais de libération, les compétences de l'équipe, le coût de la facilité de gestion de code après refactoring, à nommer quelques-uns.

Hope this helps!

Answer 10

La question que vous semblez avoir est:

  

Il prend trop de temps pour vous reconstruire l'application,   démarrer à nouveau et obtenir au bit   de l'interface utilisateur que vous travaillez.

Comme tout le monde a dit, tests unitaires contribueront à réduire le nombre de fois que vous devez exécuter votre application pour trouver des bugs / fix sur aucun code interface utilisateur; mais ils ne le font pas d'aide avec des questions telles que la mise en page de l'interface utilisateur.

Dans le passé, je l'ai écrit une application de test qui charge rapidement l'interface utilisateur je travaille et le remplir avec des données factices, de manière à réduire le temps de cycle.

La séparation de ne code de l'interface dans d'autres classes qui peuvent être testés avec des tests unitaires, vous permettra d'utiliser toutes les constructions faites C # dans ces classes. Ensuite, vous pouvez simplement limiter les constructions en cours d'utilisation dans le code de l'interface utilisateur de son auto.

Quand j'ai commencé à écrire beaucoup de tests unitaires, mon utilisation de « modifier et continuent » est descendu, je comment utiliser à peine à part le code UI.