Catégorie : .NET

Agile Tour Québec 2012: Les sessions Partie 1

Bien que j’étais un organisateur, j’ai pu assister à plusieurs sessions lors de l’Agile Tour qui a eu lieu le 6 novembre dernier à Québec. Voici donc mes impressions sur ce que j’ai vu dans les sessions du matin (ceux de l’après-midi seront dans le billet Agile Tour 2012: Les sessions Partie 2):

Développement orienté comportement et automatisation des essais d’acceptation (BDD)

par Christian Roy et Jean-François Nadeau

Je connais bien le sujet (Behavior Driven Development ou BDD) et aussi l’outil Specflow que j’ai recommandé et appliqué sur un de mes projets. Specflow est comme une sorte de version .Net de l’outil « Cucumber » qui est utilisé pour automatiser des tests d’acception qui fonctionne avec le langage Ruby. J’étais curieux de voir comment les présentateurs avaient utilisé le tout dans leur contexte. La présentation se divisait en trois parties:

  1. Théorie
  2. Démonstration
  3. Leçons apprises

Présentation très dynamique et amusante au début pour expliquer la théorie. Cela a fait un peu contraste avec la démo, mais bon c’était très intéressant somme toute. Dans la démo, on montrait l’utilisation de Sélénium Web Driver avec Specflow. Le tout était réalisé avec le patron du « PageObject ». C’était très intéressant. Par contre, je reste avec l’impression que c’est toujours un peu lourd de tester la couche graphique, et ce peu importe l’outil. On a peu parlé du TDD et de comment il s’intègre avec le BDD. Je m’interroge toujours un peu sur cet aspect que je trouve important et négligé. Je crois que les tests unitaires ne doivent pas être ignorés même si on a des tests d’acceptation automatisés grâce au BDD. J’aimerais bien voir un bel exemple pratique de tests BDD et de tests unitaires côte à côte dans un projet. Dans les leçons apprises, on a parlé de l’outil Amnesia pour aider l’exécution de tests avec une BD. Je suis intrigué, autre chose à regarder plus tard. Et un aspect que je trouve très important, les développeurs étaient impliqués dans la création des scénarios. En bref, une bonne présentation et de bonnes discussions ont eu lieu.

Références:

Propulsez votre architecture avec les TDD et les Mocks

par Félix-Antoine Bourbonnais

Mon collègue de Agile Québec, Félix-Antoine, n’est pas seulement dynamique lors de nos rencontres, il l’est aussi comme présentateur. C’est donc avec passion qu’il nous présente les différents styles de TDD avec les termes style « Classique/Chicago » ou style « Mock/London ». Je ne connaissais pas trop cette distinction, mais elle est similaire à d’autres termes comme le « State-Based testing » ou basé sur l’état et le « Interaction-Based Testing » centré sur les interactions.

Le TDD doit se voir avant tout comme un outil de découverte et d’aide à la conception de l’architecture logicielle. Les tests qui en résultent sont un peu comme un effet secondaire. Félix-Antoine nous a partagé son expérience en nous montrons ce qui est fondamental avec les tests, soit : Tester les modules en isolation. L’utilisation des mocks est une technique qui aide à cela. Encore faut-il que notre code soit bien organisé pour en profiter sans trop de « douleur ». C’est là, que l’application de bonnes pratiques comme l’utilisation d’abstraction (c.-à-d. les interfaces) , du « Clean Code », les principes SOLID et le « Tell don’t ask » sont très importantes pour réaliser de bons tests unitaires. L’idée est de combiner ces différentes techniques selon ce que l’on veut découvrir (conception ou algorithme). Pour finir, Félix-Antoine nous recommande fortement le livre « Growing Software Oriented by Tests » qui semble s’appliquer, malgré que les exemples sont en Java, aux différents langages orientés-objet.

Références:

Publicité

Notes de Lecture: The Art of Unit Testing

J’ai lu ce livre il y a un an ou deux, mais il est toujours d’actualité et je trouvais important de vous en parler. D’une certaine manière c’est toujours bon de revoir ses bases de temps à autre. Ce livre est en quelque sorte un « must » pour tout développeur, notamment ceux qui font du .Net. Il existe aussi une version inspirée de ce livre chez le même éditeur avec les exemples en Java intitulé « Unit Testing in Java » qui sera publié cette année.

Premièrement, pour bien situer ce livre, ce dernier se concentre surtout sur l’aspect « Test unitaire » et non le TDD (Développement piloté par les tests). Ce dernier y est mentionné un peu, mais l’accent de ce livre n’est pas tout simplement pas sur cet aspect.

L’auteur, Roy Osherove,  nous fait découvrir de manière pédagogique plusieurs notions essentielles lorsque l’on veut progresser dans les tests unitaires, notamment vers des cas plus complexes. Et ce, dans l’environnement de développement .Net, malgré que la plupart des notions peuvent être adaptées pour un autre environnement de développement orienté-objet.

