Qu'est-ce qui arrive lorsque l'on mélange l'agilité avec la comédie musicale...
Amusant, n'est-ce pas ?
Kent Beck, l'un des fondateurs du XP Programming, a écrit récemment un article, "Tools for Agility", sur l'importance des outils avec les méthodologies agiles. Voici un petit résumé de ses propos:
Dans le manifeste agile on parle entre autre de miser davantage sur les individus et les interactions que sur les outils et les processus de développement lourds.
Mais cela ne veut pas dire qu'on n'a pas besoin d'outils. On ne parle pas ici de retourner à l'âge de pierre pour écrire nos plans de projet sur des murs de pierre !!!
La priorité des outils était dans une approche de type "Waterfall" est de supporter efficacement une activité donné. Maintenant, les outils doivent supporter efficacement le changement fréquent d'activité, comme c'est le cas avec l'agilité.
Comme on effectue des livraisons fréquentes de nouvelles fonctionnalités, il y a davantage de transitions entre ces activités. L'image suivante représente bien ce problème de transition dans un mode agile:
La plupart des pratiques agiles ont donc besoin d'outils qui sont ajustés à ce rythme de développement. On ne pourrait pas faire de l'intégration continue sans des outils comme CruiseControl, FinalBuilder ou VSTS. Même chose pour le TDD, le refactoring et la planification itérative.
Si vous voulez en savoir plus sur l'impact des outils dans un mode agile et aussi sur l'avenir de ces mêmes outils, je vous recommande de lire l'article en question:
Tools for Agility by Kent Beck
Grigori Melnik, que j’ai rencontré au Patterns and Practice Summit l’autre fois, m’a parlé d’un projet qu’il a commencé portant sur les tests d’acceptions. D’ici à ce que son lui et son équipe produisent les documents de « guidance », il a fait un petit sondage pour l’aider à voir où mettre le focus sur les choses qui NOUS concerne. Il m’a demandé de faire parvenir ce lien aux personnes que cela pourraient intéresser.
Donc, si cela avez quelque chose à dire sur le sujet et que vous voulez aider Grigori dans ses recherches, voici le lien de son blogue qui parle de ce sondage :
http://blogs.msdn.com/agile/archive/2008/05/22/what-does-done-mean-to-you.aspx
Merci de l'aider dans ses recherches !
Lifehacker est un site fort utile. On y mentione des tas de trucs pour faire les choses simples, efficacement et sans perdre trop de temps.
On ne parle pas simplement de technologie, mais aussi de la vie de tous les jours.
Pour commencer, je vous suggère l'article suivant sur les meilleurs "hacks" du site :
Feature: The Best of Lifehacker in Upgrade Your Life
Voici un lien vers un petit vidéo fort intéressant de l'équipe "Patterns and Practice" de Microsoft. Des membres de l'équipe décrivent leur environnement de travail très axé sur l'agilité. J'aime bien le concept des tableaux blancs un peu partout et du rapprochement des équipes dans le but de favoriser la collaboration.
http://msdn2.microsoft.com/en-us/practices/cc304589.aspx
Bon, j'ai trouvé cette nouvelle version de CruiseControl en Ruby très intéressante:
On y mentionne pouvoir faire notre setup en 10 minutes (!)
Fini les fichiers XML à configurer. Hmm, cela semble attirant. Il faut cependant avoir SVN Subversion comme gestionnaire de code source et Ruby. On peut compiler des projets en Java ou en C#.
Notre code de configuration de notre build est fait en Ruby, un vrai langage de programation. Par exemple, un snippet de code peut ressembler à cela:
Project.configure do |project|
case project.name
when 'MyProject.Quick' then project.rake_task = 'test:units'
when 'MyProject.BigBertha' then project.rake_task = 'cruise:all_tests'
else raise "Don't know what to build for project #{project.name.inspect}"
end
end
J'adore cette manière très lisible de voir le code. Je ne pense pas que cela peut égaler la facilité d'utilisation et les nombreuses options de FinalBuilder, mais pour du OpenSource, cela semble prometteur. Moi qui n'aime pas trop les fichiers de configuration XML, voilà une bonne occasion d'essayer ce CruiseControl.rb !
Saviez-vous que la prochaine conférence du groupe Patterns and Practices de Microsoft aura lieu à Québec en mai prochain ?
En regardant la liste des sessions techniques, je remarque que plusieurs traitent de l'agilité. On voit donc que l'agilité est bien implanté chez Microsoft.
Pour plus de détails:
http://www.pnpsummit.com/queb2008sessions.aspx
Voici un lien pour se télécharger un poster des "Common User Types and Namespace" pour .NET framework 3.5 :
http://blogs.msdn.com/pandrew/archive/2007/11/02/announcing-the-net-framework-3-5-commonly-used-types-and-namespaces-poster.aspx
J'aime bien l'image suivante qui décrit l'évolution du framework:
Le magazine Redmond Developer News a publié cette semaine un article intéressant sur les technologies à maîtriser afin de survivre à cette marée de nouveautés. Voici le top 8:
- Rich Internet Applications (AJAX, Silverlight, ...)
- SOA and Web Services (WCF)
- Data-Driven Development (LINQ)
- Dynamic Languages in Managed Code(DLR, Iron Ruby, MVC, ...)
- Office Development Platform (VSTO)
- Mad about Multi-Core (thinking parallel)
- Development Testing (Unit Test)
- Web Development (VS2008)
Étant un fan du TDD, je suis bien content de voir qu'à la position #7, on mentionne l'importance des tests unitaires.
Pour détails sur tout cela, voir le lien suivant:
http://reddevnews.com/features/article.aspx?editorialsid=1781
J'ai découvert l'autre jour un petit utilitaire fort intéressant: Ghost Doc. Il permet de faciliter grandement l'ajout de commentaires "xml" dans le code. Ghost Doc analyse le code à commenter et génère un genre d'esquisse de commentaires et il ne nous reste plus qu'à le finaliser.
Exemple:
Voici une méthode en C# pour aller chercher une liste de répertoire sous un nom de server dans un fichier XML:
public static StringCollection GetDirectoryList(String serverName)
{
StringCollection collDir = new StringCollection();
XmlDocument xmlDoc;
XmlNodeList xmlNodeDirList;
XmlNode xmlNode;
...
}
Au lieu de faire les "///" traditionnelles, je me positionne sur la méthode à documenter et j'active la nouvelle option venant de GhostDoc avec le menu contextuel (clic droit), "Comment This" :
Et j'obtiens ceci sans rien faire d'autre:
/// <summary>
/// Gets the directory list.
/// </summary>
/// <param name="serverName">Name of the server.</param>
/// <returns></returns>
Je fais quelques petites modifications pour améliorer le tout et voilà:
/// <summary>
/// Used by the console or windows client to get the list of directories to scan
/// for the server name passed in the parameters
/// </summary>
/// <param name="serverName">Name of the server.</param>
/// <returns>
/// Return an array of string representing a list of directory
/// </returns>
Autre exemple avec une fonction de type "bool":
public static bool IsExcludeDirExist(string serverName)
{
bool nodeData = IsNodeDataExist(serverName.ToLower(), "ExcludedDirectories");
return nodeData;
}
J'utilise "Comment this" et j'obtient directement ceci:
/// <summary>
/// Determines whether [is exclude dir exist] [the specified server name].
/// </summary>
/// <param name="serverName">Name of the server.</param>
/// <returns>
/// <c>true</c> if [is exclude dir exist] [the specified server name]; otherwise, <c>false</c>.
/// </returns>
Et par la suite, j'y fais quelques modifications:
/// <summary>
/// Determines whether an excluded directory exist for the specified server name.
/// </summary>
/// <param name="serverName">Name of the server.</param>
/// <returns>
/// <c>true</c> if an excluded directory exist for the specified server name; otherwise, <c>false</c>.
/// </returns>
Intéressant, non ?
Ghost Doc ne fait pas des miracles, mais il rend la création de commentaires XML beaucoup plus facile. Par contre, il est important de bien nommer ses fonctions et méthodes pour que Ghost Doc puisse en faire une bonne analyse. C'est en fait une bonne pratique de toujours s'assurer que les noms de fonctions et méthodes sont toujours significatifs. Pour y arriver, il s'agit simplement de suivre ces trois règles:
Utiliser le "PascalCasing" ou le "camelCasing" pour écrire les noms avec plusieurs mots Débuter les noms des méthodes avec un verbe Ne pas utiliser d'abréviation dans les noms GhostDoc marche principalement avec le C#, mais je crois qu'il y a quelques fonctionnalités pour VB aussi.
Pour une simple introduction de GhostDoc, voici un article intéressant:
http://dotnetslackers.com/articles/vs_addin/Introduction_ghostdoc.aspx
Et pour le télécharger:
http://www.roland-weigelt.de/ghostdoc/
Autres liens intéressants pour des raccourci-clavier:
Free: Keyboard Shortcut Reference Posters for Visual Studio
http://blogs.msdn.com/robcaron/archive/2007/01/29/1552795.aspx
NET Cheat Sheets
http://john-sheehan.com/blog/index.php/net-cheat-sheets
Pour les amateurs de Tortoise SVN et de Subversion, les gens de CodeFlex travaillent actuellement sur un outil appelé "SvnBridge" pour être utilisé avec Team Foundation Server:
http://www.codeplex.com/SvnBridge
Si TortoiseSVN ou le concept de Subversion ne vous dit pas grand chose, voici quelques liens:
Définition de "Subversion":
http://en.wikipedia.org/wiki/Subversion_%28software%29
Logiciel de subversion "OpenSource" pour .NET:
http://tortoisesvn.net/
Logiciel pour l'intégration de Tortoise dans .NET (~50$ la licence):
http://www.visualsvn.com/
J'ai fait l'essai de TortoiseSVB dans quelques projets et je trouve cela très bien et aussi fiable (sinon plus) que VSS. Le concept de "merge" est puissant, ne causant que rarement des conflits. Il permet à plusieurs personnes de travailler dans le même fichier de code (ex: dans des fonctions différentes) en même temps sans créer aucun conflits. L'intégration de Tortoise avec le "Windows Explorer" est bien réalisée, améliorant ainsi l'opération de se créer un "Working folder". Et VisualSVN rend l'utilisation de tout ceci encore plus facile car tout se fait en direct dans Visual Studio.
Steve McConnell, un des mes auteurs favoris, vient de partir son blogue à l'adresse suivante:
http://forums.construx.com/blogs/stevemcc/default.aspx
Il est l'auteur, entre autres, des excellents livres suivants:
Code Complete (Guide très complet sur les manières de bien construire le code)
After the gold rush (essai sur la profession d'informaticien en général et autres trucs. Intéressant à lire)
