The .Net frog

Resharper est pour moi l'outil le plus important en dehors de Visual Studio pour développer en .Net. C'est simple, je suis incapable de travailler sans, et la plupart des personnes que je connais qui l'utilisent sont dans le même cas. Je vous parle d'une productivité augmenté de plusieurs dizaines de pour cent pour les taches de développements! Et d'une qualité accrue pour la simple raison que l'on se permets de refactoriser le code en permanence comme l'opération devient indolore et peu couteuse. Pourtant, pour avoir rencontré un certain nombre d'éditeurs de logiciels récemment, je peux vous assurer que le taux de pénétration de cet add-in magique reste faible, trop faible.

Certes, parler de resharper ici revient à précher aux convaincus. Si vous lisez ce blog, il y a de fortes chances pour que vous soyez déjà utilisateur... Si ce n'est pas le cas, je vous invite non seulement à lire la suite mais surtout à essayer et faire essayer cet outil !

Resharper, ça sert à quoi ?

Resharper est un outil qui permet d'améliorer significativement la productivité des développeurs. Ses fonctionnalités couvrent les points suivants :

• Refactoring
• Analyse de code
• Génération de code
• Formatage de code
• Navigation
• Exécution des tests unitaires

Concrètement, Resharper vous permet de passer moins de temps sur l'accessoire et plus sur l'essentiel. Vous ne me croyez pas? voici quelques exemples de fonctionnalités (non exhaustif !):

Refactoring :

• Créer une interface à partir d'une classe
• Créer une méthode à partir du code sélectionné
• Introduire un membre, une variable ou un paramètre à partir d'une expression
• Changer la signature d'une méthode (par exemple, modifier l'ordre des paramètres)
• Réécrire des expressions pour utiliser l'opérateur ??

Analyse de code :

• Détecter toutes les erreurs de compilation dans la solution (sans compiler)
• Détecter le code non utilisé dans la solution
• Détecter les exceptions potentielles de type NullReferenceException
• Suggestions sur les paramètres des fonctions. Par exemple utiliser un ICollection en paramètre plutôt qu'un IList si on n'utilise que des membres de ICollection dans le code de la fonction

Génération de code :

• Générer les propriétés pour les membres sélectionnés (totalement configurable pour utiliser des propriétés automatiques ou non, des propriétés en lecture seule, etc.)
• Générer un constructeur à partir des membres sélectionnés
• Implémenter une interface en générant la structure des méthodes
• Générer un membre (par exemple, après avoir tapé _foo = new Foo(); je peux générer _foo automatiquement avec un raccourci)
• Générer une méthode (par exemple, après avoir tapé foo.Bar(); je peux générer la méthode Bar dans la classe Foo avec un raccourci)
• Suggestion des using à ajouter au fur et à mesure que l'on écrit le code
• Templates pour le code et les fichiers

Formatage de code :

• Retirer les using inutile
• Trier les membres d'une classe par visibilité (private, protected, internal, public)
• Organiser la classe avec des régions de façon automatique

Navigation :

• Trouver toutes les utilisations d'un symbole (Visual Studio le fait déjà mais très lentement par rapport à Resharper)
• Surligner l'utilisation d'un symbole
• Accès rapide aux fichiers, types et symboles en tapant leur nom ou initiales
• Aller à la classe dont la classe courante hérite, à la classe fille.

Exécution des tests unitaires :

• Exécuter le test spécifié
• Exécuter tous les tests

Le plus simple pour se faire une idée concrète est encore de visionner les nombreux webcasts réalisés ici et la :

• Les démos officielles, notamment celle ci ou celle la
• Une démo faite par Los Techies. Tellement impressionnante que je l'inclue directement dans le billet :

Vous pouvez également lire l'excellente série 31 days of Resharper.

Enfin, si vous téléchargez la démo, je vous conseille vivement de télécharger et d'imprimer la feuille résumant les raccourcis :