Le TDD avec des cas simples c’est bien beau et facile, mais cela peut se corser assez vite merci. On y voit alors dans ce livre plusieurs trucs, notions et techniques tels que:

  • Les techniques de base
    • Les Stubs
    • Les Mocks
    • Les différents frameworks d’isolation
  • Le code de test
    • L’organisation et la hiérarchie des tests…
    • Les bonnes pratiques pour les tests
  • Processus et conception
    • Intégrer les tests dans l’organisation
    • Travailler avec du « Legacy Code »

J’aime le fait que l’auteur dans les premiers chapitres s’occupe de bien définir les termes essentiels qui seront utilisés tout au long du livre tel que:

  • Test Unitaire
  • Test d’intégration
  • State-based testing / vérification d’état
  • Interaction testing / vérification de l’interaction avec d’autres objets
  • Système sous test
  • La régression
  • C’est quoi du « Legacy Code » ? (en fait c’est du code sans tests unitaires)
  • Refactoring
  • Seams
  • Fake
  • Dynamic Fake

Point que je trouve important et qui est aussi abordé dans ce livre, c’est comment nommer nos méthodes de tests. J’aime bien la formule que l’auteur suggère, soit de nommer en trois parties séparées par le caractère « _ »:

  • Nom de la Méthode
  • État du test
  • Comportement prévu

Ex.: IsValidFileName_ValideFile_ReturnsTrue()

Si vous avez beaucoup de tests dans votre projet, vous allez voir que ce type de nommage aidera le classement et permettra de facilement déduire le test d’après son nom.

Le Pattern AAA est aussi abordé dans le livrer et c’est un de mes préférés. Donc, je vais vous en parler un peu. Il s’agit en fait de faire notre méthode de test en trois « sections » fonctionnelles qui sont les suivantes:

  1. Arrange: On prépare les variables nécessaires et autres préalables.
  2. Act: Action sur l’objet ou la méthode que l’on teste
  3. Assert: On compare le résultat attendu versus celui obtenu.

Exemple:

[Test]
 public void CalculateSalesBonus_VendorWithSalesBonus_BonusMade()
 {
 // Arrange
 int salesNovember = 10000;
 var calculator = new BonusCalculator();

 // Act
 var result = calculator.CheckBonus(salesNovember);

 //Assert
 result.ShouldEqual(100);
 }

Un aspect important quand on établit notre code de test, c’est de commencer par l’assertion (et oui, on commence par la fin !). Cela rend plus clair par la suite la réalisation des étapes d’Arrange et d’Act. Ce conseil me vient de JR Rainsberger que j’ai eu l’occasion de rencontrer au Code Retreat à Québec en 2011.

Personnellement, je trouve que faire des mocks peut parfois être utile, mais il faut faire attention car cela peut nous amener à faire beaucoup de code. J’aime bien dans ces cas appliquer la règle de Pareto, ou celle du 80/20, c’est-à-dire qu’on ne fera pas du code 80% plus gros pour tester un 20% de notre application. Il faut y aller alors de manière pragmatique.

L’auteur parle aussi au chapitre 8 des manières d’introduire les tests unitaires automatisés dans une organisation, encore là, une bonne section du livre. Le facteur humain n’est pas à négliger ici, car le TDD et les tests unitaires, qui introduisent une nouvelle manière de concevoir notre code, peuvent provoquer des bouleversements au passage.

Bref, si vous faites du développement avec .Net ou Java, et que particulièrement vous trouvez que c’est dur de faire des tests unitaires (et vous avez raison, car ce n’est pas une mince tâche), ce livre peut vous aider.

J’ai fait un résumé des idées de ce livre (avec une certaine adaptation) dans le mind map suivant (cliquer pour l’agrandir) :

 

 

 

 

 

 

 

Mes points clefs:

  • C’est important de bien connaître les techniques de base (stub, mock et framework) afin de progresser dans la programmation des tests unitaires
  • Organiser les tests (nomenclature, projets), n’est pas à négliger pour établir un standard dans l’équipe de programmeurs
  • Pour implanter le TDD et les tests unitaires dans une organisation, il faut être prêt. Ex.: répondre aux questions, identifier les champions, gérer avec les « bloqueurs, avoir des buts spécifiques, etc.

 

Références:

Est-ce que votre code est S.O.L.I.D. ?

CrackDans ce billet, je vais vous décrire brièvement les principes SOLID pour la programmation orientée-objet avec quelques commentaires et vous suggérer quelques ressources pour approfondir ce sujet qui devrait être connu de tous les programmeurs sérieux et professionnels.

Je suis toujours surpris lorsque, la plupart du temps, à chaque fois que je parle de ces principes à de nouveaux collègues, mon interlocuteur hausse les épaules et ne sait pas de quoi je parle.

 

