Pourquoi je n’aime pas les générateurs de code ?

639165_old_factory

Je n’ai jamais vraiment beaucoup aimé les générateurs de code.

Vous savez, le genre d’outils qui peut vous générer des centaines et parfois même des milliers de lignes de code avec simplement quelques paramètres ?

Dans cet article, je vais discuter des points positifs et négatifs quant à l’utilisation d’outils de générateurs de code. Des exemples de différents générateurs seront aussi décrits.

On mentionne  souvent que ces outils nous font économiser des centaines d’heures et aide à avoir du code plus standard, je pense par contre qu’à moyen et long terme, il peut y avoir certains effets négatifs.

Comme par exemple :

  • Nuit à l’apprentissage: C’est le point le plus important d’après moi. Le simple fait que de ne pas avoir touché à une partie du code, nous rend vulnérable par rapport celle-ci. Aussi, il est important de bien comprendre un système informatique dans son ensemble et non seulement les parties du code qui n’ont pas été générées. Faut aussi savoir que tel générateur ne sera pas disponible dans un autre projet… Exemple: un générateur de code se charge de produire les contrats de services et de données en WCF. Il se charge de bien créer les classes et de mettre les bons « tags » relatifs à WCF. Dans ce cas, on ne peut pas dire que nous avons gagné de l’expérience avec WCF. Si on arrive dans un autre mandat ou projet et que le générateur n’existe pas, il nous faudra approfondir WCF car finalement, on ne le connaît pas vraiment malgré son utilisation dans un précédent projet.
  • Difficultés lors de la recherche d’erreurs : Les générateurs de code produisent en général du code un peu obscur et difficile à lire. Si une erreur se produit dans cette partie du code, la recherche peut s’avérer longue et douloureuse.
  • Pour une simple correction, on a souvent pas le choix d’utiliser le générateur de code: C’est en général non-productif de devoir refaire l’exécution du générateur pour faire un petit changement, comme renommer une méthode par exemple ou changer de type une propriété. Pour ces gestes, c’est tellement plus facile et rapide d’y aller manuellement…

Bien que j’aie déjà utilisé certains de ces outils, je peux avouer qu’ils sont parfois efficaces et, probablement, valent la peine d’être utilisé selon le contexte. Dans certains environnements avec des dizaines de programmeurs, on n’a pas trop le choix de standardiser certaines parties du code malgré les inconvénients. Bref, je crois que l’idéal est d’avoir une bonne balance entre productivité à court terme et l’apprentissage à long-terme.

Voici quelques-unes de mes expériences avec les générateurs de code:

Bonnes:

  • LINQ to SQL: Le code généré à partir de tables SQL Server n’est pas trop gros. C’est certain qu’il n’est pas très beau non plus, mais c’est assez facile de se créer une classe « extended » pour y ajouter des options particulière, comme une chaîne de connexion qui peut changer selon certaines conditions. Mais dans ce cas, le gain se fait surtout par l’utilisation directe de LINQ pour lire et modifier nos classes SQL. Le code que l’on créé ainsi manuellement est beaucoup plus lisible et simple avec LINQ.
  • Resharper: La génération de code dans Resharper se charge surtout de petits bouts de code qui seront intégrés à notre classe. Après cela, on les manipule comme on veut. Voyez ici les exemples .

Négatives:

  • Smart Client Software Factory: Il y a une bonne volonté ici de faire des outils pour générer nos vues, contrôleurs et autres structures nécessaire au pattern MVP-C. Par contre cela en résulte en un nombre assez nombreux d’événements. Lorsqu’il faut faire du débogage, on ne se sait plus trop ou donner de la tête lorsque cela saute d’un événement à l’autre.
  • CodeSmith : J’ai déjà utilisé cet outil pour générer une couche d’accès aux données dans un précédant projet. Je trouvais terrifiant de voir des milliers de lignes de codes produite pour simple une table avec une dizaine de colonne seulement. Par chance que les erreurs ne s’y trouvaient pas souvent. Noter aussi que CodeSmith a d’autres outils que je n’ai pas essayé et qui sont probablement intéressant malgré tout.
  • L’outil « Add Service Reference » de Visual Studio pour WCF: Je n’aime pas cette option qui se fait un peu trop facilement avec un clic droit de la souris. Le gros problème c’est que le fichier de configuration est rempli plein d’options sélectionnés dont plusieurs ne sont pas utile. Aussi, c’est un peu embêtant si on ajoute un deuxième service en référence dans le même projet. J’aime beaucoup mieux la méthode manuelle tel que décrit dans l’article WCF the Manual Way…the Right Way

