Bien débuter son développement pour ArcGIS : Partie 2 - Professionnaliser son code

De par leurs formations initiales souvent de haut niveau, les géomaticiens sont généralement au fait des techniques de gestion de projet. Néanmoins, ils ne possèdent que rarement des bases solides en informatique et plus précisément en génie logiciel.

Hors, le métier a beaucoup évolué : on assiste chez ESRI à une complexification et à une multiplication des langages et plates-formes capables d’intéragir avec ArcGIS tandis que plus généralement les logiciels open-source se démocratisent, les volumes de données et les attentes de fonctionnalités augmentent. De ce fait, le géomaticien se voit dans l’obligation d’élargir son champ de compétences dans la direction de celui du développeur, ne serait-ce que pour automatiser ses traitements.

Orientée vers le code, le développement, cette présentation a pour objectif d’apporter des informations en sus de celles des ouvrages du commerce sur la programmation pour permettre notamment au géomaticien de professionnaliser son code ou de dialoguer avec un développeur.

Cet objectif sera réalisé en explicitant quelques concepts, associés à un vocabulaire spécifique, ainsi qu’en présentant quelques outils autorisant une amélioration significative de la productivité ou de la qualité du code écrit, le tout dans un contexte .Net et ArcGIS.

Contexte

Dans cette première partie, je vais tenter d’expliciter les raisons qui amènent à constater un déficit de connaissances du génie logiciel de la part des géomaticiens. Ses processus, méthodes et outils pourraient cependant s’avérer utiles, voire indispensables.

Le Géomaticien, de + en + informaticien

La démarche métier, initiée par l’association GeoRezo (1), offre un aperçu du métier de géomaticien. Les différents sondages, études et analyses montrent principalement :

• Une très large représentation des formations « Géographie –Environnement», en augmentation entre 2003 et 2005,
• Une grande spécialisation et une haute technicité du métier: en 2005, comme en 2003, plus de 65% de la population ciblée a un diplôme bac+5,
• Le caractère pluri-disciplinaire du métier,
• Une demande croissante de compétences en développement.

De ce constat, il n’est pas exagéré d’attribuer à la majorité des géomaticiens un déficit de compétences et de connaissances dans les processus et méthodes employés dans l’industrie informatique et plus particulièrement dans celle du développement logiciel. Les géomaticiens possèdent cependant sûrement la capacité de combler ce déficit.

ESRI et le développement à façon

Les logiciels ESRI permettent depuis longtemps déjà une personnalisation de l’outil, comme par exemple  la possibilité d’enchaîner les traitements (scripts), de créer ses propres menus, fonctionnalités, … adaptés aux exigences métier de l’utilisateur.

Cette personnalisation a été rendue possible dès 1986 pour ArcInfo Workstation dans sa version 4 avec l’apparition du langage AML (2). Pour ArcView, il a fallu attendre la version 3 en 1996 et la naissance du langage Avenue (3). Pour la gamme ArcGIS enfin, l’apparition des ArcObject (4) s’est faite en 1999 avec la version 8.