S.O.L.I.D. est acronyme regroupant les principes suivants:

  • Single Responsability Principle (SRP): Une classe devrait avoir une et une seul raison (responsabilité) d’être modifiée.
  • Open Closed Principle (OCP) : Chaque classe devrait être ouverte pour des extensions et fermé autant que possible pour des modifications.
  • Liskov Substitution Principle (LSK) : Les classes dérivées peuvent être substitué de leur classe de base
  • Interface Segregation Principle (ISP) : Nos classes ne doivent pas hériter, via une interface, de méthodes qu’elles n’utilisent pas.
  • Dependency Injection Principle (DIP) : On doit dépendre de classes abstraites et non de classes concrètes

De tous ces principes, le plus important à suivre selon moi est le Single Responsability Principle (SRP). Ne pas respecter ce principe peut apporter plusieurs maux, notamment lorsque l’on fait évoluer le code.  Dans mon équipe actuelle, nous avons fait du SRP le principe de base et le plus important à suivre. De cette manière nous l’avons toujours en tête et il nous sert en quelque sorte de règle de base lorsque l’on se questionne sur la grosseur de classes et de méthodes ou autre.

C’est important aussi de connaitre les autres, mais on y fait référence un peu moins souvent à mon avis.

Pour en savoir plus, sur SOLID, vous pouvez commencer par les deux références suivantes sur Internet :

Pour approfondir SOLID, je recommande fortement le livre suivant (Liens Amazon.ca commandités) de Bob Martin qui se décrit en deux versions, tout dépendant si vous êtes de type Java/C++ ou .Net:

Agile Software Development, Principles, Patterns, and Practices

Type .Net (C#/VB)

Type Java/C++

Dans ce livre, l’oncle Bob nous explique les pratiques agiles, on y voit un peu de modélisation et aussi de nombreux chapitres sont dédiés aux principes orientés-objet. Ce livre d’environ 700 pages fait un très beau livre de référence à mettre sur son bureau pour le lire au complet ou le consulter à l’occasion.

En passant, nous aurons la chance de recevoir Bob Martin en tant que conférencier principal lors de l’Agile Tour Québec 2011. Les inscriptions devraient commencer en septembre. Pour info sur l’Agile Tour : http://at2011.agiletour.org/fr/at2011_Quebec.html

Autres articles intéressants avec exemples d’application de SOLID:

Référence pour l’image utilisée:

http://www.sxc.hu/photo/954598

La place des Business Objects dans le MVP

Où doit-on placer nos composants d’affaires (i.e Business Objects) lorsque l’on utilise les designs patterns du genre Model-View-Presenter (MVP) ou Model-View-Controller (MVC) ?

C’est une bonne question et  je la retrouve régulièrement dans les projets auxquels j’ai travaillé.

Mais avant de poursuivre, voici une conversation forte intéressante que j’ai observée sur twitter il y a quelque temps entre Robert « Uncle Bob » Martin et Martin Fowler à ce sujet:

Image@unclebobmartin Views should have no knowledge of business objects. Presenters should create data structures from business objects & views should use them.
Image@martinfowler @unclebobmartin disgree. It’s both traditional and effective for views to see domain objects
Image(1)@RonJeffries @unclebobmartin i’d wanna see one or more examples showing why views shouldn’t see domain objects but instead … what, « views « of them?
Image@unclebobmartin @martinfowler The problem is that views become coupled to business logic. Changes to BOs imply changes to views.
Image@martinfowler @unclebobmartin I think the relationships between view, model and other elements is too context-specific for a general rule
Image(2)@GBGames @unclebobmartin @martinfowler To be clear, I know MVC, but it seems there’s debate about what the V knows about the M?
Image[4]@martinfowler @GBGames @unclebobmartin There are many forms of MVC with different trade-offs. I said more at http://martinfowler.com/eaaDev/uiArchs.html
Image@unclebobmartin @peter_bugge BOs change for reasons of business logic. Views need not be affected.
Image@unclebobmartin @sebasmonia A change to the BO will often cause change to presentation logic, but hopefully not to the views.
Image@unclebobmartin An object has private state and public methods. A data structure has public data and no methods. Getters and setters make data public.
Image@unclebobmartin @MahasenBandara Views are concrete. Models are abstract. Views should depend on Models.
Image@unclebobmartin Business interactions are also business objects. Controllers should invoke interactions not _be_ interactions.
…

En résumé, Uncle Bob mentionne que pour éviter le couplage, le presenter devrait se refaire de nouveaux objets et les passer à la vue. Martin Fowler nuance un peu le tout en mentionnant que ce n’est pas vrai tout le temps et que cela dépend du contexte.

Le fait de se refaire de nouveaux objets pour la vue peut amener certains problèmes. Exemple, j’ai vu très souvent ce genre de code qui, pour moi, est un beau cas de duplication:

 public ViewObject ConvertObject(BusinessObject objectFromModel)
        {
            var viewObject = new ViewObject() ;
            viewObject.Name = objectFromModel.Name;
            viewObject.Adress = objectFromModel.Adress;
            viewObject.PhoneNumber = objectFromModel.PhoneNumber;
            viewObject.City = objectFromModel.City;

            return viewObject;
        }
    }