Et vous, que pensez-vous des générateurs de code ?

Publicités

Technology Radar 2010: Focus .NET

Clear Radar Screen

Technology Radar 2010: Focus .NET

Je viens de lire le document « Technology Radar » de la firme ThoughWorks et je trouvais intéressant de faire un résumé de cette liste avec le focus .NET. Vous pouvez télécharger le document gratuitement ici:

http://www1.vtrenz.net/imarkownerfiles/ownerassets/1013/Technology%20Radar%20Jan%202010.pdf

Je trouve très intéressante la manière de bâtir le radar dans ce document.

Premièrement on y retrouve quatre grands axes:

  • Techniques
  • Tools
  • Platforms
  • Languages

Ensuite, on divise chaque cercle selon l’intérêt apporté selon l’industrie:

  • Hold
  • Asssess
  • Trial
  • Adopt

Voyons un peu ce qui ressort pour .NET et certains « à côté » selon chaque grand axe:

  • Techniques
    • On parle de l’adoption de « Build Pipelines » et de déploiement continue. On peut donc s’attendre à voir plus fréquent l’utilisation de VSTS ou autres serveurs de builds tel que CC.NET, TeamCity et FinalBuilder. Donc, davantage d’intégration continue, ce qui est très bien selon moi !
    • On mettra aussi à l’essai des pratiques d’architecture, comme le Evolutionary Enteprise Architecture, SOA et le Emergent Design, pour aider l’architecture à s’intégrer avec les approches agiles. Quel en sera l’impact sur nos projets .NET actuels ?
    • Le User-Centered Design demande une collaboration proche entre ceux qui conçoivent l’interface graphique et ceux qui font le développement. Est-ce que des outils comme Microsoft Expression Blend peuvent aider dans l’adoption de cette pratique ?
  • Tools
    • On note ici que ASP.NET MVC est devenu un développement intéressant pour Microsoft et que son adoption devrait bien se faire en générale. Le modèle MVC et le fait que c’est Open Source semble être un move intéressant de la part de Microsoft. On se rapproche ainsi de certains frameworks de Java pour un modèle plus testable que les fameuses web forms.
    • On fera aussi davantage l’essai de cueillette de données et de métriques pour voir l’évolution et la visualisation d’un système informatique. Encore ici, je crois que l’Intégration Continue pourra jouer un rôle important avec cela.
    • Baisse d’utilisation de Subversion et une tendance à aller des outils de gestion de code distribué, comme GitHub.
  • Languages
    • Apparition de langage fonctionnel, tel que le Scala et le F#.
    • La nouvelle version de C#, la 4.0, semble vouloir faire avancer le langage au devant du Java qui tarde à donner de nouvelles fonctionnalités à ses développeurs. D’ailleurs, je ne peux m’empêcher de citer la phrase suivante de l’étude (j’aime beaucoup de C#, ne vous l’ai-je déjà dit ?):

As C# continues to surge ahead, the Java language appears to be moving slowly as the Java community waits for Java 7.

  • Platforms
    • Adoption du « Cloud » on verra si Azure sera de la partie…
    • Fin de la vie de IE6. Pas vraiment de surprises ici. Mais, est-ce que les entreprises feront une transition vers IE8 ou Firefox ou Chrome ?
    • On fait aussi remarquer que IE8 n’est pas totalement conforme aux standards du web.
    • À voir aussi le système d’exploitation Chrome OS pour les netbook.
    • On pourra aussi voir davantage d’application riche pour internet, comme la plateforme Silverlight le permet. Fait intéressant, l’étude mentionne toutefois que le développement web traditionnel apportera davantage de valeur pour les entreprises. Donc à utiliser seulement pour les applications qui nécessitent une meilleure visualisation.

Vous pouvez aussi retrouver d’autres commentaires sur le site InfoQ (ils ont fait un beau tableau pour classer tout cela):

http://www.infoq.com/news/2010/01/ThoughtWorks-Technology-Radar

Et vous, qu’est-ce qui vous branche pour 2010 côté technologie ?