• Avec le mapping Resharper (celui que j'utilise personnellement)
• Avec le mapping Visual Studio

Toutes ces fonctionalités ont évidemment un prix, soit 315€ pour la version complète (c# + vb.net) ou 225€ pour la version C# seulement. Je peux vous assurer que c'est rentabilisé en 1 semaine !

P.S : Non, je n'ai pas d'actions chez Jetbrains, le créateur de Resharper :-)

On m'a récemment demandé de citer un pattern que j'utilise systématiquement dans mes projets. Question difficile dans la mesure ou un pattern ne doit justement pas être appliqué mécaniquement : son utilisation est conditionnée par le contexte.

Pourtant, apres réflexion, il y a bien un pattern que j'utilise de façon systématique : l'injection des dépendances qui est un application d'un pattern plus global appelé inversion de contrôle (Dependency Injection et Inversion of Control en anglais, ou DI et IoC).

L'inversion de contrôle est un concept assez générique. Il permet à un framework de déléguer l'implémentation et l'exécution d'un comportement à du code qui n'est pas lui même contenu dans le framework. Plusieurs façons existent pour appeler le code en question, comme :

• La programmation orientée évenement : le code appelant le framework à la possibilité de se lier à certains évènements pour effectuer des opérations quand ces derniers sont levés. On retrouve cet architecture à tous les étages du framework .Net.
• Le pattern "Template method" : une classe abstraite définie une fonction qui appelle un certain nombre de méthodes virtuelles. Celles ci peuvent doivent être implémentées dans une classe fille pour définir le comportement.
• L'injection des dépendances, que je vais expliquer dans les lignes qui suivent :-)

L'injection des dépendances :

Un programme informatique comprends généralement un ensemble plus ou moins complexe de dépendances entre différentes classes. Par exemple, nous pourrions envoyer un email avec le code suivant :

class Controller
{
    public void DoStuff()
    {
        var emailSender = new EmailSender();
        emailSender.Send("j@j.com", "Email Subject", "This is the content !");
    }
}
 
class EmailSender
{
    public void Send(string to, string subject, string message)
    {
        // Send the email...
    }
}

Nous venons de créer une relation de dépendance forte entre la classe Controller et la classe EmailSender. Cependant, l'envoi d'email est un service qui peut avoir de nombreuses implémentations. On pourrait par exemple avoir une implémentation utilisant la classe System.Net.Mail.SmtpClient et une seconde utilisant un prestataire externe par l'intermédiaire de web services. Qui plus est, on peut envisager d'utiliser la première implémentation en test et la seconde en production. Autrement dit, nous ferions mieux de refactorer ce code pour découpler Controller d'une implémentation spécifique d'EmailSender !

Première étape de notre refactoring, EmailSender doit implémenter un contrat (une interface) :

interface IEmailSender
{
    void Send(string to, string subject, string message);
}
 
class EmailSender : IEmailSender
{
    public void Send(string to, string subject, string message)
    {
        // Send the email...
    }
}

Deuxième étape : remplacer la dépendance Controller <-> EmailSender par Controller <-> IEmailSender :

class Controller
{
    private IEmailSender _emailSender;
 
    public void DoStuff()
    {
        _emailSender.Send("j@j.com", "Email Subject", "This is the content !");
    }
}

A cet instant, la classe Controller ne dépend plus d'une implémentation spécifique d'EmailSender. Nous avons donc appliqué le pattern inversion de contrôle. Dernière étape : injecter l'implémentation voulue dans la classe Controller, par l'intermédiaire du constructeur :

class Controller
{
    private IEmailSender _emailSender;
 
    public Controller(IEmailSender emailSender)
    {
        _emailSender = emailSender;
    }
 
    public void DoStuff()
    {
        _emailSender.Send("j@j.com", "Email Subject", "This is the content !");
    }
}

(Remarque : l'injection peut aussi être faite par l'intermédiaire d'une propriété)

Et ça y est, nous venons d'appliquer l'injection de dépendances !

L'utilisation de ce pattern offre plusieurs bénéfices immédiats :

• Nous l'avons déjà vu, Controller ne dépend plus d'une implémentation spécifique. Il est donc facile de passer d'une implémentation à une autre en fonction du contexte
• La dépendance entre Controller et IEmailSender est explicite, le code devient plus maintenable et compréhensible
• Si la dépendance est exposée, il est possible de la remplacer par une implémentation factice pour écrire des tests unitaires
• Enfin, la configuration des dépendances peut maintenant être centralisée et effectuée par l'intermédiaire un framework (StructureMap, Spring.Net, Castle, NInject, etc.).

Ces deux derniers points feront l'objet d'un billet prochainement :-).

Voici le nombre de réponses obtenues sur un site d'offres d'emploi pour quelques mots clefs différents, dans un rayon de 40km autour de chez moi (paris) :

• C# : 337 résultats
• C# ET agile : 2 résultats
• Nunit : 8 résultats (mais 3 en retirant les doublons)
• NHibernate : 2 résultats

Conclusion : Il y a du boulot avant que les concepts poussés par alt.net passent dans le mainstream !

Pour faire suite à la présentation sur le DDD que Gauthier et moi avons fait à Alt.net, voici 2 ressources supplémentaires :

• MVC Storefront, part 25
• Hanselminutes #140 (Merci Rafael)

Je n'ai pas encore eu le temps d'écouter les 2 webcasts, mais je suppose que le 1er est très concret (les sources peuvent être téléchargées depuis le site de Rob Conery)

Voici les slides que Gauthier et moi-même avons utilisé pour notre présentation sur le Domain Driven Design à Alt.net :

N'hésitez pas à les réutiliser si cela peut vous être utile ! N'hésitez pas non plus à nous laisser un petit mot si c'est le cas ;-) Juste par curiosité :-).

Enfin, petit message personnel : Je cherche du boulot ! Donc si vous montez une équipe agile de la mort qui tue, contactez moi!