Hmm, redondant n’est-ca pas ?

Si les objets sont pratiquement semblables, je suis d’accord avec le point de Martin Fowler et que ce genre d’objets peut être visible au niveau de la vue.

Par contre, s’il y a quelques différences ou des champs non utiles qui sont tout de même transférés à la vue, je crois qu’il vaut mieux y aller avec de nouveaux objets comme le mentionne Uncle Bob.

Bref, la règle à suivre selon moi est de toujours voir selon les besoins du contexte.

Et vous, qu’est-ce que vous faites dans ce cas avec les Business Objects ?

Small Basic, un bel outil d’apprentissage

En bon papa, je voulais initier ma grande fille à la programmation et aussi lui expliquer un peu ce que je fais dans la vie.

En regardant l’environnement de développement Small Basic de Microsoft, qui est gratuit en passant, j’ai donc décidé de l’utiliser et de regarder un peu ce qu’il peut faire.

Premièrement, l’interface est très « bonbon » avec seulement quelques gros boutons. Beaucoup plus épuré que Visual Studio:

image

Par la suite, je remarque que l’intellisense est aussi très graphique:

image

J’aime bien.  Je trouve que cela rend facile de voir les possibilités du langage. Je regarde aussi dans la documentation pour me trouver quelques exemples intéressants et je tombe sur les commandes suivantes:

image

Eh oui, le langage “Logo” est inclus en partie dans le Small Basic avec la commande “Turtle”. Ce fut un de mes premiers langages de programmation sur mon vieux Commodore 64 il y a de ça de nombreuses années. D’ailleurs, cela ressemblait à ceci à l’époque:

c64-terrapin-logo-vers-a.jpg

Par la suite, je guide ma fille pour l’aider à écrire ses premières lignes de code et on y va avec la compilation:

image

Ce qui donne un petit déplacement de la tortue:

image

On a aussi repris un exemple de la documentation qui fait tourner la tortue pour faire un beau dessin. Voici le code:

image

Et son résultat:

image

Cool, n’est-ce pas  ?

D’ailleurs la documentation est assez bien faite et montre différents exemples. On peut aussi compiler le tout et faire des exécutables.  Avec cela, s’achève cette première leçon, elle préfère jouer sur l’ordinateur que de programmer semble-t-il… On va donc la laisser grandir un peu plus et on essayera une autre fois.

Références:

TFS est ouvert aux vieilles technos

Je regardais récemment le scénario d’intégrer du code VB6 dans le gestionnaire de code source Team Foundation Server (TFS) 2008, histoire de faire un premier pas vers une conversion à .NET. C’est en fouinant un peu que j’ai découvert l’existence du Visual Studio Team System 2008 Team Foundation Server MSSCCI Provider

Ce petit provider de Microsoft s’avère très utile si vous avez de vielles applications et que vous voulez tout regrouper sous un même toit, comme avec TFS. On peut ainsi dire un beau bye-bye à Visual SourceSafe.

L’outil permet d’utiliser TFS comme gestionnaire de code source pour des outils de développement un peu vieillot tel que VB6 ou  Visual FoxPro. Il marche même avec PL/SQL après l’ajout d’un petit plug-in:

Du côté de VB6, tout marche très bien et les menus; ils sont pratiquement les même qu’avec Visual Source Safe (VSS):


On peut aussi changer de gestionnaire de code source au besoin grâce au programme suivant qui est installé avec le provider:

Une fois notre option choisie, on verra le bon gestionnaire de code source à la prochaine ouverture de notre outil de développement.

On peut donc ouvrir un projet VB6 sous VSS, changer le gestionnaire de code source et ouvrir une deuxième instance de VB6 qui utilisera TFS.

Points à retenir:

  • L’historique de VSS ne se copie pas dans TFS. À moins de faire une conversion, mais la procédure semble plus complexe qu’une simple copie des fichiers.
  • Le concept de fichiers partagés de VSS n’existe pas dans TFS. Si c’est utilisé, prévoir du temps pour réarranger le code.
  • La recherche dans TFS 2008 ne peut aller jusqu’au contenu des fichiers. On ne peut que chercher les titres des fichiers (!). Je ne sais pas si cette lacune est corrigée dans TFS2010 par contre.

Donc, ne jeter pas VSS aux poubelles trop vite. Il pourrait servir pour des recherches et des consultations de l’historique.

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 ?

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 ?