I. Visual Studio 2008, l'environnement de développement tout terrain

Image non disponible

I-A. Un seul outil pour plusieurs versions du Framework .NET et d'Office

Visual Studio 2008 permet de développer des applications ayant pour cible les différentes versions de .NET sorties après octobre 2005 (c'est-à-dire les versions 2.0, 3.0 et 3.5) et non plus une seule version comme ses prédécesseurs.

Qu'en est-il du développement d'add-ins pour la suite Office ? Il y a également du neuf vu que, par défaut, Visual Studio inclus Visual Studio Tools for Office et nous propose donc des projets de types add-in pour les versions 2003 et 2007 d'Office.

I-B. Des designers parfaitement intégrés

Désormais, il est encore plus aisé de développer des applications utilisant une interface graphique basée sur Windows Presentation Foundation (WPF) et de mettre en place de la communication entre différentes applications à l'aide de Windows Communication Foundation (WCF).

Les designers pour Windows Workflow Foundation (WF) se retrouvent également complètement intégrés à Visual Studio 2008, ce qui réjouira bon nombre de développeurs dont les nombreux développeurs SharePoint.

Vous aurez peut-être noté que ces designers étaient déjà présents dans Visual Studio 2005 sous la forme d'extensions. C'est effectivement vrai et, bien que ce ne soit pas fondé, un certain nombre de développeurs avait des craintes autour de l'installation de ces extensions, cette installation étant vue par certains comme du bricolage. Ces craintes peuvent désormais s'estomper et même disparaître : les designers font bel et bien partie intégrante de Visual Studio 2008.

I-C. Ajoutez du dynamisme dans vos applications Web

Inclus dans le Framework .NET 3.5 et disponible en tant qu'extension pour la version 2.0 du Framework, ASP.NET AJAX est un Framework s'intégrant parfaitement avec ASP.NET. ASP.NET AJAX permet d'implémenter facilement des contrôles utilisant JavaScript et permettant d'effectuer des requêtes vers le serveur de manière asynchrone, c'est-à-dire sans recharger la page web ni la bloquer durant l'exécution de ces requêtes. Mais cela ne s'arrête pas là : ASP.NET AJAX propose des composants permettant d'étendre les possibilités de plusieurs composants ASP.NET classiques et d'y ajouter des fonctionnalités du côté client.

Visual Studio supporte totalement ces différents contrôles.

I-D. De l'aide pour le développement d'applications Web utilisant du JavaScript

Avec l'utilisation en pleine croissance du JavaScript, tout environnement digne de ce nom se doit de posséder les outils permettant le développement avec du JavaScript. Visual Studio 2008 propose de nouveaux outils, permettant ainsi de regrouper tous les outils nécessaires au sein d'un même environnement. On retrouve ainsi véritablement de l'IntelliSense pour JavaScript, un vérificateur syntaxique et la possibilité de déboguer le JavaScript de manière simple et efficace directement dans Visual Studio.

Il ne nous reste plus qu'à utiliser abondamment ces outils pour rendre nos applications web encore plus attrayantes.

II. La gestion du cycle de vie d'une application

Les besoins et les exigences des utilisateurs grandissent jour après jour. Ainsi, gérer le cycle de vie d'une application devient une nécessité dans les développements d'aujourd'hui.

En utilisant Visual Studio et Team Foundation Server, la gestion du cycle de l'application fait partie du processus de développement, ce qui assure une maintenance plus aisée.

II-A. Quoi de mieux que des designers pour dessiner l'architecture des applications ?

Visual Studio 2008 nous permet de réaliser une approche " top-down ". Les architectes peuvent réaliser facilement le design d'applications, que ce soit du point de vue logique ou technique. Les architectes peuvent également utiliser un designer pour spécifier comment doit se faire le déploiement d'une application.

Image non disponible

II-B. Une méthode donne-t-elle le résultat attendu ?

Lors du développement, une des premières choses qu'importe un développeur est d'écrire du code qui réponde à des spécifications techniques et qui permette donc de réaliser les opérations indiquées au sein de ces spécifications. Ainsi, pour arriver à ses fins, le développeur peut créer des tests et développer la méthode jusqu'à ce qu'elle réponde entièrement aux différents cas présents dans les documents d'analyse grâce à l'utilisation de tests dit " unitaires ", c'est-à-dire ayant pour but de tester un cas particulier. Par ailleurs, par cette technique, nous pouvons vérifier que notre méthode fonctionnera toujours même si nous modifions d'autres méthodes ou classes.

II-B-1. Les tests unitaires

La première étape lors du développement d'une méthode, ou d'une fonction, en dehors de l'analyse et du développement proprement dit, est de vérifier que cette méthode répond aux spécifications. Il nous faudra donc tester les différents cas qui sont censés être gérés au sein de cette méthode.

Visual Studio nous permet, au travers des différents menus, qu'ils soient contextuels ou non, et des différents fenêtres mises à notre disposition, de créer, de gérer et de lancer les tests unitaires.

Le Framework utilisé par Visual Studio a été également fortement amélioré. Un test unitaire peut désormais hériter d'un autre test unitaire, ce qui permet, entre autres, de réaliser les différentes initialisations dans une classe de base et évite les doublons de code pour les tests unitaires.

Les tests unitaires peuvent également être appliqués à du code T-SQL.

Parfait, nous avons créé des tests unitaires et ceux-ci sont tous au vert. Enfin une application sans bugs, sans comportements non contrôlés et qui donc satisferont pleinement l'utilisateur final ! Mais… est-on sur de cela ? Non bien sûr, effectivement, nous venons de tester des morceaux d'application, mais quel est le pourcentage de code qui est réellement couverte par les tests unitaires? Pour le savoir, Visual Studio nous propose une fonctionnalité appelée " couverture de code ". Cet outil nous donne ce pourcentage méthode par méthode. Enfin, pour identifier les lignes de code qui ont été testées et celles qui ne l'ont pas été, cette fonctionnalité surligne chacune de nos lignes de code dans une couleur différente selon si un test couvre ou non celle-ci.

II-C. Le code est-il de bonne qualité ?

Maintenant, nous avons du code qui répond aux attentes vis-à-vis des opérations qu'il effectue. Cependant, est-il simple à maintenir ?

II-C-1. L'analyse du code

L'analyse du code permet d'identifier les erreurs de codage et les vulnérabilités au niveau de la sécurité. Cette analyse utilise la source de notre code afin de vérifier que nous respectons les différentes guidelines. Dans le cas contraire, nous recevons un avertissement dans la fenêtre " Liste des erreurs " si bien connue des utilisateurs de Visual Studio 2005.

De quel type sont les messages que l'analyseur nous renvoie ? Il vérifie par exemple qu'une librairie de classes soit bel et bien signée, que les variables sont bien initialisées avant leur utilisation et bien d'autres choses encore.

Par rapport à son prédécesseur, Visual Studio 2008 propose plus de 20 nouvelles règles dont principalement des règles autour des conventions de nommage et de l'orthographe, ce qui est très utile étant donné que parfois, les fautes d'orthographe dans une application peuvent provoquer un retour disproportionné de la part des utilisateurs par rapport à ces fautes. Pour éviter de recevoir des messages au sujet de l'orthographe des termes liés au métier auquel l'application est destinée, il vous est possible d'utiliser un dictionnaire personnel.

Mais le code d'une application s'arrête-t-il à la partie .NET de celle-ci ? Bien sur que non. D'ailleurs, souvent, le rôle de développeur .NET et de développeur SQL coïncide. C'est pourquoi ce type d'analyse s'applique également sur du code T-SQL. Ainsi, si nous avons utilisé un " SELECT * " dans une requête, l'analyseur nous indiquera qu'il est préférable de donner le nom des colonnes à retourner. Il sera ensuite très simple de réaliser la modification en utilisant du refactoring sur le code T-SQL.

Enfin, on notera une véritable évolution du point de vue de la gestion de ces messages puisque la suppression des messages est bien plus efficace qu'auparavant. Il est par ailleurs possible d'indiquer que les messages nous indiquant des améliorations possibles dans du code généré ne soient pas pris en compte.

II-C-2. Les métriques de code

Maintenir du code peut s'avérer une tâche ardue si les bonnes pratiques n'ont pas été mises en place. L'analyse statique du code ne permet pas de vérifier si les bonnes pratiques du point de vue architectural (faible cohésion entre les objets, …) sont respectées ou non.

Ainsi, sur base de valeurs telles que le nombre d'objets liés à une classe et le nombre de lignes présentes dans une méthode, un indice de maintenabilité est calculé. Le développeur peut ainsi aisément identifier les zones de code à refactoriser.

II-D. Et les performances dans tout cela ?

Grâce aux tests unitaires, à la couverture du code, aux métriques et à l'analyse du code, notre application est bien plus facile à maintenir et à modifier qu'auparavant. Mais, par quoi l'utilisateur final est-il le plus intéressé ? Du code facile à maintenir ou une application qui réponde à ses besoins, simple à utiliser et performante ?

II-D-1. L'analyse de performance

Un des critères important pour les utilisateurs d'une application est la vitesse d'exécution de celle-ci.

Ainsi, il est intéressant de réaliser des tests de performance durant le processus de développement. Identifier un goulot d'étranglement dans le code et cela avec des chiffres obtenus ligne par ligne permet de mettre le doigt sur une méthode qui rendra l'utilisation insatisfait et qui demande donc du refactoring.

Afin d'identifier ce qui s'avère être la meilleure solution, Il est également important de pouvoir comparer deux ensembles de résultats de tests de performance. Cela semble anodin mais il s'agit d'une des nouveautés les plus appréciées dans cette nouvelle version.

Le choix des résultats à comparer se doit d'être simple afin de permettre d'obtenir des résultats de comparaison réellement utiles. Cela est possible grâce à l'utilisation de filtres basés sur le timestamp ou le processus, entre autres.

Image non disponible

II-E. L'application répond-t-elle, dans sa globalité, aux attentes techniques et fonctionnelles ?

II-E-1. Les tests de charge

Comment notre application va-t-elle se comporter si plusieurs centaines ou plusieurs milliers de personne s'y connectent simultanément ?

Souvent, les tests sur les applications sont effectués par quelques personnes maximum et l'application ne subit pas le stress qu'elle subira le jour de la mise en production. Or, nous savons tous qu'une application qui n'est pas accessible le jour de sa sortie ne reçoit que difficilement pleine confiance des utilisateurs qui doivent s'y connecter.

Ainsi, il est important de réaliser des simulations réalistes basées sur différents critères comme la durée du test, le nombre d'utilisateurs et bien d'autres critères.

Enfin, si le nombre d'utilisateurs simulés est insuffisant, il nous est possible d'utiliser des agents à installer sur d'autres ordinateurs qui simuleront des utilisateurs supplémentaires.

II-E-2. Les tests d'applications Web

Pour tester nos applications web, nous allons utiliser la notion de scénario. Pour réaliser ces scénarios, rien de plus simple, il suffit d'enregistrer ceux-ci dans Internet Explorer grâce au plugin Test Recorder. Cette nouvelle version du plugin est capable de capturer le trafic généré par les requêtes effectuées à l'aide de XMLHttpRequest (et donc ce qu'il est communément appelé " AJAX "). Test Recorder peut également gérer les paramètres dynamiques qui peuvent être utilisés dans notre application.

Ces scénarios peuvent évoluer au fur et à mesure que le développement avance. Dès lors, le refactoring des tests d'applications s'avère d'une grande utilité. Ce refactoring permet d'extraire des sous-tests qui peuvent être exécutés seuls ou être liés entre eux. Grâce à cette possibilité de faire appel à d'autres tests, il est aisé de créer de nouveaux scénarios.

II-E-3. XML, le format pour le stockage d'informations concernant des tests

Les métadonnées et les résultats sont stockés dans des fichiers XML. Grâce à cela, vous pouvez manipuler ces fichiers à la main ou par programmation. Il est par ailleurs aisé de partager des fichiers contenant les définitions de tests, par l'intermédiaire de Team Foundation Server par exemple.

Toutes les définitions de tests doivent respecter un schéma qui est décrit dans le fichier TestTypes.xsd. En respectant ce schéma, nous pouvons créer de nouvelles définitions de tests qui pourront être exécutés par Visual Studio.

II-F. Travailler en équipe

Dès que vous pensez au mot " équipe ", pensez à Team Foundation Server. C'est lui qui est l'élément central de votre équipe permettant de partager des informations et du code source.

II-F-1. Le contrôle des sources partagées par un serveur de source

Eviter tout conflit et faciliter la manipulation des sources sur le serveur, voici ce qui ressort des nouvelles fonctionnalités et menus présents dans Visual Studio. Ainsi, il est par exemple possible d'automatiser le téléchargement de la dernière version lors de chaque " check-out ", ce qui assure d'éviter la perte de modifications réalisées par un membre de l'équipe sur ce même fichier.

II-F-2. Les annotations de fichiers

Plusieurs personnes peuvent intervenir sur un même fichier, à des moments différents. Ainsi, bien que l'on puisse forcer la déclaration du lien entre des fichiers et un Work Item lors de l'envoi des fichiers sources sur le serveur (check-in), comment pouvons-nous savoir qui a fait quelle modification ?

Tout simplement en utilisant des annotations. Celles-ci nous donnent la date et le nom du développeur qui a fait des modifications, bloc de lignes par bloc de lignes. Ces informations proviennent directement de Team Foundation Server puisque, à nouveau, c'est lui qui centralise ce type d'informations.

Cette fonctionnalité était disponible au sein de Visual Studio 2005 sous la forme d'un Power Tool.

Image non disponible

II-F-3. La comparaison de fichiers ou de répertoires

A nouveau présent en tant que Power Tool dans la version précédente de Visual Studio, la comparaison de répertoires permet d'identifier rapidement les différences entre le contenu des répertoires ou des fichiers.

Cette comparaison peut être réalisée entre des répertoires ne se trouvant pas sur la même machine.

II-G. Visual Studio pour les professionnels des bases de données

Au-delà des tests et analyses présentés précédemment et applicables au T-SQL, nous pouvons noter plusieurs améliorations particulièrement utiles.

II-G-1. Le refactoring du T-SQL

Nous utiliserons la " Wildcard Expansion " pour remplacer un " SELECT * " par un SELECT avec les noms des colonnes. Notez que ce refactoring est capable de gérer les alias, évitant ainsi toute ambigüité et ainsi toute erreur dans les requêtes.

On notera également que lors du refactoring de la procédure stockée, tout DataSet utilisant cette procédure pour son chargement est automatiquement refactorisé.

II-G-2. La comparaison de schémas ou de données entre deux bases

Cet ensemble de fenêtres permet non seulement de réaliser des comparaisons entre des données ou des schémas de bases de données mais également de générer les scripts permettant de synchroniser deux bases de données.

Les scripts générés peuvent être également sauvegardés pour une exécution ultérieure. Cette fonctionnalité est très utile pour faciliter les mises en production, que ce soit vis-à-vis des changements sur le schéma ou des configurations stockées dans une table par exemple. Nous sommes évidemment libres de modifier ces scripts si le besoin s'en fait sentir.

Image non disponible

III. Visual Studio Team Foundation Server

III-A. Des performances en nette évolution

Team Foundation Server 2008 est beaucoup moins gourmand en ressources que son prédécesseur. Cela sous-entend que plus d'utilisateurs peuvent accéder à Team Foundation Server simultanément pour accéder à un nombre grandissant de projets et ne bloquant pas pour autant les compilations et tests en cours.

III-B. Microsoft Office SharePoint Server 2007, distant ou non, pour la gestion des documents

MOSS 2007 n'est plus à présenter tant il est devenu une des références dans le monde de la gestion documentaire.

Team Foundation Server 2008 utilise pleinement les possibilités de Windows SharePoint Services 3.0 et de Microsoft Office SharePoint Server 2007. SharePoint peut être installé localement ou sur un autre serveur.

III-C. Check-in policies

Sauvegarder ses sources sur un serveur central et les partager entre différentes personnes est nécessaire pour un développement efficace en équipe. Cependant, pour cela, il faut encore que les sources mises en commun soient de qualité sans quoi, le travail de l'équipe s'en voit fort contrarié.

C'est sur ce constat que se base la notion de check-in policies. Effectivement, à chaque envoi des sources sur le serveur, c'est-à-dire à chaque check-in, Team Foundation Server vérifiera que nos sources respectent bien certaines règles. Ainsi, il est fréquent d'obliger le développeur à associer un changement dans ses sources à un Work Item, facilitant ainsi la maintenance.

D'autres règles peuvent être établies comme par exemple vérifier que le code est bien couvert entièrement à des tests unitaires ou que l'analyse de code ne renvoie pas tel ou tel type d'avertissements.

III-D. Faire de l'intégration continue sur base des déclencheurs dans Team Foundation Server

Sur base de déclencheurs, une compilation (et tous les tests qui en dépendent) peut être lancée à chaque check-in avec ou non un délai d'attente indiquant le délai minimum entre deux compilations. La compilation périodique reste toujours possible.

Notons également que la gestion, la configuration et la planification des compilations peuvent se faire directement dans Visual Studio, amenant de la convivialité pour l'utilisateur.

Image non disponible