FIGURE 1: EVOLUTION DES SOLUTIONS ESRI (SOURCE: HTTP://WWW.WIKI.GIS.COM/WIKI/INDEX.PHP/FILE:SDS10FIG2.1_SWEVOLUTION.JPG )

Depuis cette date, avec une accélération lors des ces toutes dernières années, on assiste à deux phénomènes concomitants :

• Un rapprochement vers les langages standards :
  • D’une part, l’abandon progressif des plates formes ArcView et ArcInfo (respectivements de statuts ‘Mature support’ depuis 2002 et ‘General availability’ depuis 2008), avec comme corollaire le désintérêt des géomaticiens pour leurs langages,
  • D’autre part, la fin du support du VBA (5) dans ArcGIS après la version 9.4/10, que l’on peut mettre en relation avec l’apparition dans cette même version des add-ins (6), permettant l’ajout de fonctionnalités codées en langage .Net.
• Une diversification des langages capables d’intéragir avec ArcGIS :
  • Le Python (7), apparu en version 9 en 2004, permettant également la naissance du model builder (8),
  • Le support du média internet, via ArcIMS en 2002 et ArcGIS Server en Web ADF en 2006,
  • Les APIs riches pour ArcGIS Server en 2008,
  • Le supports des smartphones (9) en 2009/2010.

Ainsi, la personnalisation du logiciel glisse d’un modèle propriétaire robuste, documenté et facile d’emploi vers des langages plus génériques, induisant ainsi un besoin accru de compétences générales en développement informatique.

Plus généralement en géomatique

Plus généralement, on assiste également à une démocratisation des logiciels à fonctionnalités géographiques, open source ou non, tant professionnels que ‘récréatifs’ (cf.  (10), cartographie collaborative, …).

Cette démocratisation s’accompagne d’une augmentation des fonctionnalités des logiciels SIG open-source (11), (12) ainsi que d’une élévation des attentes d’un SIG, passant pour simplifier du stockage d’une représentation du réel à un outil de modélisation (cf. (13), vision geodesign ESRI (14))

De part ma veille technologique sur les forums géomatiques francophones, j’ai également noté une tendance à l’augmentation du volume et de la qualité/précision des données traitées ainsi qu’à la multiplication des logiciels employés. Parallèlement, on assiste à une augmentation des demandes d’automatisation des tâches et traitements.

Il est donc raisonnable d’imaginer un accroissement des scripts et bouts de code présents sur les machines des géomaticiens, dont la gestion en raison de leur nombre ou de la multiplication de leurs versions peut devenir délicate.

Objectif de la présentation

Orientée vers le code, le développement, cette présentation a pour objectif de compléter les ouvrages du commerce sur la programmation pour permettre notamment au géomaticien de professionnaliser son code ou de dialoguer avec un développeur.
Cet objectif sera réalisé en explicitant quelques concepts, associés à un vocabulaire spécifique, ainsi qu’en présentant quelques outils autorisant une amélioration significative de la productivité ou de la qualité du code écrit, le tout dans un contexte .Net et ArcGIS.

Phase de développement : des principes

Dans l’écriture des lignes de code, il convient de se fixer des principes, des règles, parfois communs à tous les logiciels et parfois propres au langage employé et/ou à l’équipe de développeurs. Cette partie tente d’en lister les plus importants.

Principes de développement, en vrac …

De manière très générale, dès la phase d’architecture du logiciel comme dans le code d’une classe, trois principes majeurs sont à retenir :

• Faire au plus simple, quitte à affiner, complexifier une fois l’ébauche fonctionnelle, KISS : Keep It Small & Simple  (http://en.wikipedia.org/wiki/KISS_principle )
• Ne pas se répéter… En clair, factoriser le code qui peut l’être, c’est-à-dire le rendre commun ou générique afin de pouvoir le réemployer, DRY : Don't Repeat Yourself (http://en.wikipedia.org/wiki/Don%27t_repeat_yourself  )
• N’ajouter une fonctionnalité que si elle est nécessaire ou demandée par les utilisateurs, afin de se focaliser sur l’important à implémenter, YAGNI : You Ain't Gonna Need It (n’ajouter une fonctionnalité que si nécessaire) (http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It  )

Principes de développement, patrons de conception

Les patrons de conception sont utilisés dans le monde de la programmation orientée objet (.Net, Java, …) afin de fournir des solutions efficaces à des problèmes récurrents comme par exemple « Comment n’autoriser qu’une seule instance de la classe trucmuche ? ». Autrement dit, ils décrivent des solutions standard pour répondre à des problèmes d'architecture dans le monde objet. Le lecteur intéressé pourra se reporter notamment aux liens suivants :

• http://fr.wikipedia.org/wiki/Patron_de_conception
• http://dotnetgrowingpains.blogspot.com/2009/08/introduction-to-design-patterns-as-best.html
• http://www.evernote.com/shard/s6/res/3b2b4040-ce93-440b-a3fa-cee46df7de04/Introduction+to+Design+Patterns+as+a+Best+Practice.pdf
• http://www.dofactory.com/Patterns/Patterns.aspx

Principes de développement, nommage

Les principes regroupés dans les bonnes pratiques de nommage permettent de standardiser le code produit. Elles portent notamment sur la façon de nommer les variables, les classes, les objets, comme par exemple choisir (et s’y tenir!) entre :

• MonBoutonListerLesCouches
• ListerLesCouchesBouton
• LayersListButton
• …

Le nommage permet alors :

• De rendre plus lisible le code produit par différents développeurs,
• De faciliter la documentation de son code,
• D’apporter des métadonnées facilement appréhendables sur le bout de code (dans l’exemple ci-dessus, un objet de type bouton destiné à récupérer la liste des couches de la carte)
• De pouvoir automatiser la maintenance, i.e. regrouper automatiquement attributs et propriétés dans une région par exemple, voire générer une esquisse automatique de commentaire sur une fonction.

Le lecteur intéressé pourra se reporter notamment aux liens suivants :

• http://submain.com/products/guidelines.aspx 
• http://blog.xebia.fr/2010/02/18/nommage-en-anglais-ou-francais-ou-franglais/

Principes de développement, documentation du projet

Il existe plusieurs types de documentation pour un projet :

• Besoins (cahier des charges)
  • Fonctionnalités
  • Performances
  • Sécurité
  • …
• Communication avec le logiciel (inputs, outputs)
• Architecture (logicielle, physique,…)
• Comptes rendus de réunions
• Cahiers de tests (vierges et  passés)
• Marketing
• + doc du logiciel

Le lecteur intéressé pourra se reporter notamment au lien suivant : http://fr.wikipedia.org/wiki/Documentation_logicielle

Principes de développement, documentation du logiciel

Pour un logiciel, là aussi plusieurs document sont à rédiger

• Technique :
  • Choix (// contraintes)
  • pb rencontrés,
  • Solutions,
  • …
• Administration
  • manuel d’installation,
  • de maintenance
• Manuel utilisateur
• Dictionnaire des classes
• Librairies tierces (+ code source)

Le lecteur intéressé pourra se reporter notamment au lien suivant : http://fr.wikipedia.org/wiki/Documentation_logicielle

Phase de développement : des pratiques

Après avoir esquissé les principes, la partie suivante vise à lister et décrire les pratiques utilisées en développement.

La gestion de versions, quoi ?

• Dans le développement, on modifie le code :
  • Ajouts,
  • Modifications,
  • Suppressions.
• La gestion de version enregistre ces modifications
  • Datées,
  • Commentées,
  • Associées à un développeur.
• Elle permet donc notamment :
  • La restauration de l’état d’un projet à une date/modification donnée,
  • D’assurer une sauvegarde du projet.

Le lecteur intéressé pourra se reporter notamment au lien suivant :
http://fr.wikipedia.org/wiki/Gestion_de_versions

La gestion de versions, quand ?

A employer toujours et dès le début, cette pratique apportant en sus du versionnement un backup régulier, les coûts de mise en place étant également très largement inférieurs aux bénéfices. Chez ESRI, le sujet a été abordé via la présentation « ESRI DS2010 Developer-to-Developer: The ESRI Development Process » (http://proceedings.esri.com/library/userconf/devsummit10/papers/tech/sou... ).

La gestion de versions, l’exemple de SVN+Tortoise .

FIGURE 2 : CLIENTS POUR SUBVERSION.

Le lecteur intéressé pourra se reporter notamment aux liens suivants :

• SVN :
  • http://subversion.tigris.org/
  • http://fr.wikipedia.org/wiki/Subversion_%28logiciel%29 
  • http://svnbook.red-bean.com/  
• Clients SVN
  • http://rapidsvn.tigris.org/   
  • http://freefr.dl.sourceforge.net/sourceforge/tortoisesvn/TortoiseSVN-1.6.2-fr.pdf
  • http://arcgisdeveloper.blogspot.com/2009/10/cool-web-app-client-for-svn-repository.html
  • http://www.websvn.info/

FIGURE 3 : APERCU VISUEL DE SUBVERSION ET TORTOISE.

La gestion de versions, pour Visual studio.

AnkhSVN sans hésitation disponible pour Microsoft Visual Studio 2005, 2008 ou 2010. Pour tous les types de projets de MS VS, 100% open source, cité/conseillé par le projet SVN. AnkhSVN est disponible à l’URL http://ankhsvn.open.collab.net/

La gestion de versions, conseils.

1. Ne pas utiliser le versionnement comme un outil de backup
2. Commiter à chaque changement d’unité logique
3. Être précis et exhaustif dans ses commentaires
4. Ne jamais casser le build du trunk (l’application doit compiler)
5. Ne créer une branche/version que si nécessaire
6. Commiter souvent et tôt

Les 5 premiers conseils sont tirés de http://www.iovene.com/21   et y sont donc explicités en détail. Le sixième est décrit plus précisément à l’URL http://stackoverflow.com/questions/107264/how-often-to-commit-changes-to... .

Documentation du code, quoi ?

Deux points d’entrée :

• Documenter les attributs, propriétés, fonctions, procédures, classes, namespaces:
  • Apporte l’intellisense (assistance au codage),
  • Génération automatique de documentation technique,
  • Utilisation des tags de documentation.
• Documenter dans les fonctions et procédures:
  • Explicite le code ’réellement’ écrit,
  • Ni trop, ni trop peu… ,
  • Correspond plutôt au raisonnement qu’au pseudo code, i.e. le pourquoi plutôt que le comment.

Documentation du code, quand ?

En permanence…

Documentation du code, comment (.net)

La documentation du code en .Net utilise un fichier XML, lié aux fichiers contenant le code. La syntaxe utilisable est décrite aux URL suivantes :

• Bien commenter et documenter son code, http://vincentlaine.developpez.com/tuto/dotnet/comdoc/ 
• Documenting Your Code With XML Comments, http://msdn.microsoft.com/en-us/magazine/dd722812.aspx 
• XML Comments Quick Reference, http://jelle.druyts.net/2005/01/16/XMLCommentsQuickReference.aspx 

Dans Visual Studio, le menu contextuel d’une classe, fonction, méthode, propriété ou d’un attribut laisse apparaître l’item « Insérer un commentaire ». Au clic, l’IDE générera le squelette du commentaire pré-rempli de façon sommaire. Un plug-in gratuit (GhostDoc, http://submain.com/products/ghostdoc.aspx  ) permet d’aller plus loin en pré-remplissant de façon beaucoup moins sommaire les commentaires :

• Anciennement exclusivement pour C#.Net, maintenant également pour VB.Net
• En cas d’héritage ou d’implémentation d’interface, récupère la documentation parente
• Interpréteur de nommage pour tenter une documentation automatique

Documentation du code, comment (JS)

Dans le cas particulier des commentaires pour du code javascript, il s’agit :

• De commenter le code javascript afin de le rendre exploitable par le moteur intellisense de Visual Studio
• De pouvoir activer l’intellisense pour du code javascript
• Ainsi que de pouvoir regrouper en #region le code javascript, afin de le rendre plus lisible

On pourra se reporter à :

• The format for JavaScript doc comments
• http://weblogs.asp.net/bleroy/archive/2007/04/23/the-format-for-javascript-doc-comments.aspx
• Ajouter l’intellisense sur les librairies JS:
• http://blogs.esri.com/Dev/blogs/arcgisserver/archive/2008/09/16/How-to-get-IntelliSense-with-the-.NET-Web-ADF-JavaScript-library.aspx 
• http://weblogs.asp.net/scottgu/archive/2007/04/24/javascript-intellisense-in-visual-studio-orcas.aspx 
• Using #region Directive With JavaScript Files in Visual Studio
• http://blog.devarchive.net/2008/04/using-region-directive-with-javascript.html

Documentation du code, illustration.

FIGURE 4 : ILLUSTRATION DE L'ECRITURE D'UN COMMENTAIRE SUR LA FONCTION REGKEYEXISTS (EN HAUT À GAUCHE), SUR L'INTELLISENSE QUE CELA APPORTE AILLEURS DANS LE CODE DURANT L'ECRITURE (EN BAS À GAUCHE) OU EN AIDE MEMOIRE / DOCUMENTATION TECHNIQUE (EN BAS À DROITE).

Documentation générale du code, principes.

La documentation générale du code vise à construire un index des classes utilisées/créées (souvent appelé « Library reference »), avec leurs composants (attributs, propriétés, méthodes, fonctions) commentés, ainsi que des liens existants (héritage, interfaces, …). Elle peut être construite automatiquement si le code a été commenté.

FIGURE 5: EXEMPLE DE DOCUMENTATION GENERALE DU CODE (SOURCE : HTTP://I.MSDN.MICROSOFT.COM/DD722812.FIG09_L%28EN-US%29.GIF ).

Documentation générale du code, retour d’expérience sur SandCastle.

L’utilitaire SandCastle permet, si les bonnes pratiques de commentaires ont été respectées, de générer automatiquement la documentation générale du code, la library reference.

• Génération de documentation (library reference) avec Sandcastle Help File Builder
• Remplir SandcastlePath dans le projet ..\Program Files\SandCastleEcosystem\SandCastle\
• Pas de génération dans un dossier « système », y compris sur le bureau
• Peut être long
• Tout un tas de paramètres : en-tête, logo, inclusion ou non des références, ….
• Retenir qu’une fois le code documenté, l’essentiel est fait…

Le lecteur intéressé pourra se reporter notamment au lien suivant :
http://philippe.developpez.com/articles/SandCastle/

Optimisation du code

Il s’agit de :

• Modifier du code existant
• Sans en modifier le comportement,
• Dans le but de réduire:
  • Le temps d'exécution d'une fonction,
  • L'espace occupé par les données et le programme,
  • La consommation d'énergie,
  • …
• Pas trop tôt, aux environs de la bêta

Le lecteur intéressé pourra se reporter notamment au lien suivant :

http://fr.wikipedia.org/wiki/Optimisation_de_code

Refactoring, principes

Il s’agit de :

• Modifier du code existant
• Sans en modifier le comportement,
• Dans le but d'en faciliter la maintenance:
• Méthode trop longue,
• Nommage inconsistant
• Code mort
• …
• Généralement sous le contrôle de tests unitaires.

Quand ?

• Projet Agile: une fois par cycle ?
• Autre: interval régulier…

Le lecteur intéressé pourra se reporter notamment aux liens suivants :

• http://fr.wikipedia.org/wiki/Refactoring ,
• http://fr.wikipedia.org/wiki/Refactorisation
• http://www.geek-directeur-technique.com/post/2009/08/26/La-refactorisation

Et trouvera une liste de cas et exemples de refactoring (en java, mais les idées restent les mêmes) :
http://wiki.java.net/bin/view/People/SmellsToRefactorings

Refactoring, comment ?

Il n’existe pas d’outils dédié au refactoring dans Visual Studio. Néanmoins, un plug-in gratuit est disponible, intégré au produit CodeRush Xpress et dénommé Refactor!.

Refactor! for Visual Basic 2008, inclus dans coderush xpress :

• Permet notamment :
  
  • Changement des signatures
  • Aide sur les expressions
  • Propositions de changements
• En bonus: aide à la lecture du code
  • Renforcement de la lisibilité de la structure du
  • code via l'emploi de lignes de tabulations
  • Soulignement des occurences au survol d'un objet 

Le lecteur intéressé pourra se reporter notamment aux liens suivants :

• http://msdn.microsoft.com/en-us/vbasic/bb693327.aspx
• http://www.devexpress.com/Products/Visual_Studio_Add-in/CodeRushX/  
• http://msdn.microsoft.com/en-us/vbasic/ms789084.aspx#refactor_why

Refactoring, l’outil Refactor!.

FIGURE 6: 4 FONCTIONNALITES DE REFACTOR! EN IMAGE.

L’illustration ci-dessus illustre 4 fonctionnalités de Refactor! :

• Lisibilité :
  • La mise en évidence et un contrôle accru des indentations (à gauche en haut),
  • Le soulignement des occurrences d’une variable (à gauche en bas)
• Refactoring :
  • Le transfert d’une constante de ressource en ressource incorporée (à droite en haut),
  • L’ajout d’un paramètre à une fonction (à droite en bas)

Loguer, quoi ?

Il s’agit de :

• Enregistrer des évènements
  • Instanciations de classes
  • Inputs/outputs fonctions
  • Valeurs de variables
  • …
• Avec des niveaux de log:
  • Debug
  • Fatal
• Dans une BD (fichier ou sgbd voire mails)
• Pourquoi ?
  • Débugger
  • Informer (bug, action réalisée, …)
  • …

Retenir qu’un mécanisme de log doit à minima fournir des niveaux de logs et pouvoir être activé/désactivé facilement lorsque le logiciel est déployé.

Le lecteur intéressé pourra se reporter notamment au liens suivants :

• http://fr.wikipedia.org/wiki/Historique_%28informatique%29
• http://www.codinghorror.com/blog/2008/12/the-problem-with-logging.html

Loguer, quand ?

Dès le début du projet

Selon ses besoins, avec un minimum syndical (15) :

• INFO Level
  • The start and end of the method
  • The start and end of any major loops
  • The start of any major case/switch statements
• DEBUG Level
  • Any parameters passed into the method
  • Any row counts from result sets I retrieve
  • Any datarows that may contain suspicious data when being passed down to the method
  • Any "generated" file paths, connection strings, or other values that could get mungled up when being "pieced together" by the environment.
• ERROR Level
  • Handled exceptions
  • Invalid login attempts (if security is an issue)
  • Bad data that I have intercepted forreporting
• FATAL Level
  • Unhandled exceptions.

Loguer, comment ?

On ne saurait faire l’impasse d’un framework de logs, évitant de ré-inventer la roue. Parmi ceux existant, citons Log4Net :

• Introduction à log4net : http://lutecefalco.developpez.com/tutoriels/dotnet/log4net/introduction/
• En contexte ESRI : http://blog.davebouwman.com/index.php/2009/10/using-log4net-in-arcmap-co...
• log4javascript: http://log4javascript.org/index.html  

Ainsi que quelques compagons utiles :

• Fédérer les logs: TraceTool 12.1: The Swiss-Army Knife of Trace: http://www.codeproject.com/KB/trace/tracetool.aspx 
• Lire les logs en direct sans verrouiller le fichier: baretail
• http://viswaug.wordpress.com/2008/09/14/a-better-way-to-read-arcgis-server-logsand-some-weird-errors-being-logged/
• http://www.baremetalsoft.com/baretail/

En .Net, le lecteur intéressé par des alternatives à Log4Net pourra se reporter notamment aux liens suivants :

• http://nlog-project.org/
• http://www.codeproject.com/KB/cs/ReallySimpleLog.aspx

Tests unitaires, quoi ?

Il s’agit de :

• Ecrire du code pour vérifier du code
• S’assurer du fonctionnement d’une partie du logiciel
• Répétable
• Vérifie l’impact d’une modification du code sur le reste du logiciel
• Argument qualité
• Aide au suivi de l’avancement

FIGURE 7 : LES TESTS UNITAIRES (SOURCE: HTTP://WWW.ESRI.COM/NEWS/ARCUSER/0110/NOYLES.HTML).

Chez ESRI, la question a été abordée lors de la session “ESRI DS2010 Developer-to-Developer:
The ESRI Development Process” http://proceedings.esri.com/library/userconf/devsummit10/papers/tech/dev...

Le lecteur intéressé pourra se reporter notamment aux liens suivants :

• http://fr.wikipedia.org/wiki/Test_unitaire
• http://www.dotnetguru.org/articles/dossiers/testunitaires/UnitTest.htm
• http://www.codeproject.com/KB/tips/convince.aspx
• http://smeric.developpez.com/java/astuces/tests/
• http://dotnetgrowingpains.blogspot.com/2009/10/advanced-unit-testing.html
• http://www.evernote.com/shard/s6/res/59d2d6fd-1aad-4048-a690-5a67c597b4e4/Advanced+Unit+Testing.pdf
• http://exchange.itpro.fr/Veille-Technologique/suivante/1/3/211013914-Visual-Studio-2010-Pex-Power-Tools-:-du-testing-pour-les-developpeurs-.htm

Tests unitaires, quand ?

Complexes, les tests unitaires peuvent êtres mis en place :

Si :

• Chef de projet confirmé
• Equipe aguerrie
• Méthode plutôt Agile

Alors… dès le début du projet

Tests unitaires, cas particulier: le pattern de test "objet simulacre" (Mock Object)

Comment faire pour tester une méthode qui utilise une base de données ?
Comment tester la validité d'une écriture dans un log ?
De façon générale, comment peut-on tester du code faisant intervenir un objet pour lequel l'initialisation est plus importante que le test que l'on pensait effectuer ?

La solution : Mock, pattern de test « objet simulacre »: un "objet simulacre" est un objet qui va remplacer un des objets réels de notre solution, mais qui va retourner un résultat que l'on va prédéfinir.

Le lecteur intéressé pourra se reporter notamment au lien suivant :
http://philippe.developpez.com/articles/IntroductionMock/

Tests unitaires, cas particulier: le pattern de test "objet simulacre" chez ESRI

Seule solution pour être général et ne pas tout réinventer : ArcUnit pour pallier à la déficience ESRI dans le SDK

FIGURE 8 : ARCUNIT.

Pas de changements sur le sujet à venir de la part d’ESRI
https://c.na1.visual.force.com/apex/ideaView?id=0873000000086uy  «Thanks for the feedback but at this time ESRI has no plans to provide a test framework. –Rob, ArcGIS Engine Product Manager »

Pour le monde ESRI et donc la cartographie, le lecteur intéressé par le concept de mock pourra se reporter notamment aux liens suivants :

• http://dotnetgrowingpains.blogspot.com/2009/06/dynamic-mapresourcemanager-part-1.html
• http://dotnetgrowingpains.blogspot.com/2009/08/dynamic-mapresourcemanager-part-2.html
• Unit Testing for ESRI Developers: A test case for ArcUnit, http://www.esri.com/news/arcuser/0110/noyles.html

Phase de développement : des outils généraux (et gratuits)

Pendant la phase de développement proprement dit, i.e. l’écriture du code, l’emploi de logiciels spécifiques peut grandement améliorer la productivité. Ce chapitre liste ceux peuvent vite devenir indispensables.

Reflector, principes.

En langage .Net, le logiciel à utiliser sans modération s’appelle Reflector :

• Dé-compile des exe ou des dll du framework .Net
• Permet de pallier à une absence de doc
• Peut permettre de comprendre le code utilisé par une librairie tierce

Pour plus de précisions, un excellent tutoriel est disponible à l’URL http://www.csharpfr.com/tutoriaux/REFLECTOR-DECOMPILATEUR-NET_678.aspx

FIGURE 9: REFLECTOR (SOURCE: HTTP://WWW.CSHARPFR.COM/TUTORIAUX/IMAGEHANDLER.ASHX?DOCUMENTID=108&NAME=... ).

Reflector, les add-ins.

Parmi la liste des add-ins pour reflector disponibles, citons notamment :

• Refexil, qui permet la modification du code d’une assembly (dll),
• FileDisassembler, qui permet d’exporter/désassembler dans le langage de son choix une assembly,
• AutoDiagrammer et SequenceViz, qui schématisent les classes et séquences de l’assembly.

Liste complète: http://reflectoraddins.codeplex.com/

Le lecteur intéressé pourra se reporter notamment aux liens suivants :

• http://reflectoraddins.codeplex.com/ 
• http://www.codeproject.com/KB/msil/reflexil.aspx
• http://sourceforge.net/projects/reflexil/

FxCop et StyleCop, principes.

FxCop et StyleCop sont des outils qui analysent une dll et en dégage les incohérences par rapport aux bonnes pratiques recommandées par Microsoft (16).

• FxCop
  • Plutôt binaire
  • Plutôt sécurité, bonne pratiques de code
• StyleCop
  • Plutôt code source
  • Plutôt bonnes pratiques de présentation
• Attributs insérables (sur namespace, classe, fonction, …) pour indiquer que l’on déroge à une règle en toute conscience.

Le lecteur intéressé pourra se reporter notamment au lien suivant :
http://blog.developpez.com/ylarvor/p8651/developpement/c/c-retour-darsqu...

FxCop et StyleCop, FxCop

Vérifie :

• Design de la librairie
• Globalisation (langues)
• Conventions de nommage
• Performance
• Interopérabilité
• Portabilité
• Sécurité
• Usage

FIGURE 10: FXCOP.

Le lecteur intéressé pourra se reporter notamment aux liens suivants :

• http://webman.developpez.com/articles/dotnet/fxcop/
• http://www.codeproject.com/KB/dotnet/FxCop.aspx

FxCop et StyleCop, StyleCop

Vérifie :

• Documentation
• Modèle, présentation
• Maintenance
• Nommage
• Ordonnancement
• Facilité de lecture
• Espacement

FIGURE 11: STYLECOP.

Le lecteur intéressé pourra se reporter notamment aux liens suivants :

• http://en.wikipedia.org/wiki/StyleCop
• http://stylecop.codeplex.com/
• http://code.msdn.microsoft.com/sourceanalysis
• http://blogs.msdn.com/sourceanalysis/

NArrange - .NET Code Organizer/Formatter/Beautifier

Afin de préparer son code à StyleCop ou de l’arranger selon ses préférences (#region, attributs et propriétés groupées (ou non!), …, NArrange peut être employé.

FIGURE 12 : RESULTAT D'UN PASSAGE SOUS NARRANGE

Le lecteur intéressé pourra se reporter notamment aux liens suivants :

• http://www.codeproject.com/KB/codegen/narrange.aspx
• http://www.narrange.net/ 

Compteur de lignes de code

Cet outil basique permet d’obtenir quelques métriques (statistiques) simples d’un projet .Net, telles que le nombre total de lignes, le nombre de lignes de code ou de commentaires.

FIGURE 13: C#, VISUAL BASIC AND C++ .NET LINE COUNT UTILITY.

Le lecteur intéressé pourra se reporter notamment au lien suivant :

• http://richnewman.wordpress.com/2007/07/09/c-visual-basic-and-c-net-line-count-utility-version-2/

Conversion C# <-> VB

Les conversions C#<-> VB se font généralement via SharpDevelop, un IDE .Net Open Source.

• Via SharpDevelop
  • http://www.icsharpcode.net/opensource/sd/
  • + = Conversion complète de la solution possible!
• Service web (basé sur SharpDevelop):
  • http://www.developerfusion.com/tools/convert/csharp-to-vb/
  • http://www.developerfusion.com/tools/convert/vb-to-csharp/
• Plug-in VS CodeConvert (basé sur SharpDevelop)
  • http://codeconvert.codeplex.com/

Revue de code : Code review plug-in for Visual Studio 2008

Permet de :

• Faire des commentaires sur du code
• Enregistrés dans un xml associé à un fichier de code
• Et donc diffusable pour revue/discussion collaborative

FIGURE 14: CODE REVIEW PLUG-IN.

Le lecteur intéressé pourra se reporter notamment au lien suivant :

• http://www.codeproject.com/KB/work/ReviewPal.aspx

Le Todo sous VS

Insérer en commentaire un « TODO»  ou tout autre mot clé défini en jeton permet de retrouver, à la façon d’un marque-page, ce commentaire (ainsi que le fichier de code dans lequel il se trouve, accompagné de la ligne concernée). Cela permet de bénéficier directement dans Visual Studio d’une liste de tâches personnelle, dans la fenêtre « liste des tâches ».

FIGURE 15 : LE TODO SOUS VISUAL STUDIO (SOURCE : HTTP://KB.GILLELAND.INFO/HOME/TABID/808/CTL/ARTICLEVIEW/MID/1674/ARTICLE... ).

FIGURE 16 : MODIFIER LA LISTE DES MOTS-CLE APPARAISSANT DANS LA FENETRE LISTE DES TACHES DE VISUAL STUDIO.

Le lecteur intéressé pourra se reporter notamment au lien suivant :

• http://www.techheadbrothers.com/Articles.aspx/trucs-astuces-visual-studio-dotnet-page-16
• Comments and Tasks in Visual Studio, http://kb.gilleland.info/Home/tabid/808/ctl/ArticleView/mid/1674/article...

Conclusion

Au travers de cette présentation, le géomaticien débutant en développement pour Arcgis possède les clés permettant de dialoguer ou de collaborer sereinement avec un développeur professionnel…
Et qui sait, peut être même se sentir capable d’internaliser le développement ?

Remerciements

Le Doc, Lud, Warg, David, ClaireLK, Christell, Benoît, Et les autres
Pour leurs relectures et commentaires.

 

(1) Cf. http://georezo.net/wiki/_media/main:formetiers:poster_metier_mathian_200...

(2) http://en.wikipedia.org/wiki/ArcInfo, http://en.wikipedia.org/wiki/ARC_Macro_Language, http://downloads2.esri.com/support/product%20life%20cycle/ao_/ArcInfoWor...

(3) http://support.esri.com/index.cfm?fa=knowledgebase.gisDictionary.search&..., http://downloads2.esri.com/support/product%20life%20cycle/other_/ArcView...

(4) http://en.wikipedia.org/wiki/ArcGIS, http://downloads2.esri.com/support/product%20life%20cycle/ao_/584ArcGIS_...

(5) http://blogs.esri.com/Dev/blogs/arcobjectsdevelopment/archive/2009/03/30...

(6) http://www.arcorama.fr/2010/03/developer-summit-2010-plenary-session_24...., http://proceedings.esri.com/library/userconf/devsummit10/papers/tech/int...

(7) http://www.esri.com/news/arcuser/0405/files/python.pdf

(8) http://support.esri.com/index.cfm?fa=knowledgebase.gisDictionary.search&...

(9) http://blogs.esri.com/Dev/blogs/arcobjectsdevelopment/archive/2010/02/19..., http://geo.geek.nz/esri/run-arcgis-server-maps-on-your-blackberry-for-free/

(10) http://brehat.ec-nantes.fr/ogrs2009/download/Keynotes/From%20a%20niche%2...

(11) http://www.innovativegis.com/basis/MapAnalysis/Topic27/Topic27.htm

(12) http://www.esri.com/news/arcwatch/0210/feature.html

(13) http://brehat.ec-nantes.fr/ogrs2009/download/Keynotes/Free%20and%20Open%...

(14) An Overview on Current Free and Open Source Desktop GIS Developments. International Journal of Geographical Information
Science, Volume 23, Issue 10 October 2009 , pages 1345 – 1370

(15) Code to logging ratio? http://stackoverflow.com/questions/153524/code-to-logging-ratio#153547

(16) Conformité aux "bonnes pratiques" recommandées par Microsoft. Design Guidelines for Class Library Developers
http://msdn.microsoft.com/en-us/library/czefa0ke%28VS.71%29.aspx

Site officiel : forumsig
Autres Liens : Bien débuter son développement pour ArcGIS : Partie 1 - Professionnaliser sa gestion de projet

licence Creative Commons Paternité-Pas d'Utilisation Commerciale-Pas de Modification 2.0 France