dimanche 9 février 2014

Premiers pas sur .Net

Nouvelle ville, nouveau domaine, nouvelle techno pour moi : je travaille sur l'environnement .Net en ce moment. Venant plutôt du monde de l'open source (officiellement, je dis que je suis développeur Java), voilà qui fait un gros changement pour moi. Que peut-on dire de ce contexte quand au départ on est plutôt sceptique face à ce que MS peut apporter ? Car oui, sceptique je suis : mon a priori c'est que MS, globalement, c'est de la merde en branche.

Pour vous donner une idée, mon environnement est le suivant :

  • .Net 3.5 (la version courante est la 4)
  • Visual Studio (w00t) 2008 (wat?)
  • Développement sur un bureau distant (sic) via un bouzin Citrix
  • Utilisation du framework développé par le client.
  • On va dire qu'a priori, je ne peux rien installer (pas d'add in, pas de bibliothèque sans validation des responsables du framework)

TL, DR : l'expérience est loin de ce que je me crois en droit d'attendre.

À la vue de ces contraintes, certains pourront trouver normal d'éprouver ce que j'éprouve. Que quand on a claqué ses étrennes pour s’offrir une version décente de VS, on peut quand même se payer quelques add in intéressants (comme resharper de jet brains pour ne citer que lui). Ah oui, c'est Microsoft : on ne dit pas plug in mais add in. Encore des gens qui sont contre le mariage pour tous...

Que peut on dire de l'IDE ? En utilisation naïve, c'est bien. On a une bonne intégration des outils (MS), on peut faire des diagrammes de classes qui se traduisent tous seuls en code, on peut rapidement s'interfacer via web services grâce au système de web / service references. On peut designer les pages ASP avec un éditeur wysiwig. Il y a un moteur de complétion pas mal (l'intellisense. Ouh la la j'en tremble). Il y a également la possibilité de faire des tests unitaires sans rien installer. Il y a même un débogueur pour faire comme Papa. À première vue, c'est donc pas trop mal. Le point fort de MS est d'avoir une stack toute intégrée, ce qui permet de déployer rapidement des applications. Et effectivement, je pense qu'en suivant une méthode de travail classique (c'est à dire privilégiant l'absence de qualité) l'environnement .Net tient ses promesses.

Maintenant, je le trouve faible dans le cas où on veut faire du développement dirigé par les tests. Force est de constater que VS n'est absolument pas compatible avec ce workflow. Son gros handicap : la faiblesse de sa fonctionnalité de quickfix. Voici ce qui me fait m'arracher les cheveux : j'écris une classe de test en C#. Dans un test, j'essaie d'instancier une classe qui, forcément n'existe pas. Pour moi, l'IDE devrait me proposer de créer la classe. VS me dit d'aller me faire foutre et me voilà donc en train de naviguer avec ma putain de souris dans l’explorateur de solution, à passer par 4 menus pour créer ma classe. Je me galère encore 5 minutes avant de pouvoir lancer mon test (bah oui, par défaut, VS crée des classes C# privées… c'est aussi utile qu'un trou de balle au niveau du coude, si je puis me permettre).

Au lancement du test, deuxième déconvenue : c'est lent. Genre méchamment lent. Comment peut-on imaginer bosser en TDD dans ces conditions ? C'est peut-être lié à mon contexte de dev à distance mais je n'en suis pas persuadé.

À part ça, qu'est-ce que je n'aime pas dans la stack ? Bon, je suis fatigué, je vous la fais courte :

  • ASP et ses contrôles. PFff, j'aime tellement les systèmes de templates que mettre plein de logique dans le code de présentation et surcoucher le html ça me file des boutons. On sent que le but c'est de faire comme si le dev web devait se comporter comme le développement d'application desktop. Et bien désolé, moi je trouve que le web c'est beau, ça vaut le coup de savoir ce qu'est une requête GET ou POST. Parce que même sans savoir ça, on peut se bâtir une carrière sympathique de développeur ASP apparemment. En fait je crois que j'ai juste envie d'utiliser Razor.
  • On utilise TFS (la gestion de code source made in microsoft, mec). Il parait que c'est super... Au bout d'une heure, je me retrouve face à 2 conflits que l'outil ne peut pas régler tout seul (au bout de 3 ou 4 commits). Je finis par supprimer un fichier directement sur le serveur. Génial. On propose donc de locker les fichiers pour modification. Oui, comme avec ce bon vieux PVCS. Snif.
  • C# n'est pas avare en concepts. Déjà que je trouvais que Java avait tendance à aller loin et pourtant C# est beaucoup plus riche. Trop riche. On est bien loin de la simplicité volontaire de Python.

Et donc voilà, un premier aperçu que je qualifierais d'en demi teinte. J'espère pouvoir continuer à manier l'euphémisme avec maestria jusqu'à la mise en prod...